Re: Support for compression in XHR?

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.

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.

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.

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.

MikeA

<snip>
>> My assumption here is that "component" = XHR and "application =
>> "browser" (or some other hosting environment).
>
> Sorry, in my initial reply I meant "application" as the one that has
> specific knowledge of the data and servers that are being involved. In this
> case that means the webpage. I'll try to clarify:
>
> / Jonas
>
</snip>


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

Received on Thursday, 11 September 2008 20:21:57 UTC