W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

comments on caching rewrite

From: Dan Winship <dan.winship@gmail.com>
Date: Wed, 11 Mar 2009 11:40:18 -0400
Message-ID: <49B7DB62.50607@gmail.com>
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/ 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

    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


-- Dan
Received on Wednesday, 11 March 2009 15:41:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:03:24 UTC