- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 11 Sep 2008 12:59:53 -0700
- 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 UTC