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
