- From: Dan Winship <dan.winship@gmail.com>
- Date: Wed, 11 Mar 2009 11:40:18 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
You need to s/Request-URI/request-target/ globally. 2.1. Response Cacheability The new text, with the split between what can be cached and what can be returned, is MUCH clearer (and more correct) than the old. But I think the cacheability section would be even clearer if you negated the sense of the list, and/or split out the special shared cache rules: A cache MUST NOT store a response to any request if: o the request method is not defined as being cacheable, or o the "no-store" cache directive (see Section 3.2) appears in request or response headers, or o the response is partial or incomplete, if the cache does not understand partial responses (see Section 2.1.1). Additionally, a shared cache MUST NOT store a response if: o the "private" cache response directive (see Section 3.2) appears in the response, or o the "Authorization" header (see Section 3.1 of [Part7]) appears in the request, and the "public" directive is not present (see Section 3.2). A cache MAY store a response to any other request. (If you don't take this patch, note that there's a missing ")" in the third item in the original.) 2.1.1. Storing Partial and Incomplete Responses > A cache that does not support the Range and Content-Range headers > MUST NOT store incomplete or partial responses. FWIW, this is now redundant with 2.1. 2.2. Constructing Responses from Caches > o selecting request-headers nominated by the stored response (if > any) match those presented (see Section 2.6), and "selecting request-headers" haven't been mentioned yet, so "selecting" looks like it's a verb not an adjective and then the sentence doesn't parse. We mostly just need to call out to Section 2.6 here anyway. Maybe: o request-headers used for content negotiation match between the stored response and the presented request (see Section 2.6), and > o the presented request and stored response are free from directives > that would prevent its use (see Section 3.2 and Section 3.4), and s/its/the response's/ 2.3.1.1. Calculating Heuristic Freshness > Heuristics MUST NOT be used for other response status codes. It is not possible to define heuristic freshness for new status codes? 2.3.2. Calculating Age The rules don't say what date_value is for a response with no Date header. Part 1, 8.3 says that "A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient", but doesn't say what that value should be. Given the rules here, I suspect it should add a Date header with request_time, to make the worst-case assumption about its age? Likewise, the rules don't say what age_value is when the response has no Age header. In this case, it probably shouldn't even do the steps of the calculation involving age_value... The detailed description of the Age computation uses "now" twice where it means "response_time": > corrected_received_age = max(now - date_value, age_value) > corrected_initial_age = corrected_received_age > + (now - request_time) ("now" is the time when the response is being served to a client, as opposed to "response_time", which is when it was received from the server.) The summary at the end uses "response_time" correctly. Even after fixing that, the math still seems wrong, because there's no reason to worry about "response_delay" if you're using the "response_time - date_value" case for corrected_received_age. (Unless you're worried about clock skew, but in that case it's still adding response_delay in the wrong place.) I think the correct calculation for corrected_initial_age is something like: response_delay = response_time - request_time; if (response_time > date_value) apparent_age = response_time - date_value; else /* clock skew! */ apparent_age = response_delay; if (is_first_hand_response) corrected_initial_age = apparent_age; else { corrected_age_value = age_value + response_delay; corrected_initial_age = max(apparent_age, corrected_age_value); } or maybe apparent_age = max(response_time - date_value, response_delay); if you want to assume clock skew is more likely than very-new responses. 2.3.3. Serving Stale Responses > Caches SHOULD NOT return stale responses unless they are disconnected > (i.e., it cannot contact the origin server or otherwise find a s/it cannot/they cannot/ 2.5. Request Methods that Invalidate > The following HTTP methods MUST cause a cache to invalidate the > Request-URI as well as the Location and Content-Location headers (if > present): Part 3, 5.7 says "The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases", so presumably the rule here only applies to Content-Location in the response headers? 3.2.2. Response Cache-Control Directives The discussion of optional field-names in "private" and "no-cache" is vague about whether the cache MAY or MUST revalidate when handling a subsequent request for that resource. That is, if another request for the resource comes in, and the cached response is still fresh, is the cache allowed to return it, minus the forbidden headers, or is it required to revalidate, and merge in new values of those headers from the 304 response?) Under no-cache: > This allows an origin server to prevent caching even by caches > that have been configured to return stale responses. That describes must-revalidate. no-cache is stronger than that. Maybe: Essentially, a response returned with this directive is never fresh, and is never allowed to be served stale. > names, this requirement is limited to the field-values assosicated s/assosicated/associated/ -- Dan
Received on Wednesday, 11 March 2009 15:41:02 UTC