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

Re: Support for compression in XHR?

From: mike amundsen <mamund@yahoo.com>
Date: Thu, 11 Sep 2008 23:15:13 -0400
Message-ID: <b548df650809112015r7a7776f5w73b96ce7db771e9a@mail.gmail.com>
To: public-webapps@w3.org


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. 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.
> What does "client", "component" and "application" mean in the above
> paragraph?
> / Jonas

Received on Friday, 12 September 2008 03:15:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC