I am testing a REST API service that supports json and gzip data. I have tested the response from the json request payload. How to test if it handles gzip data properly? Please help?
Basically the client sends a request with accept-encoding as gzip in the header, service handles the compression and the client takes care of the decompression. But I need a way to confirm that service indeed handles compressed gzip data
gzip is basically a header + deflate + a checksum.
Gatling will retain the original Content-Encoding response header so you can check if the payload was gzipped, and then trust the gzip codec to do the checksum verification and throw an error if the payload was malformed.
Related
I'm invoking a HTTP GET request to another system using RESTEasy with resteasy-client:3.12.1.Final (provided by WildFly 20.0.1.Final).
ResteasyClient client = new ResteasyClientBuilder().build;
ResteasyWebTarget target = client.target(fromPath(url));
Response response = target.request()
.header(AUTHORIZATION, "Basic <authentication_token>")
.accept(APPLICATION_JSON)
.get()
As you can see, I don't configure anything "special" in the ResteasyClientBuilder but for some reason all requests contain this header parameter: Accept-Encoding: gzip which causes some trouble on the remote side.
The RESTEasy documentation however states:
RESTEasy supports (though not by default - see below) GZIP
decompression. If properly configured, the client framework or a
JAX-RS service, upon receiving a message body with a Content-Encoding
of "gzip", will automatically decompress it. The client framework can
(though not by default - see below) automatically set the
Accept-Encoding header to be "gzip, deflate" so you do not have to set
this header yourself.
From my understanding the gzip parameter should not be set by default. Or are there any other possible default configurations which might add this parameter?
You might want to try this:
Variant variant = new Variant(MediaType.JSON_APPLICATION, "", "gzip");
Response response = client.target(generateURL("/big/send")).request().post(Entity.entity(b, variant));
I don't know if I am not correctly understanding how the caching aspect of ETags work if there is some other issue I am dealing with, but I'll walk you through my situation.
From my understanding ETags are a unique hash that is created based on the file information and they are sent as part of Response header to uniquely identify the file. If the file is updated then the info is changed and hence the ETag for the file is also changed.
In my project, I need a fresh JS file to be fetched everytime I make changes to the file. I can't use version tags or unique hashes as part of the file name. I thought an ETag would work where
Http Request
GET myFile.js
Client ------------------> SERVER
Http Response 200
Http Response Header
accept-ranges: bytes
cache-control: max-age=86400, public
etag: "a7-58c3bb52101c4"
......
myFile.js
Client <------------------ SERVER
// myFile.js has not been changed
Http Request
GET myFile.js
Client ------------------> SERVER
Http Response 304
Http Response Header
accept-ranges: bytes
cache-control: max-age=86400, public
etag: "a7-58c3bb52101c4"
......
Client uses cached version of file
// myFile has been changed
Http Request
GET myFile.js
Client ------------------> SERVER
Http Response 200
Http Response Header
accept-ranges: bytes
cache-control: max-age=86400, public
etag: "88-58c3a1cb8474f" // new etag generated
......
myFile.js
Client <------------------ SERVER
So, if you request the file again and no changes have been made..the etag will remain the same and you'll get a 304 will indicate that the cached version should be used.
If the file has been changed the etag will be different as well and a fresh copy of the file will be sent by the server.
This is how I expected it to work.
MY PROBLEM:
When I update myFile.js it seems like I never get the new ETag has back. It just defaults to the cahced version of the file. If I clear the cache then I get the latest file and the new ETag. This to me seems to defeat the purpose. Is this how it works or am I understanding something incorrectly here?
How to enable glass fish compression? I enabled compression in http-lister properties
but no changed response
Login to admin console: localhost:4848
Go to the Network Config > Network Listener
Select the listener for which you want to enable gzip > HTTP Tab
Check if you have min compression size set. I don't remember from the top of my head if glassfish has a default min compression size. Pretty much if the resource does not exceed this value in size, it won't be compressed.
Check if you have correct compressableMimeType set. application/xml is not the same as text/xml, even if they're really both XMLs.
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.
My website serves gzipped content. I verified with Firebug and YSlow. However, JMeter does not request the gzipped content. Therefore, it gets all uncompressed content. As a result, my test cases take much longer (6-10x longer) than they do in reality.
How can I make JMeter request gzipped content from a website?
FYI, I am using the latest stable build: JMeter 2.3.4 r785646.
Add an HTTP Header Manager to the Thread Group in your Test Plan.
Add the name-value pair:
Name: Accept-Encoding
Value: gzip,deflate,sdch
This will ensure that all JMeter requests use HTTP compression.
To verify:
Add this Listener to the Thread Group: View the Results Tree
Run your test plan
View the Sampler result tab for one of the webpages.
Do you see these name-value pairs?
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
If yes, then you've successfully setup gzip requests in JMeter. Congrats.
Another way to verify is in the Summary Report stats:
You'll see that the Avg Bytes values are the uncompressed sizes. That's OK. For whatever reason, that's how JMeter works. Pay attention to the KB/sec column. That will show an improvement of 6-10x with gzip enabled.
By default axis2 returns regular(plain text xml) response. My goal - find some cfg property to make axis2 return gzipped response.
Anybody?
Thanks!
You configure this via the client, not the server
http://wso2.org/library/230#GZIP
Set this options flag to true
org.apache.axis2.transport.http.HTTPConstants.MC_GZIP_REQUEST
to send your client request gzipped
Set this options flag to true
org.apache.axis2.transport.http.HTTPConstants.MC_ACCEPT_GZIP to request that the server respond with a gzipped response