- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 09 Sep 2008 16:00:42 -0700
- To: Kris Zyp <kris@sitepen.com>
- CC: Geoffrey Sneddon <foolistbar@googlemail.com>, Dominique Hazael-Massieux <dom@w3.org>, Boris Zbarsky <bzbarsky@MIT.EDU>, public-webapps@w3.org
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
Received on Tuesday, 9 September 2008 23:02:39 UTC