- From: Paul Burchard <burchard@cs.princeton.edu>
- Date: Wed, 05 Jun 1996 00:15:17 -0400
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: burchard@cs.princeton.edu
OK, this is my last message on this topic. Roy T. Fielding <fielding@liege.ICS.UCI.EDU> writes: > the cache is fully capable of understanding that the > 503 error is not the same as a 200 OK; URI's don't vary -- > response representations do. Could you explain one thing: if there are cached representations with different response codes for the same URI, and Vary headers are allowed vary by response code, couldn't it easily happen that more than one cached representation (though at most one per response code) matches the request? And if so how should the cache choose among the matching response codes? > Server-driven negotiation occurs when the server varies the response > entity for a particular method*identifier*request-entity*status-code > combination according to the value of the request-header fields, or > something external to the normal request parameters above (the "*" case). Sounds clear enough...but is it true? What about request headers with "required variation", as Koen brought up (e.g. Range)? It seems that Vary really has to do with a fairly small set of request headers. jg <jg@w3.org> writes: > your definition of required variation header > requires understanding of the entire document [...]. > This is worse than any disease the current text has. Yes, point taken. It would be better to reverse the implication, making "required variation" an a priori designation (like "request header") which instead imposes requirements on the header spec (i.e. to define what that header's required variation is). In any case, the subsequent discussion seems to have confirmed that the worms in this can have real teeth. :-) -- --------------------------------------------------------------------- Paul Burchard <burchard@cs.princeton.edu> ``I'm still learning how to count backwards from infinity...'' ---------------------------------------------------------------------
Received on Tuesday, 4 June 1996 21:17:54 UTC