RE: [webkit-dev] Accept- & Content-Resolution headers proposal

Peter Speck wrote:
> On 07/06/2007, at 19:18, Nicholas Shanks wrote:
> > An asterisk would be implied because there will always be
> > a closest match, even if the only resolution is lower than
> > a client requested. (i.e. There would be no 406 errors
> > because of this header)
> 
> If we allow a range, why not? Then the UA would be able to say: "I  
> dont want any media for dpi > 100". Cell phones could use this to  
> avoid download of huge files.

If the proposal exists to minimize bytes transferred, wouldn't a new
"Accept-Length" header be more appropriate and useful for a wider set of
media types? The server could then vary the representation returned in
order to meet the restriction given by the client (or return 406 Not
Acceptable).

If the issue is actually image resolution and not octets, a media-range
parameter in the Accept header seems to be a more appropriate place to
implement it; for example:

    image/jpeg;max-dpi=100;q=0.5

Regardless, I don't see how either one should involve any changes to the
request for a CSS file. The user-agent will fetch the CSS resource,
execute the CSS rules, and then fetch additional resources in separate
HTTP requests. Those latter requests seem to me to be the appropriate
place to specify restrictions on the representations returned. I can't
think of any precedent for using the headers of request A to influence
the characteristics of the response to request B--that's too tight a
coupling between HTTP and CSS, in my humble opinion.


Robert Brewer
System Architect
Amor Ministries
fumanchu@amor.org

P.S. Hello, ietf-http-wg list, I'm the author of CherryPy 3, which
includes an HTTP server that is arguably the most used in the Python
web-framework space these days. I'll try to keep quiet and learn from
here on out. ;)

Received on Thursday, 7 June 2007 18:49:39 UTC