- From: Kris Zyp <kris@sitepen.com>
- Date: Tue, 9 Sep 2008 17:35:17 -0600
- To: "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Geoffrey Sneddon" <foolistbar@googlemail.com>, "Dominique Hazael-Massieux" <dom@w3.org>, "Boris Zbarsky" <bzbarsky@MIT.EDU>, <public-webapps@w3.org>
>>> 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. Encoding capability isn't really a state in the HTTP sense, since it is presumably an immutable characteristic of the server, rather than a mutable state of an application (the latter being what HTTP abhors). It seems completely analagous to Accept-Ranges which works exactly the same (communicates the server's ability to handle Range requests and what range units are acceptable). Kris
Received on Tuesday, 9 September 2008 23:36:37 UTC