Kris Zyp wrote:
Well, at least when an outgoing XmlHttpRequest goes with a body, the
spec could require that upon setting the Content-Encoding header to
"gzip" or "deflate", that the body be adequately transformed. Or is
there another e.g. to POST a gzip request with Content-Encoding?
Why can it not just be added transparently by the XHR implementation?
I doubt that it could. An UA implementation won't know which encodings
the server supports.
I suspect compression from the UA to the server will need support on
the XHR object in order to work. I don't think the right way to do it
is through setRequestHeader though, that seems like a hack at best.
I would have thought this would be negotiated by the server sending a
Accept-Encoding header to indicate what forms of encoding it could
handle for request entities. XHR requests are almost always proceeded by
a separate response from a server (the web page) that can indicate the
server's ability to decode request entities.
I think that this would go against the spirit of HTTP. The idea of HTTP
is that it is state-less, so you should not carry state from one request
to the next.
/ Jonas
