Re: Support for compression in XHR?

mike amundsen wrote:
> Jonas:
> 
> In the text below I meant:
> 
> client = browser (or other hosting environment)
> component = xmlHttpRequest (or XHR, etc.) object available as part of
> the client/environment
> application = code running within the client/environment (i.e. script
> that can get an instance of the component, etc.)
> 
> Mike A
> 
> On Thu, Sep 11, 2008 at 11:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> mike amundsen wrote:
>>> Jonas:
>>>
>>> <snip>
>>>> Your proposal with the flag seems like it's reverting to the "having to
>>>> know" case, since you'd want to set the flag if and only if the server
>>>> supports compression to avoid extra overheads, while still taking
>>>> advantage
>>>> of compression when the server supports it.
>>> </snip>
>>>
>>> Well, seems I've muddled things a bit by mixing concerns of
>>> cross-domain, compression support, and security in an overly simple
>>> suggestion.
>>>
>>> My intention was to allow clients to decide if they want to *attempt*
>>> compression, not *force* it. Thus, it could be exposed as an flag in
>>> the component in an effort to cut down on extra traffic between client
>>> and server.

Wouldn't that mean that it's the application (i.e. web page) and not the 
client (i.e. browser) that decides to attempt compression or not? I.e. 
the browser wouldn't try unless the web page had told it to do so.

>>> If the flag is set to "false", don't try query the server
>>> to see if it supports compression. This is on the assumption that a
>>> client must execute an OPTIONS call in order to discover if the server
>>> supports compression on uploads.  This model would make the whole
>>> conversation transparent to the application developer, but not the
>>> component developer.

Not really though, since it's the application (i.e. web page) that needs 
to set the flag in order to get compression.

It seems like the difference between having the web page fully decide 
and what you are proposing is basically the ability to fall back 
gracefully if the web page thought that compression is available when it 
is not.

This at the cost of the overhead of always making an OPTIONS request 
before attempting compression.

(not saying if this is good or not, just trying to make sure I 
understand the proposal).

/ Jonas

Received on Friday, 12 September 2008 03:43:10 UTC