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

[Nicholas Shanks]

On 7 Jun 2007, at 23:07, Rob Burns wrote:

> PS, again my suggestion is for the client to request specific pixel  
> dimensions for the media not the ppi/dpi/cmpi) If the the UA is in  
> an environment with multiple displays or multiple resolution output  
> of any kind it can use that in determining the pixel dimensions to  
> request. Otherwise, it can re-request the image for the new output  
> device..

Yeah, your earlier example used ppi, not dimensions. Could you please  
provide a new example of what you envisage, with all the relevant  
back-and-forth headers enumerated, although I think what I suggest  
below is better than sending any pixel data to the server. Let me  
know what you think on this, Rob:


On my previous CHOICES suggestion:

Thinking further about caching, creating a new request type that was  
a hybrid of GET and HEAD was a bad idea. A better way would be to use  
GET but supply a new header that disables content negotiation (which  
is what I was really trying to do, though I didn't quite realise it),  
forcing a 406 if any content negotiation would otherwise have been  
performed. The 406 would then be automatically handled (not presented  
to the user). It puts all choice in the hands of the client/user and  
not the server/author.

I expect it would go something like:

"Negotiation: disable"


So what happens now still works:

Old client requests image /foo and provides no disabling header
Server sends back 'optimum' resource foo, as best it can determine,  
taking into account quality-of-source and file length
Object is cached by proxy
Client uses result returned


New behaviour also works:

New client requests /foo and asks for content negotiation to not  
occur by including a new header.
Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.

-or-

New client requests /foo and asks for content negotiation to not  
occur by including a new header.
Server detects multiple resources to choose from, sends back a 406  
immediately
Result is not cached by intermediate proxies.
	(A smart proxy could even clear it's cache whenever it sees a URI  
return a 406,
	as it now knows that there are multiple representations for that  
resource and
	that it's previous cached object would not be valid for all clients!)
Client parses (scrapes) the 406 response body (which will have to be  
more clearly spec'ed)
Client issues a new request for the choice it wants, using exact URI,  
can omit new header this time
Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.


The cost is one round-tip to the server per negotiable URI + one  
header on all initial resource requests.
The saving is no need to send any Accept-* headers anymore.


So basically:
• Content negotiation is a good thing for users
• Server-side negotiation defeats caching and gets so long-winded  
that usually a wildcard is sent anyway (e.g. Accept-Encoding)
• Client-side negotiation allows caching of the final URI, as long as  
the negotiable URI is not cached and a bad choice returned by the proxy.
• Client-side negotiation can be transparent to the user, a 406  
response doesn't need to be presented
• This can all be implemented as an extension to HTTP 1.1, and in a  
future version of HTTP, the new header can be made implicit.
• Whilst there could also be a "Negotiation: enable" for HTTP 1.2 or  
2.0, simply sending the Accept-* headers would be enough to indicate  
that you wanted server-side negotiation.
• The response could also include a Suggest-Location: header for  
clients that aren't able to/don't want to parse the choices and  
select one. This would probably be what the server would have picked  
if it had done negotiation anyway.
• Also, a new response code (418 Client Selection Required) could be  
used instead of a 406, with an XML body that the client is not  
allowed to show to the user. This would be much better than scraping  
a 406, more extensible in future etc etc. Clients without an XML  
parser just use the server's suggestion.


- Nicholas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20070608/905ce899/smime.bin