Re: Support for compression in XHR?

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

Received on Friday, 12 September 2008 00:23:07 UTC