Mark Baker wrote, > On Sun, Jan 26, 2003 at 08:41:25AM +0000, Miles Sabin wrote: > > I disagree. Abstract Resources aren't needed for HTTP caching. > > Nothing would break if you thought of it as operating in terms of > > entities with URIs telling a cache where to go to get a fresh > > entity when the current one is stale. > > Try to explain the role of the HTTP Vary header, without saying > "resource", "thing", "that which a URI identifies", or the > equivalent. The same way RFC 2616 does. From 12.1, The Vary header field can be used to express the parameters the server uses to select a representation that is subject to server- driven negotiation. See section 13.6 for use of the Vary header field by caches and section 14.44 for use of the Vary header field by servers. tho' I'd prefer to replace "representation" with "entity". Interestingly, 14.44 doesn't mention resources at all, and barely mentions representations, prefering instead to talking about responses. "Resource" only appears twice in 13.6 and in both cases could (actually, I think _should_) be replaced with "URI" without loss. Of course, a variation implies a variation on _something_. But it doesn't follow that that something is an abstract resource in the REST sense. In practice Vary: is primarily used to indicate to caches that an origin server will select one of a collection of internationalized documents on the basis of an Accept-Language: request header. If you want to think of such collections as abstract resources, be my guest. I'd rather not, because collections of documents, just like individual documents, can move or be replaced, and that's not consistent with the REST worldview. Cheers, Miles
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format