I am building a JSP application. I am trying to send an screenshot image from the page to the servlet by using base64 encoding. It makes the returning string super long with 100k characters length. So when I post this to the servlet and with getParameter, I am getting null there.
Is there a way to get them by chunks are am I missing something?
I found this maybe useful for you.
Passing a huge String as post parameter to a servlet
Namit Rana:
We used GZip compression/decompression to lower the size of the string. And it worked effectively.
So, the .net service compressed the huge string, sent it to our Servlet. We then decompress it at our server.
Related
I want to get the image size from the URL.
My source is working locally but aws Ubuntu server will return -1.
What's the problem?
URL url=new URL("https://www.bithumb.com/resources/img/comm/sp_coin.png?v=180510");
int image_size = url.openConnection().getContentLength();
System.out.println("mage size:: "+image_size);
If the server doesn't respond with a valid Content-Length header, getContentLength returns -1. As an alternative, you can always get the size of the returned data:
size = IOUtils.toByteArray(url.openStream()).length;
Using Apahe commons IO IOUtils.
What's the problem?
Difficult to say. However, ultimately it is up to the implementation of the web service (not Ubuntu or AWS) to include a content length in the response.
So if you want to find out why (and fix it) you need to examine the implementation of the (your?) web service, and how it is creating the responses.
As #jspcal points out, you can work around the problem. But in order to do that you would need to (at least) read the entire image from the response data stream. Whether this is a viable / efficient solution depends how / when you intend to use the content length.
This is about a weird behaviour that I have witnessed while making a servlet that calls and fetches data from Apache Solr based on some parameters that I supply to servlet.
The servlet queries Solr and returns data to me in json format. Then verify it by placing a System.out.println(response). It was in json format only.
My issue is that when I received same response over a client who was consuming this service, data returned in Base64 format. In my code, I wrote not even a single line that converts the response into Base64. The only line I wrote before sending response were resp.setContentType("application/json").
Though I later solved it by setting resp.setCharacterEncoding("UTF-8");in my servlet before sending response. Then I received only JSON response every time I queried on client side or over a REST client. But still I am wondering, why that happened, why a response that was sent as a JSON from servlet converts into Base64?
Has anyone experienced something like this before?
I am using Apache Tomcat as my server.
This is most likely the property of your Java servlet framework. It is possible that your Solr content includes characters from Unicode range outside of English. So, the algorithm thinks it is actually a binary response and encodes it into base64 (possibly with a changed mime-type header).
Setting character encoding tells the framework that the full range of characters is expected and no escaping is required.
Or this could be in Tomcat. But the focus in your documentation search should be on escaping binary content, in my opinion.
I'm handling a Web Service and need some help. The process is that a pdf will be encoded with base64 and sent to my web service. I will then decode it back into a pdf and place it in the appropriate folder. The issue is that the request needs to contain the actual giant base64 string. First question is is this possible. Second, I am using postman to make the requests and was wondering how to even copy the base64 string into it. It seems there's a string limit. Any help would be greatly appreciated.
I don't know about postman but I can suggest to use JAX-RS and implement a ReaderInterceptor and a WriterInterceptor using Base64.Decoder#wrap respectively Base64.Encoder#wrap.
Otherwise, maybe postman has similar features?
Use streams like these as much as possible to reduce memory usage.
Tutorial:
https://jersey.java.net/documentation/latest/filters-and-interceptors.html#d0e9806
Alright it just seems to be an issue with Postman. When you place a string of that size it will give you errors and only put a certain length per line. It will still receive the entire string. I am able to receive it and decode it. Thank you all for your help!
I am having difficulty receiving a PDF file via a rest service. The rest service returns a long string with the data that is suppose to make up the PDF. My overall goal is to save the response as a PDF file for later use.
I call this service url: http://4.hidemyass.com/ip-2/encrypted/dnXuHKAZVZaONS2GNfC9RFn8k8puE2YJx6MjcPDMaKdpMRTBkvNF4CrTg4m7GeKjcLfO1bgYWIwR9bz1ZJP-LTK6Gm8tG_-d4V-oSUMfT-tIJMuZizsz9AeZp5tcZWVcz62A6j7YRWqJRAS_s_cMFLlo&f=norefer
and according the docs, it should be the string contents that make up a valid PDF.
What am I missing? What do I need to do in order to make is viewable as a PDF.
Thanks!
Chuc
Sorry the above link failed.
In the end we found that sending the PDF as binary data wrapped in JSON did not work very well. The creators of the service found that their framework was manipulating the binary data ever so slightly and converting some characters. They ended up switching to Base 64 encoding which worked great.
My REST web service has to send an image file to the client. I am confused between 2 options : send the image as a byte array, or should I encode it as a base 64 string ? What are the pros and cons of each ? I may have to compress the image using gzip...should it create problem with any one of methods ? I may even need to expose my method as a SOAP service, which method should I prefer in that case ?
Thanks !!
The wonderful thing about a RESTful interface is that it's just HTTP. So if you expose the "byte array" version via REST, any browser can do an HTTP GET on your REST URL and receive and directly render your image. Returning the payload verbatim is far more RESTful than placing an encoding on it. There is not much to recommend an extra base64 encoding layer via REST.
If you're returning SOAP, you absolutely want to return a base64 string. Raw binary data is not compatible with XML, upon which SOAP is built. You can try to work around it via MTOM, but for general-purpose compatibility with SOAP clients you probably want inlined base64-encoded data.
In general, there's no benefit to be gained by compressing an image file. The image formats themselves internally involve compression, and a second compression pass will not gain any more space savings.
If your service returnes JSON or XML (image + some information), than you should encode image in base 64 because both of them string based, and you want to transfer byte array. The only question, whether you should make it yourself or it should be made my framework you use.
Situation with GZip is clear - relay compression to the servlet container (like tomcat - you can configure, whether response should be gzipped). Alternatively you can use something like GZipFilter.