- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 09 Sep 2008 15:32:05 -0700
- To: Dominique Hazael-Massieux <dom@w3.org>, public-webapps@w3.org, Stewart Brodie <stewart.brodie@antplc.com>
Stewart Brodie wrote: > Dominique Hazael-Massieux <dom@w3.org> wrote: > >> Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : >>> HTTP has Content-Encoding and Transfer-Encoding, no? No special effort >>> on the part of XMLHttpRequest is needed to make use of those, as long as > >>> the underlying HTTP implementation supports them. >> 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? > > I disagree with any proposal that allows the application layer to forcibly > interfere with the transports layer's internal workings. Use of encodings, > persistent connections, on-the-fly compression are entirely internal to the > transport mechanism. This is fine for transport mechanism where capability negotiation is two-way. However a relatively common use case for the web is transferring things through HTTP, where the HTTP client has no way of getting capability information about the HTTP server until the full request has already been made. / Jonas
Received on Tuesday, 9 September 2008 22:34:04 UTC