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: Fri, 8 Jun 2007 12:07:33 +0100
Message-Id: <0265F824-0618-4883-A7B1-418413D01CDB@nickshanks.com>
Cc: ietf-http-wg@w3.org
To: Peter Speck <speck@vitality.dk>, WebKit Development <webkit-dev@lists.webkit.org>
Hi Peter.

I recommend you take a look at what Larry Masinter pointed out. It  
becomes clear that all of this has already been solved 9 years ago,  
but because it (apparently) isn't enabled in Apache by default, I and  
many others never even realised it existed:

> Content negotiation for HTTP based on parameters beyond MIME types
> was the focus of a significant amount of IETF work, including
> RFC 2295 ("Transparent Content Negotiation in HTTP")
> RFC 2296 ("HTTP Remote Variant Selection Algorithm -- RVSA/1.0")
> and a set of 'media features' (including resolution, screen
> size, pixel depth, etc.) in a Media Feature registry
> (RFC 2506, BCP 31).

http://www.ietf.org/rfc/rfc2295

Basically the client adds a "Negotiate: trans" header to the GET  
request, and initiates transparent (to the user) content negotiation  
(TCN). The server sends back a 300 response with a list of choices in  
an Alternates header, the format of which is defined in the RFC. The  
client then issues a new GET request for the one it wants, without  
having to send any environment information (dpi, &c.) to the server.

Clients can also send a few (small) Accept-* headers and ask the  
server to take an educated guess, but still return the list of  
Alternates along with it's guess, which could save round trips if the  
client decides that the server's guess was good enough ("the 150dpi  
would have been best for me, but I'll just use this here 200dpi image  
you've already sent"). If the resource is non-negotiable, the  
Negotiate header is ignored by the server and nothing changes.


In light of this, I suggest that WebKit developers (including me if I  
get the time) look into implementing this set of RFCs, and ignore all  
previous suggestions.
It seems we've been in the classic chicken-and-egg situation since  
1998, where clients don't implement it because servers don't have it  
turned on by default, and servers don't have it enabled because there  
are no client implementations to test against. Website owners are  
left none the wiser, and while a few server-side negotiation, most  
don't find it reliable enough to use, and have things like flag icons  
on their home page to choose your language.

Apple members should discuss with the IETF the addition of device- 
pixel-ratio to the Media Feature registry. This will allow TCN for  
<img> and <object> elements containing visual media, and anywhere  
else where CSS does not apply.
I also suggest a "High-Res: Part III" blog post on webkit.org to draw  
attention to this feature and get more web developers aware of and  
using TCN, which I think is the biggest hurdle (implementing it won't  
be as hard).

- Nicholas.

Received on Friday, 8 June 2007 11:07:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:10 GMT