Re: Support for compression in XHR?

On Sep 11, 2008, at 22:59, Jonas Sicking wrote:

> Wouldn't a better solution then be that when the web page sets the  
> flag on the XHR object the browser will always compress the data?  
> And leave it up to the web page to ensure that it doesn't enable  
> capabilities that the web server doesn't support. After all, it's  
> the web page's responsibility to know many other aspects of server  
> capabilities, such as if GET/POST/DELETE is supported for a given URI.


This is the approach I've taken with Validator.nu. Validator.nu  
support gzipped request bodies. If someone reads the docs for the Web  
service API so that they can program client code for the service, they  
should notice what the documentation says about compression.

There is, though, the problem that now compression support is part of  
the published API as opposed to being an orthogonal transport feature,  
so removing incoming compression support from Validator.nu (e.g. if  
bandwidth were abundant and CPU were the bottle neck) would break  
existing clients. This is not a problem with same-site XHR, though,  
when the same entity controls the server and the JS program performing  
the requests and can update the JS program immediately.

(Validator.nu also advertises Accept-Encoding: gzip via OPTIONS, but  
I'm not aware of any client automatically picking it up from there.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 12 September 2008 09:26:51 UTC