- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Sat, 13 Apr 1996 20:44:47 -0700
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-caching@pa.dec.com, jg@w3.org
> [...] >>If there is no other available information, Last-Modified is sufficient >>and can be assumed to BE sufficient for all caching purposes. If it >>isn't sufficient, the provider of that information MUST supply something >>more reliable than Last-Modified (which itself is reliable 99.9999% of >>the time). > > My point against allowing Last-Modified values (generated by 1.0 servers) > to combine ranges is not so much that it is unreliable in 0.0001% of the > cases, but that there is nothing in the 1.0 spec that _disallows_ a 1.0 > server to provide resources for which combining ranges using Last-Modified > is 99.9% unreliable. You can require the above MUST for 1.1 servers, but > not for 1.0 servers. So what? We already know 1.0 is not reliable in the face of caching. Content providers that want reliable caching must upgrade to HTTP/1.1. What must not happen is for service to degrade for HTTP/1.1 users when talking to HTTP/1.0 servers. We can safely assume that HTTP/1.0 is a land of optimism because anyone with a worry should upgrade -- if they don't, then they will suffer the consequences. This has nothing to do with protocol compatibility. >>I am not using double-quotes around the change-token (what was being >>called the validator) because it is generally better to avoid quoted >>values when they can be avoided (due to problems of charsets and the >>possibility of embedded quotes and the problems of whitespace lossage >>by gateways to non-HTTP environments). In any case, I see no advantage >>in giving people extra rope to hang themselves when the thing must be >>a computed function anyway in order to be reliable. > > Side remark: I think the chance of CGI authors hanging themselves writing > functions that make tokens are is greater than the chance of CGI authors > hanging themselves writing functions that make quoted strings. When making > tokens, you have to know all about which characters cannot be in tokens > because they are in `tspecials'. I certainly don't know all tspecials by > heart. How many CGI authors will not bother to look it up? I disagree. I have seen more people, in practice, hang themselves with a quoted string than with a more restricted syntax. We could make an exception syntax like <"> <any CHAR except CTLs, <">, and SP> <"> but that is just as likely to be screwed up as token. >> If the Request-URI corresponds to two or more variant representations, >> then a variant-id MUST be included in the entity-id to distinguish >> between those representations. > > I disagree to this MUST: the alternates in transparent content negotiation > do not have variant-ids in draft-holtman, they have alternate URIs. The > above MUST does not allow transparent content negotiation according to > draft-holtman on top of 1.1, and we have consensus that this must be > allowed. That simply is not true. You can add variant-ids (or ignore them) to the Alternates stuff with no impact to transparent negotiation. Deriving a variant-id when you already have a location is trivial -- it is just the difference between the specific URI and the common URI (with a mapping to a suitable syntax). There is absolutely no justification for making the choice between negotiation mechanisms exclusive, nor is it a good idea to force providers to choose one in exclusion of the other. A single resource can and should support both EID and Alternates. > I strongly object to a requirement that varying resources which use the > Alternates header to indicate variance MUST include variant-ids. Such a > requirement would be easy to satisfy for preemptive negotiation, but very > painful for reactive negotiation, where a second request is done on the > actual URI of the alternate resource (which may even live on a different > server). ... This has no impact on the second response in reactive negotiation because the second response is a different Request-URI, and your argument simply does not apply. Nor do any of the suggested changes. >> The change-indicator is used to indicate changes to the content of >> the resource uniquely identified by the Request-URI and variant-id. >> The change-indicator value SHOULD change when the content of an entity >> changes and SHOULD NOT change when the content remains the same. >> When the value changes, it MUST change to a value not already used for >> that entity within a timeframe for which there may still exist >> legitimately cached entities with the same change-indicator value. > > As Jeff has pointed out in his more theoretical caching models, one can > legitimately store in cache memory a stale response forever. So your > requirement above is better expressed as: > > When the value changes, it MUST change to a value not already used. No, the wording is correct as it stands -- the origin server can and will decide the scope of the timeframe. In most cases, it will be "forever", but that is not necessary in the protocol. >>As far as I can tell, there is no reason that a private cache should >>be prevented from using a weak validator comparison, even for byte range >>insertion. > > As far as I can tell, the privacy requirements of a response are orthogonal > to the server's ability to supply a strong validator. So a private cache > should also be prevented from using a weak validator comparison for > combining ranges. No, there is no way for the private cache to have a stored entity which is different from that of the client, and therefore it is always safe for a private cache to handle partial GET requests. > I do not agree to removing validators if we can't settle all issues > connected to them in 24 hours. Removing validators would make accessing > varying resources way to expensive. We have consensus that the 1.1 Vary > header should be good enough to support multi-lingual servers. Removing > If-Invalid would make use of Vary so expensive that it is hardly usable. Then it will be hardly usable. .....Roy
Received on Sunday, 14 April 1996 04:03:13 UTC