W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

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

From: Nicholas Shanks <contact@nickshanks.com>
Date: Thu, 7 Jun 2007 20:17:45 +0100
Message-Id: <E9DF2056-257D-4836-9854-E06B5A49DC47@nickshanks.com>
Cc: ietf-http-wg@w3.org, Web-Kit Dev <webkit-dev@opendarwin.org>
To: "Robert Brewer" <fumanchu@amor.org>
On 7 Jun 2007, at 19:46, Robert Brewer wrote:

> 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

That seems to differ from current practice, e.g. we don't have:
Accept: text/html;lang=fr
but use a separate header. Content-Language isn't appropriate for  
many types of resource, but still it's there.

> 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.

the later requests *are* the appropriate place (I shouldn't have used  
CSS as an example in the original suggestion) but also the author of  
the referring file (could be a javascript, for example) may not have  
control over the images' server (e.g. adverts loaded from third party)

> 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.

it wouldn't. the headers for A would influence what resources were  
requested for B, because different images would be referenced in the  
file returned by request A.

- Nicholas.

Received on Thursday, 7 June 2007 19:47:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC