(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" <[EMAIL PROTECTED]>
To: "Kris Zyp" <[EMAIL PROTECTED]>
Cc: "Geoffrey Sneddon" <[EMAIL PROTECTED]>; "Dominique
Hazael-Massieux" <[EMAIL PROTECTED]>; "Boris Zbarsky" <[EMAIL PROTECTED]>;
<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
