- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 10 Sep 2008 10:40:36 -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: >>>> 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). You might be right, I'd have to defer to people that know HTTP better than me. I'm not sure it's a capability of the server, but rather a capability of that particular URI. For example <example.com/foo.cgi> might be implemented using entirely different code from <example.com/bar.php>. / Jonas
Received on Wednesday, 10 September 2008 17:42:34 UTC