Disable HTTP Compression?

  • 1
  • Question
  • Updated 6 years ago
Is there a way to prevent compression (gzip/deflate) from being used in returned JSON?
Photo of Nathan Simonis

Nathan Simonis

  • 3 Posts
  • 0 Reply Likes

Posted 6 years ago

  • 1
Photo of Brendan Hayes

Brendan Hayes, Official Rep

  • 962 Posts
  • 123 Reply Likes
It happens at the server level and there isn't a parameter to turn it off.
Photo of afelicioni

afelicioni

  • 227 Posts
  • 43 Reply Likes
At raw http level I just verified that avoiding the use of header in request like Accept-Encoding: gzip, deflate data is returned in plain text.

So check your library or routine that "build and make" the HTTP request to api.wunderground.com for a piece of code related with this header.
Photo of Nathan Simonis

Nathan Simonis

  • 3 Posts
  • 0 Reply Likes
The [minified] library I'm using allows for headers to be sent, but i'm not sure that it's actually sending them. When I don't include "Accept-Encoding: identity", the response is sent with "Content-Encoding: deflate". If I send "Accept-Encoding: gzip", the response is still "Content-Encoding: deflate". It appears that it doesn't matter what I send (or think I'm sending), the response is always the same.
Photo of afelicioni

afelicioni

  • 227 Posts
  • 43 Reply Likes
Mumble, maybe not easy to fix this...
A dirty help could be come if instead of calling the http//api.wunderground.com/etc/ you can code a sort of sandbox URL in a machine you can manage and temporarly redirect requests to monitor first and analyze later at them.

I was also wondering if specifying aAccept-Encoding: identity;q=1.0, *;q=0
would solve this, but at last the above approach would be clearer to find the issue (a proxy or something in the middle could anyway mislead the whole thing).

A reference: http://www.w3.org/Protocols/rfc2616/r...
Photo of Nathan Simonis

Nathan Simonis

  • 3 Posts
  • 0 Reply Likes
I added Accept-Encoding: identity;q=1.0, *;q=0, but it didn't change anything. I'm working with a SaaS that supports server side scripting, so the script runs server side before the page loads (this is done to hide calls to the Weather Underground API). Client side calls to same SaaS API RequestURL function result in the same encoding issue. This is sounding like it is an issue with the SaaS. I may have to change my design to allow the Weather Underground API calls to be made from the client using jQuery.