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.
Related
I'm new to Apache NiFi, and I developed an application to send JSON data to a NiFi endpoint via HTTP POST request.
In Apache NiFi, I have a HandleHTTPRequest processor connected to a PutFile processor then a HandleHTTPResponse processor. I've also tried using a LogAttribute processor. The response code and HTTP message from the NiFi web service is working properly, but I'm trying to make sure my JSON payload is being sent properly. Post is enabled in the HTTPRequest handler. Yet, the only files it's generating are blank and 0kb in size. Any ideas?
Based on the comments above the conclusion is that there was no problem on the side of Nifi.
It's definitely an issue with the Java code, I used postman again after changing some local firewall configurations and it successfully logs any POST requests that are sent to it and puts it in a file
The key step towards resolving the issue was trying to connect with something like Postman as #Binary Nerd and #Brian Bende suggested.
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);
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 am using SAAJ at the client side for sending a soap request. I am also attaching a random binary string as an attachment to the SOAP request, using this API.
soapMessage.addAttachment(attachment);
When I sniff this request through wireshark, I can see my attachment outside the <SoapEnv>,
but when this request reaches the client side (which is implemented using the JBoss libraries), I only get the message and not the attachment.
I have not specificed anything in the WSDL related to the attachments.
I can't figure out what can be the problem.
Any pointers would be helpful.
Do you send along the right Content-Type, Content-Transfer-Encoding and Content-ID header values?
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html#Value-space_of_Content-Id_Header
Maybe post the generated soap-message
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...