I am communicating to a Tomcat Server using a Java ME application on my mobile device.
I was wondering if I could compress my requests/responses using Gzip to reduce the number of bytes sent over the network.
Modern phones have so much CPU power and the network is relatively slow so compression makes perfect sense. It's quite easy to do also.
On the J2ME side, you do something like this (assuming you use HttpConnection),
hc.setRequestProperty("Accept-Encoding", "gzip, deflate");
if (hc.getResponseCode() == HttpConnection.HTTP_OK) {
InputStream in = hc.openInputStream();
if ("gzip".equals(hc.getEncoding()))
in = new GZIPInputStream(in);
...
We use GZIPInputStream from tinyline but I am sure there are others,
http://www.tinyline.com/utils/index.html
On the server side, it's all built-in. Just add following attributes to the Connector in server.xml on Tomcat,
<Connector
compression="on"
compressionMinSize="2048"
compressableMimeType="text/html,application/json"
... />
You can compress the content of an HTTP request or response, but not the headers. See section 3.6 of the HTTP 1.1 spec, and the later section that describes the Content-Encoding header.
EDIT: The flip side of this is that there is no guarantee that an HTTP server side will accept any particular compression format. And depending on the quality of the server-side implementation of HTTP, it might not even recognize that the request content has been compressed. So you don't want to do this unless you know that the server-side supports compressed request content.
Since you are using Tomcat, consider the possibility of putting an instance of Apache HTTP Server in front of the Tomcat server.
This can be done using the mod_jk module for Apache HTTP Server. Once you have done that, you can use mod_gzip/mod_deflate in Apache.
Of course, your client should have the ability to handle the compressed responses, for this to work. If you force your client to work with compressed responses, the client will end up displaying gibberish, since it would have been (usually) expecting plain text responses. You will find the definite indicator of the client's capability to handle compressed responses, in the client's Accept-Encoding headers.
This can be done programatically, using a servlet or a servlet filter that writes to a ZipOutputStream or GZipOutputStream, if you want to avoid the introduction of the Apache HTTP Server in the network. You will find some pointers on how to do this at the OReilly OnJava.com site.
On the server side, you can enable it as described here, but the mobile application will need a library that can decompress gzip, such as this one. Might be a bit of work to get it working though...
Related
I'm sending JSON data from my Java application to my local webserver with my PHP script that is receiving this message. Now as far as I know I can only view what has been received by for example inserting the data in a database. Is there a way/application to view the live POST requests sent to my PHP webserver?
I like to use fiddler for these kinds of tasks if the java HTTP library has support for proxies. Fiddler will list all information about the HTTP requests that is available. It will by default log all HTTP requests across your system, but can be told to limit to one application.
You can try setting your httpd logging level to verbose or (depending on what httpd it is) try to use extension that would do log all the data send in requests
For debugging purposes why not just write the POST data to a file?
i.e.
file_put_contents(<some filename>, $HTTP_RAW_POST_DATA);
i am working on java with Netbeans IDE and glassfish 3.1.2 i have created in rest services using jaxrs. when request from client is made ,i need to send json data in compressed format.to do this i have enabled the compression in glassfish as shown the following picture
but response got from the server is not compressed using gzip. it is receiving as normal json data. what should i do to overcome this issue
This is a solution for GF 3.1.2.2.
Responses to HTTP requests in version 1.0 are not compressed. You must send your requests in HTTP 1.1 to get gzipped responses from your glassfish server.
More over, you must add the header "Accept-Encoding: gzip" in your http requests.
To get a compressed response you need to have both sides agree to use it. You have configured GlassFish to send compressed responses. I can see that from the picture.
You need to make sure that your request to the services tells GlassFish that it can accept a compressed response. You normally do this by adding the following header to your HTTP requests: Accept-Encoding. You can read about the header in the RFC document that defines HTTP 1.1 request headers.
You can also get a lot of info from reading though SO questions about Accept-Encoding.
Is this done at the code level, perhaps through JAX-WS handlers? Or is it done through some configuration at the app server?
I've read something about web compression in general, it appears that just as the message is about to head to the wire, compression is applied. Clients should be able to accept a GZIP MIME type for them to be able to decompress the message.
I'd like to find out who's supposed to apply that compression and how it's done.
It can be done either by code or by configuring the server to do it on the fly. How it's done with server configuration varies widely depending on the server. For Apache, the tool to use is mod_deflate. The instructions when using JBoss are here.
To do it in code, you need to:
compress the data with gzip
set the content-length header to the length in bytes of the compressed response
include the following header in the response:
Content-encoding: gzip
The request should include the header:
Accept-encoding: gzip
More info can be found in Wikipedia.
I have a third party server that is periodically sending http post request messages to an URL(can be configured). In my application I am reading data by starting a jetty server and listening for data on the configured URL.
Wondering if it is possible to listen for the data sent by the server without starting any server like the jetty?
You can always create a socket yourself and listen at port 80 (or something similar) for HTTP requests. See http://download.oracle.com/javase/6/docs/api/java/net/ServerSocket.html
But there are several problems: Theres a lot of overhead that you need to do yourself. Parse the HTTP request, extract the headers and the body and depending on the headers you need to do certain things like caching, authentication, etc. And that's a lot of stuff you need to implement. Using an existing web server is usually a better idea, since the people who wrote it (usually) know exactly what they are doing.
Another option is the Apache HttpCore library (http://hc.apache.org/httpcomponents-core-ga/index.html). You can use it to write your own Http Server... But again, there's still a lot of stuff you need to take care of ...
If you want to do it for learning purposes, go ahead and implement it yourself. When it is for production, stick with the commonly used web servers.
I am trying to download a file from my Java application. But because UrlConnection uses HTTP 1.1 protocol i get a Tranfer Encoding: chunked response in which case i can not find out file size(content-length is not set). From what i could find HTTP version is hard coded in the class and there is no way to change it. Is it somehow possible to change the version back to one or tell the server not to use chunked encoding when sending a file?
Edit: I am not trying to retrive dynamic content my application is a download manager.
files i am downloading are static. Other downloaders i checked wget,igetter,curl use Http 1.0 and they get the size info from most servers. But my application and firefox issuing Http 1.1 always gets chunked encoding. I understand that content-length is not always present but i would like to get it most of time.
The Jakarta Commons HTTP Client contains a "preference architecture" that allows some fine grained control over the particulars of the HTTP connection. See http://hc.apache.org/httpclient-3.x/preference-api.html
It's very likely that the server can't specify a valid content-length, even if you specify HTTP/1.0. When content is dynamically produced, the server has to buffer it all to measure its total length. Not all servers are going to be able to fallback to this less efficient behavior.
If buffering the response is reasonable, why not do it in your client, where you have full control? This is safer than relying on the server.
Read the response without processing, just stuffing the data into a ByteArrayOutputStream. When you are done, measure the length of the resulting byte array. Then create a ByteArrayInputStream with it and process that stream in place of the stream you got from the URLConnection.