- From: Nicholas Shanks <contact@nickshanks.com>
- Date: Thu, 7 Jun 2007 20:17:45 +0100
- To: "Robert Brewer" <fumanchu@amor.org>
- Cc: ietf-http-wg@w3.org, Web-Kit Dev <webkit-dev@opendarwin.org>
- Message-Id: <E9DF2056-257D-4836-9854-E06B5A49DC47@nickshanks.com>
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.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 7 June 2007 19:47:29 UTC