Re: ETags vs Variants, was: Revising RFC2616 - what's happening

fre 2006-10-20 klockan 17:05 +0200 skrev Julian Reschke:

> I would say that if the value for "Vary" changes between to HTTP 
> requests, the sever implementation/configuration has somehow changed, 
> and a proxy should invalidate all cached entries for that URI.

Yes, that is what is natural to implement to the cache, but the RFC
unfortunately says nothing on the subject.

Some seem to argue that both should be cached, and the most recent match
returned by the cache. Which I personally think is both bad, nearly
impossible to implement efficiently and may results in non-deterministic
results to the end-user when there is conflicts.

Another related but less clear example which came from a server vendor
is

Vary: Accept-Language

and on another variant

Vary: Accept-Language, Accept-Encoding

seen where one language is only available in identity encoding while
another language is available in both gzip and identity encoding. The
reasoning here is that Vary lists the headers the server actually looked
for when determining which variant to return, not the headers it may
look for on all variants of the URI.

> Yep. Maybe we can improve proxy support by improving the spec text.

No doubt about that. Had to read the RFC many times before things
started to fall into place. And if every proxy, browser and server
vendor (and their coders) have to do the same no doubt there will be
broken implementations.

> "just"? The user follows a link and gets a completely misleading error 
> message, although the server works just fine.

User-agents not behaving well to the user is not non-compliance to the
protocol specifications. And if I am not mistaken the user can select to
save the file to disk instead of opening it directly and then open it
separately outside of the browser.

How content is displayed is entirely outside of the specifications, for
good reasons.

But such issues surely drags down the deployment of affected protocol
features.

Regards
Henrik