More content negotiation

Koen wrote a long time ago:
>Perhaps even more importantly, having a safe way to disable the
>client/proxy side `variant selection engine' would allow service
>providers to use special purpose variant selection algorithms that
>cannot be `run' on client-side `variant selection engines'.  One
>example of such a special purpose algorithm is negotiation around
>known bugs in user agents based on the user-agent header.

I'm not a big fan of any scheme that purposely defeats the ability of a
proxy to serve cached objects because of user-agent rendering differences.
However, some people seem intent on doing this, so it has to be addressed.
But, I'm not convinced any HTTP headers or protocol changes can overcome or
signifigantly reduce the performance hit of the existance of opaque
variant-picking schemes.

I'm also not a fan of any client-side variant-picking algorithm going into
the protocol.  What's the point?  Defining variant-picking algorithm for
servers allows the variant choices to be reproduced by proxies, but what
does defining the client-side variant-picking algorithm gain?

If some server has variant-picking schemes that cannot be represented in the
scope of content negotiation, why dont they just send (on base URI requests)
non-cachable redirects to the appropriate variant URI?  A caching proxy can
then choose not to access the redirected-to variant based on that variant
already being present in the proxy's cache.  This behavior requires no flag
form the proxy to indicate the presence of variants in the requestor proxy's
cache, no directive from the server to the proxy to indicate that things
behave outside the scheme of the (content negotiation portion of the)
protocol, and no unnessary associations with the base URI to be saved in the
proxy's database (like additional URI information or a list of user agent
headers or a list of any arbitrary header for that matter).  It requires no
changes to existing clients or proxies.  It requires no more requests than
reactive negotiation.

The only downside is a 100-byte body that says "This resource is located at
http:/blahblahblah" instead of Koen's proposed "20x No Body" scheme.  Not a
biggie.

PS:  When I say base URI, I mean the negotiable resource, the "/index" as
opposed to the variant "/index.html" or "index.fr.html.zip"
-----
Dan DuBois, Software Animal             http://www.spyglass.com/~ddubois/
		I absolutely do not speak for Spyglass.

Received on Thursday, 28 December 1995 07:24:09 UTC