- From: Shel Kaphan <sjk@amazon.com>
- Date: Mon, 5 Feb 1996 14:18:30 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: "David W. Morris" <dwm@shell.portal.com>, HTTP Caching Subgroup <http-caching@pa.dec.com>
Jeffrey Mogul writes: > > Say a client (or another cache) has two such responses R1 and R2 > for the same resource, and so must decide which of them to use > (if any) without doing a conditional GET (i.e., without checking > the validator), or to decide which is the optimal validator > to use in a conditional GET. ... > Otherwise, it has to decide which of the two responses is more > "believable." That is, if they are both still fresh, but have > different bodies, then the server must have been too optimistic when > assigning the Expires: value to one of them. ... > > So the problem is to assign an ordering to the *responses*, not > the validators, that allows the client/cache to choose the "best" > one. > > After discussion in todays subgroup meeting, Jeff Mogul suggested > that the Date: header value could be used in conjunction with the > validator to establish the order. > > Exactly. Although I actually first proposed this on the list several > weeks ago. Note that the Date: is in the *response* headers that > came from the origin server, NOT (as Shel seems to have believed) > in the requests! I believe (or believed, depending on the answer to questions below) that to use Date as a sequencer, the Date in the response headers would be used, and passed back (somehow) in subsequent requests. But I think there is a deeper confusion here. What is at issue is the semantics of conditional GET. Do conditional GETs always have to be forwarded all the way to the origin server in all cases, even if a cache contains a fresh response with a matching validator? If so, conditional GETs will often be more expensive than unconditional GETs that can be answered by a cache. If so (as an aside), I think we should not call them "conditional GETs", since that seems to imply that the overhead is <= the overhead of a normal GET. Maybe we should call them "validating GETs" instead. I suppose it doesn't make sense for validating GETs to be answerable by a cache, since the requestor must already have a copy of the object (else why would it have the validator?), and so, if it believes the document to be fresh, why would it be validating it unless it really wanted to check with the origin server? If validating GETs always must be forwarded all the way to the origin server, the question is simply which validator should a cache use when attempting to validate a resource. It only makes sense for a cache to send a validator for an object it contains a copy of, so if it has to make a choice, the response's Date could be used as the criterion as discussed. What follows is moot if all validating requests (those containing validators) must be forwarded all the way to the origin server: You are talking above about a different scenario than what we were considering. We were talking about a situation in which a cache contains a single "best" response so far, and is presented by a client with a validator that does not correspond to the entry already in the cache. In this case, although the entry in the cache may still be fresh and may in fact be the "current version", without additional state the cache cannot respond to a conditional request using the fresh entry. This is why I said that in order to make use of Date as a sequencer, it would be necessary for clients to pass back the Date and Validator corresponding to the objects they wanted to validate. Then the cache could know if the date (corresponding to the object referenced by the validator) in the request headers was after or before the date in its cached entry. If before, the cache could respond with its fresh entry. If after, the request must be forwarded. And it was following this that I made the other suggestions about heuristics to avoid it. But it's all moot if validating requests must all be forwarded all the way. --Shel
Received on Monday, 5 February 1996 22:49:21 UTC