- From: Bob Wyman <bobwyman@medio.com>
- Date: Thu, 24 Aug 95 15:17:03 -0800
- To: Roy Fielding <fielding@beach.w3.org>, "www-talk@w3.org" <www-talk@w3.org>
-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] -- In response to my question: >Is a caching proxy permitted to cache HTTP headers that it doesn't >understand? 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. bob wyman
Received on Thursday, 24 August 1995 18:29:43 UTC