Re: Support for compression in XHR?

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). If, in reality, it is
the application that is making the HTTP Requests when using the XHR
component, then yes, it is reasonable for the application to handle
any OPTIONS calls and negotiating of compression capabilities.  And,
if the app-level is doing this, XHR can signal compression is to be
used when the flag is turned on and let the app-level sort it out.

> 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. Also,
my suggestion of using OPTIONS for server to advertise support for
inbound compression is not standard. In fact, using "Accept-Encoding"
from the server side might be a misuse of the header.  It was just a
way to get things started.

MikeA

On Thu, Sep 11, 2008 at 2:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> mike amundsen wrote:
>>
>> I think a reasonable approach would be to offer an optional flag to
>> *attempt* compression on the upload.
>> When set to "false" (the default), no OPTION call would be made and
>> the content would be sent w/o any compression.
>> When set to "true" the component can make an OPTIONS call, inspect the
>> result and - if the proper HTTP Header is present in the reply, send
>> using the appropriate compression format.
>>
>> Components could choose to not implement this feature, implement it
>> using only one type of compression or implement it w/ the ability to
>> support multiple types of compression.
>
> 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.
>
> 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?
>
> / Jonas
>



-- 
mca
http://amundsen.com/blog/

Received on Thursday, 11 September 2008 18:40:30 UTC