Re: Support for compression in XHR?

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.

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.

No flags. No OPTIONS call.

Mike A

Received on Friday, 12 September 2008 04:02:22 UTC