Old business: Terminology Are we done? I'll work further on the variant definition. max-age vs. TTL. Checked with Don Eastlake; he thought it didn't matter. Persist default case? Any problems with 04 draft and it. Digest authentication docking. Still don't have time. New business Larry's list. Paul Burchard's message on retry. (problem is real on blind retry. Dave Morris's. 24 hour thing no longer needed. Nit in 8.1.2.2 wording.) Larry to re-revise section 3.5. Paul's detected inconsistency around caching restrictions. (he's right...) If-Unmodified-Since to be added to 5.3 request-header BNF. (Yes.) Are RST's comments on bug in 04alpha document on caching correct? What is correct fix? (Jeff to send fixes). Accept's mxb parameter. Was deleted, but Roy, Henryk want it. Seems to be little record why it was to be removed. (JG and Henryk to find out from RST what Apache does.) Should headers describe implementation requirements via some tagging? (add issue to issues list so we don't forget about it). Did I get Content-Location right for interpretation of relative URL's? Jeff's issues. (see below). Please note that I did not apply Roy's diff's blindly; we need to examine the almost 04 text as it current exists rather than Roy's diffs. My brain is too fried to remember my decision in each case. (Move expires max/age stuff to appendix) 300 and 406 list size issue. (add (s) in both locations). Vary should have cross ref. to CAching Negotiated Responses. (Jeff to draft message with exact changes; some other problems with Vary) Page through the almost ID4. Pass through issues list. Strategy for IESG submission of 1.1 document and related documents (DA, state). Go over issues list to see which we believe have been closed and which might/should be deferred. Fix refernece to SSL. Go over references. From: Paul Leach To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" Subject: cacheability of response codes. Date: Wed, 29 May 1996 16:24:22 -0700 Section 10.3.2 of "almost draft 4" says that 301 (Moved Permanently) responses are cacheable unless indicated otherwise. Section 13.7.1 says only 200 and 206 are cacheable unless Expires or Cache-Control explicitly allows it. I believe that section 13.7.1 is the one that is inconsistent with the concensus intent. Fix: change A response received with a status code of 200 or 206 may be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a Cache-Control directive prohibits caching. to A response received with a status code of 200, 206 or 301 may be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a Cache-Control directive prohibits caching. Paul To: jg@w3.org Cc: "Roy T. Fielding" , koen@win.tue.nl (Koen Holtman), mogul@pa.dec.com Subject: Agenda items for Thursday's teleconference Date: Tue, 28 May 96 16:45:44 MDT From: Jeffrey Mogul Content-Length: 6201 I agree with most of the changes that Roy suggested in his message of Sat, 25 May 1996 09:14:38, but there are a few (six) areas where I may disagree. I'd like to put these specific issues on the agenda for Thursday. Rather than try to describe the issues, I'm just including the relevant sections of Roy's explanatory message below. I don't think it's worth getting into a lengthy online debate in the next 36 hours, since we'd probably just recapitulate it all on the telephone. I tried to retain (or insert) diff's "***************" separators between each individual issue. Thanks -Jeff (1) > *************** > *** 4338,4378 **** > > > 16.3.1 Last-modified Dates > - In HTTP/1.0, the only cache validator is the Last-Modified time carried > - by a response. Clients validate entities using the If-Modified-Since > - header. In simple terms, a cache entry is considered to be valid if the > - actual resource entity has not been modified since the original response > - was generated. This is wrong because all aspects of caching are independent of the protocol version. There is nothing preventing an HTTP/1.0 client or server from implementing cache-control, Etag, etc. (2) > *************** > *** 4543,4549 **** > > . If an entity tag has been provided by the origin server, MUST use > that entity tag in any cache-conditional request (using If-Match or > ! If-NoneMatch). > . If only a Last-Modified value has been provided by the origin > server, SHOULD use that value in non-subrange cache-conditional > requests (using If-Modified-Since). > --- 4527,4533 ---- > > . If an entity tag has been provided by the origin server, MUST use > that entity tag in any cache-conditional request (using If-Match or > ! If-None-Match). > . If only a Last-Modified value has been provided by the origin > server, SHOULD use that value in non-subrange cache-conditional > requests (using If-Modified-Since). REASON: Typo. (3) > *************** > *** 4993,5061 **** > updates and the problems arising from server, cache, or network failure > prior to write-back. > > - > - 16.12 Generic Resources and HTTP/1.0 Proxy Caches > - If the correct handling of responses from a generic resource (Section > - 15) by HTTP/1.0 proxy caches in the response chain is important, > - HTTP/1.1 origin servers can include the following Expires (Section > - 18.22) response header in all responses from the generic resource: > - > - Expires: Thu, 01 Jan 1980 00:00:00 GMT > - > - If this Expires header is included, the server should usually also > - include a Cache-Control header for the benefit of HTTP/1.1 caches, for example > - > - Cache-Control: max-age=604800 > - > - which overrides the freshness lifetime of zero seconds specified by the > - included Expires header. REASON: That is completely bogus and unnecessary. The protocol cannot advocate defeat of its own features. If it does, I will insist that implementers ignore all such cache constraints, since they are clearly contrary to the future of the Internet as a whole. Furthermore, it is incorrect to describe HTTP/1.0 as not including cache-control, since any HTTP/1.0 application can (and should) implement it even if they are not HTTP/1.1 compliant in other aspects. If origin servers invent ugly hacks to handle older protocols, that is their perogative. There is no basis for making it a standard. (4) > *************** > - > - 16.13 Cache Replacement > - If a new cacheable response (see sections 18.10.2, 16.2.6, 16.2.8 and > - 16.8) is received from a plain resource while any existing responses for > - the same resource are cached, the cache MUST NOT return any of those > - older responses to any future requests for the resource. > - > - Note: a new response that has an older Date header value than > - existing cached responses is not cacheable. > - > - If a new cacheable response is received from a generic resource with a > - certain variant-ID while any old responses with the same variant-ID for > - the same resource are cached, the cache MUST NOT return any of those old > - responses to any future requests for the resource. > - > - Note: In some cases, this may mean that the cache chooses to delete > - the old response(s) from cache storage to recover space. However, > - note that there will never be a new response to signal that a > - variant-ID is no longer in use. It is expected that the cache's > - update heuristics will eventually cause such old responses to be > - deleted. > - > - The cache SHOULD use the new response to reply to the current request. > - It may insert it into cache storage and may, if it meets all other > - requirements, use it to respond to any future requests that would > - previously have caused the old response to be returned. If it inserts > - the new response into cache storage it should follow the rules in > - section 16.4.3. > - REASON: HTTP does not place requirements on how a cache manages its own storage process. (5) > *************** > - > - 16.14 Caching of Negative Responses > - Caching of negative responses has often been a significant performance > - advantage in distributed systems. In some future draft or specification > - we may have more to say about negative caching. > - REASON: Completely bogus -- caching of any response is already defined by this specification. (6) > *************** > *** 6824,6830 **** > me the part(s) that I am missing; otherwise, send me the entire new > entity.'" > > ! Range-If = "Range-If" ":" (if-valid-rhs | HTTP-date) > > If the client has no entity tag for a plain resource, but does have a > Last-Modified date, it may use that date in a If-Range header. (The > --- 6584,6590 ---- > me the part(s) that I am missing; otherwise, send me the entire new > entity.'" > > ! If-Range = "If-Range" ":" ( entity-tag | HTTP-date) > > If the client has no entity tag for a plain resource, but does have a > Last-Modified date, it may use that date in a If-Range header. (The REASON: The old BNF was wrong. > *************** [end of list]