In response to my question:
>Is a caching proxy permitted to cache HTTP headers that it doesn't
Roy Fielding wrote:
>Yes. In fact, it must.
I don't understand why a cache "must" do this... Can you explain why this is
necessary? Or, perhaps you are suggesting that a cache author can survey all
the defined headers for a particular version of HTTP and then decide that
the cache doesn't need to worry about (or "understand") some of them... My
question really applies to the behaviour of a cache in the face of a header
which is *not* defined in whatever level of the protocol that the cache
thinks it understands.
If a cache is "required" to cache headers that it doesn't understand even if
those headers are not defined in HTTP specifications, it would seem that
experimentation with new headers becomes exceptionally dangerous in some
cases (see my previous mail). If caches are allowed to cache stuff from
protocol versions that they don't understand (i.e. a 1.0 cache dealing with
V1.1 or V2.0 stuff) then it sounds like we've got a real mess and a "chicken
before the egg" race. i.e. Server writers won't support something like State
-Info until clients generally support it. Clients won't support it until
servers do, and *everyone* will be afraid to support State-Info until caches
generally support it.
I would prefer if caches would not cache objects that contained unknown
headers under any conditions. If this can't be the case, can we at least
have a requirement that caches must not cache responses that carry protocol
versions whose defined elements aren't understood by the cache.