Re: comments on caching rewrite

Hi Dan,

Thanks for the quick comments. A few quick responses in turn below,  
I'll follow up on the rest ASAP.

On 12/03/2009, at 2:40 AM, Dan Winship wrote:

> You need to s/Request-URI/request-target/ globally.

I noticed that, but it's not clear what the right term is yet, since  
request-target specifically refers to what comes in on the request- 
line (last time I looked), which is often not what we want to use;  
i.e. it also needs to take the Host header into account. I suspect  
this is going to require some revision (and possibly a new term) in p1.


> 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

I'm open to that; the current language is a bit tortured because MAY  
was switched out for MUST NOTs at the last minute, to make the  
requirements more clear.



> 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?

Good question, I think we need to discuss that.


> 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?)

I think we have an existing issue for this (am offline so can't  
check); if not will add one.


> 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
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 12 March 2009 04:51:15 UTC