Does using GZIP on an application/json response stream to an Ajax request cause problems? This question has been coming up a lot in Tapestry, to the point that we had to explicitly turn it off. For some users, on some combination of server and client (not always the ones you'd expect), the response comes out garbled. It's been hard to diagnose, but it almost seems that the Content-Encoding: gzip header is lost, leaving the browser to parse the compressed response as uncompressed (however, this theory is far from confirmed).
None of this occurs with traditional, non-XHR, requests and responses. Is it tied to XHR or to the content type (application/json)? Could this be a bug in Prototype? On Windows only? It's been hard to track down the triggering environment for this, but it appears that my initial guess (a proxy server in the middle) doesn't bear fruit.
Have other app or framework developers confirmed this? If so, what was your approach to addressing this. I know I'd like to see full GZIP compression for all that JSON content.
3 comments:
I am aware of a (possibly) similar problem with Apache XML RPC. The main problem there is the ambiguous definition of the content-length header: Does it specify the length of the compressed request/response or the length of the uncompressed?
@Johen:
Definition of content-length is quite precise about it. Perhaps you should read the RFC first?
(spoiler: it's amount of bytes in response body that you need to download).
@kkll2:
The specification defines the content length as "the size of the entity-body". This is crystal clear in the absence of compression. If compression is used, I fail to understand this as precise. Sorry, if it's my sillyness, but I'd be quite happy if you have a pointer that clarifies that, apart from your words.
Post a Comment