W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Support for compression in XHR?

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 11 Sep 2008 12:59:53 -0700
Message-ID: <48C978B9.5010809@sicking.cc>
To: mike amundsen <mca@amundsen.com>
CC: public-webapps@w3.org

mike amundsen wrote:
> Jonas:
> 
> Good points.
> 
>> Wouldn't a better solution then be that when the flag is set always
>> compress? And leave it up to the application to ensure that it doesn't
>> enable capabilities that the server doesn't support. After all, it's the
>> applications responsibility to know many other aspects of server
>> capabilities, such as if GET/POST/DELETE is supported for a given URI.
> 
> My assumption here is that "component" = XHR and "application =
> "browser" (or some other hosting environment).

Sorry, in my initial reply I meant "application" as the one that has 
specific knowledge of the data and servers that are being involved. In 
this case that means the webpage. I'll try to clarify:

Wouldn't a better solution then be that when the web page sets the flag 
on the XHR object the browser will always compress the data? And leave 
it up to the web page to ensure that it doesn't enable capabilities that 
the web server doesn't support. After all, it's the web page's 
responsibility to know many other aspects of server capabilities, such 
as if GET/POST/DELETE is supported for a given URI.

>> Or is there a concern that there is a transparent proxy sitting between the
>> browser and the server that isn't able to deal with the compression? If so,
>> will the OPTIONS proposal really help? If it will, how?
> 
> I'm pretty sure the "Accept-Encoding" HTTP Header is transport-level
> (not hop-by-hop). If it is, then proxies should not be an issue.

That is my understanding too.

/ Jonas
Received on Thursday, 11 September 2008 20:01:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT