Klaus Weide:
>
[...]
>Checking for an inconsistent Content-Location still may make sense.
>I also had this in mind (from RFC 2068, 13.5.2):
>--- begin excerpt ---
> A cache or non-caching proxy MUST NOT modify any of the following
> fields in a request or response, nor may it add any of these fields
> if not already present:
>
> o Content-Location
> o ETag
> o Expires
> o Last-Modified
>--- end excerpt ---
>
>But 10.2 4.a and 4.f (adding Content-Location and modifying Etag) are
>in violation of that prohibition anyway, if the algorithm is running
>on a proxy instead of the origin server.
No, they are not:
> [Some ideas come to mind how
>you could talk yourself out of that: (a) State upfront that this is a
>new protocol which sopersedes/obsoletes certain HTTP/1.1 rules;
Yes, this is the way out. TCN is a protocol on top of HTTP/1.1, so it can
provide services beyond 1.1, as long as it is careful that these services do
not break 1.1 clients.
The construction of choice responses in proxy caches is one such service.
This service is only performed for requests by negotiation-capable user
agents on transparently negotiable resources. TCN proxies sometimes ignore
the 1.1 rules in the same way as 1.1 proxies sometimes ignore the 1.0 rule
about the Expires header.
Note that choice response construction was hashed out in early 1996,
_before_ the caching sections in 1.1 were completed. There is a very close
relationship between the two: the 1.1 rules for proxies were written so that
1.1 proxies could take advantage of the extra information (the
Content-Location header) in the responses that TCN servers and proxies would
generate.
Also note that che choice response algorithm takes a response from the
_variant_ resource to answer a request on the _negotiable resource_. If a
plain 1.1 proxy would do this, this would be a far greater sin than just
changing a nonmodifiable header.
[I still have not had time to carefully read all your comments, but I hope
this at least clears some things up. More later.]
> Klaus
Koen.