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

Re: Support for compression in XHR?

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 12 Sep 2008 17:27:26 -0700
Message-ID: <48CB08EE.8020808@sicking.cc>
To: mike amundsen <mamund@yahoo.com>
CC: public-webapps@w3.org

mike amundsen wrote:
> Jonas:
> <snip>
>> 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.
> </snip>
> Yes, if a flag is employed, the application code is in control.
> Again, I proposed the flag as a way to by-pass any extra traffic
> (OPTIONS call) to the server before starting the upload. Because I
> assumed the OPTIONS call would be required in order to support
> compressing uploaded bodies. This maybe a poor assumption on my part.
> <snip>
>> 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.
> </snip>
> Yes.
> <snip>
>> 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).
> </snip>
> Again, my assumption of the need for OPTIONS may one of the serious
> flaws in initial my proposal.  If determining compression for uploads
> is handled the same way determining compression for response bodies,
> then no OPTIONS call would be needed.

Honestly, I don't know if an OPTIONS request would be needed, or if we 
would be allowed to use the response headers from a previous request.

> What about this as a new proposal:
> When handling the upload of a file, the HTTP Headers collection (sent
> by the server to the client) for the "X-Accept-Compression-for-Upload"
> header. If it exists, the header is parsed to see if a compression
> format supported by the client is present in the header. If one is
> present, the file is compressed using that format when it is sent to
> the server. If no supported format is found or the header is not
> present, the file is sent to the server without any compression.

How exactly would this work? The browser doesn't receive any response 
headers at all until the full request is done, and the upload is part of 
the request.

/ Jonas
Received on Saturday, 13 September 2008 00:29:32 UTC

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