Indicating acceptable request entity encodings (was Re: Support for compression in XHR?)

(Restating for the HTTP working group)
Is it reasonable for a server to indicate support for decoding additional 
content encodings of the request entity body with the Accept-Encoding 
header? That is, can a server advertise support for decoding gzip in 
responses, such that a user agent could compress subsequent request 
entity-body using content-encodings supported by the server? Can a server 
include a response header:
Accept-Encoding: gzip;q=1.0, identity; q=0.5

And then a user agent could compress request entity bodies (and include the 
corresponding Content-Encoding header). RFC 2616 does not seem to prohibit 
the use of Accept-Encoding in response headers, but on the otherhand, it 
only seems to suggest it's use for requests, so it is unclear to me if it is 
usable in this manner. The use of Accept-Encoding in response headers seems 
analogous to the Accept-Ranges response header as far advertising the 
capabilities of a server and seems like an appropriate application of this 
header to me.

Thanks,
Kris


----- Original Message ----- 
From: "Jonas Sicking" <jonas@sicking.cc>
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>
Sent: Tuesday, September 09, 2008 5:00 PM
Subject: Re: Support for compression in XHR?


>
> 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 Wednesday, 10 September 2008 04:28:05 UTC