- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 28 Dec 1995 23:46:21 +0100 (MET)
- To: Daniel DuBois <ddubois@rafiki.spyglass.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Daniel DuBois:
>
>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.
Yes.
>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.
As you explain in your message, with a 302 `moved temporarily'
redirection scheme, you can already do opaque variant picking at the
server side for the cost of one RTT if the picked variant is in the
cache. So there is not that big a performance hit already.
`Real opaque content negotiation' will improve over 302 redirection by
1) making the availability of variants explicit, so that the
user can pick another variant if desired
2) improving on the cost of the 302 redirection scheme if the
selected variant is _not_ in the cache: 302 needs 2 RTTs for this
case, real opaque negotiation will only need 1 RTT in most cases.
>I'm also not a fan of any client-side variant-picking algorithm going into
>the protocol. What's the point?
The client (the user agent) doing reactive negotiation is the point.
> [Description of opaque `negotiation' doing 302 redirects deleted to
> save space]
>Dan DuBois, Software Animal http://www.spyglass.com/~ddubois/
Koen.
Received on Thursday, 28 December 1995 14:50:02 UTC