Re: Support for compression in XHR?

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.

I agree that a better process would be to engineer it in a way that
makes this discovery and choice transparent to the component
developer, too. One way to do this would be to engineer the component
to send the body using the compression method described by the
"X-Accept-Compression-For-Upload" header when present. If the header
does not exist, no problem. If it does, inspect it for a compression
format supported by the component and, if one is found, do the
compression.  With this approach all that is needed is that the server
agrees to send the header to the client (on every request? on OPTIONS
request?) and the component agrees to look for it and honor it if
possible.  No flags. No extra traffic.

Finally, in the case of *X*HR, this header might be allowed
automatically, ignored all the time, or require a pre-flight. That is
probably a different discussion.

MikeA


On Thu, Sep 11, 2008 at 8:20 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> mike amundsen wrote:
>>
>> If i understand you, you're saying the coding of the page (HTML/JS)
>> should 'know' that the target server does/does-not support compression
>> for uploads and handle it accordingly.  I assume you mean, for
>> example, as a coder, I know serverX only allows posting an XML
>> document, while serverY only allows posting urlencoded pairs;
>> therefore I write my HTML page accordingly to prevent errors. This
>> works fine and is the way most pages are built today.
>
> Yup.
>
>> I was thinking that compression on upload could be seen more like
>> compression on download. This is a decision that HTML/JS coders do not
>> have to make as it is handled 'under the covers' between client and
>> server. When clients make a request, they tell the server that they
>> can accept compressed bodies. If the server is properly
>> config'ed/coded it can then compress the response.  and if the server
>> does not support compressed downloads, it just sends the uncompressed
>> version instead. no handshakes. no extra traffic.
>
> This would be idea. I definitely agree.
>
>> In my initial suggestion was attempting to describe a way that the
>> client could act the same way for up-stream bodies. Maybe we don't
>> need any flags at all. If the environment (app code, browser,
>> component?) 'knows' the server supports compressed uploads, it sends
>> the body that way.  I just am not clear on the details of how to
>> support this cleanly without causing extra traffic or breaking
>> existing implementations.
>
> 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.
>
>> Ideally, I think some thing like this is transport-level and should be
>> 'serendipitous' if at all possible instead of requiring special coding
>> on the client.
>
> Agreed. I personally just can't think of such a solution. However there are
> people far smarter than me and with far more knowledge of HTTP on this list,
> so hopefully we can figure something out.
>
> / Jonas
>



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

Received on Friday, 12 September 2008 02:02:57 UTC