Ignore:
Timestamp:
Jul 12, 2009, 11:58:01 PM (10 years ago)
Author:
julian.reschke@…
Message:

Regenerate ready-to-submit drafts; update diffs.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/07/draft-ietf-httpbis-p6-cache-07.txt

    r605 r608  
    179179     C.7.  Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
    180180     C.8.  Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
    181    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     181   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
    182182   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
    183183
     
    7317312.4.  Validation Model
    732732
    733    Checking with the origin server to see if a stale or otherwise
    734    unusable cached response can be reused is called "validating" or
    735    "revalidating."  Doing so potentially avoids the overhead of
     733   When a cache has one or more stored responses for a requested URI,
     734   but cannot serve any of them (e.g., because they are not fresh, or
     735   one cannot be selected; see Section 2.6), it can use the conditional
    736736
    737737
     
    743743
    744744
    745    retransmitting the response body when the stored response is valid.
    746 
    747    HTTP's conditional request mechanism [Part4] is used for this
    748    purpose.  When a stored response includes one or more validators,
    749    such as the field values of an ETag or Last-Modified header field,
    750    then a validating request SHOULD be made conditional to those field
    751    values.
     745   request mechanism [Part4] in the forwarded request to give the origin
     746   server an opportunity to both select a valid stored response to be
     747   used, and to update it.  This process is known as "validating" or
     748   "revalidating" the stored response.
     749
     750   When sending such a conditional request, the cache SHOULD add an If-
     751   Modified-Since header whose value is that of the Last-Modified header
     752   from the selected (see Section 2.6) stored response, if available.
     753
     754   Additionally, the cache SHOULD add an If-None-Match header whose
     755   value is that of the ETag header(s) from all responses stored for the
     756   requested URI, if present.  However, if any of the stored responses
     757   contains only partial content, its entity-tag SHOULD NOT be included
     758   in the If-None-Match header field unless the request is for a range
     759   that would be fully satisfied by that stored response.
    752760
    753761   A 304 (Not Modified) response status code indicates that the stored
    754762   response can be updated and reused; see Section 2.7.
    755763
    756    If instead the cache receives a full response (i.e., one with a
    757    response body), it is used to satisfy the request and replace the
    758    stored response. [[anchor5: Should there be a requirement here?]]
     764   A full response (i.e., one with a response body) indicates that none
     765   of the stored responses nominated in the conditional request is
     766   suitable.  Instead, the full response is used both to satisfy the
     767   request and replace the stored response. [[anchor5: Should there be a
     768   requirement here?]]
    759769
    760770   If a cache receives a 5xx response while attempting to validate a
    761771   response, it MAY either forward this response to the requesting
    762772   client, or act as if the server failed to respond.  In the latter
    763    case, it MAY return a previously stored response (which SHOULD
    764    include the 111 warn-code; see Section 3.6) unless the stored
    765    response includes the "must-revalidate" cache directive (see
    766    Section 2.3.3).
    767 
    768 2.5.  Request Methods that Invalidate
    769 
    770    Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
    771    for changing state on the origin server, intervening caches can use
    772    them to keep their contents up-to-date.
    773 
    774    The following HTTP methods MUST cause a cache to invalidate the
    775    Request-URI as well as the URI(s) in the Location and Content-
    776    Location headers (if present):
    777 
    778    o  PUT
    779 
    780    o  DELETE
    781 
    782    o  POST
    783 
    784    An invalidation based on a URI from a Location or Content-Location
    785    header MUST NOT be performed if the host part of that URI differs
    786    from the host part in the Request-URI.  This helps prevent denial of
    787    service attacks.
    788 
    789    [[anchor6: TODO: "host part" needs to be specified better.]]
    790 
    791    A cache that passes through requests for methods it does not
    792    understand SHOULD invalidate the Request-URI.
    793 
    794 
    795 
    796 Fielding, et al.        Expires January 14, 2010               [Page 14]
    797 
    798 
    799 Internet-Draft              HTTP/1.1, Part 6                   July 2009
    800 
    801 
    802    Here, "invalidate" means that the cache will either remove all stored
    803    responses related to the Request-URI, or will mark these as "invalid"
    804    and in need of a mandatory validation before they can be returned in
    805    response to a subsequent request.
    806 
    807    Note that this does not guarantee that all appropriate responses are
    808    invalidated.  For example, the request that caused the change at the
    809    origin server might not have gone through the cache where a response
    810    is stored.
    811 
    812    [[anchor7: TODO: specify that only successful (2xx, 3xx?) responses
    813    invalidate.]]
    814 
    815 2.6.  Caching Negotiated Responses
    816 
    817    Use of server-driven content negotiation (Section 4.1 of [Part3])
    818    alters the conditions under which a cache can use the response for
    819    subsequent requests.
    820 
    821    When a cache receives a request that can be satisfied by a stored
    822    response that includes a Vary header field (Section 3.5), it MUST NOT
    823    use that response unless all of the selecting request-headers in the
    824    presented request match the corresponding stored request-headers from
    825    the original request.
    826 
    827    The selecting request-headers from two requests are defined to match
    828    if and only if the selecting request-headers in the first request can
    829    be transformed to the selecting request-headers in the second request
    830    by adding or removing linear white space [[anchor8: [ref]]] at places
    831    where this is allowed by the corresponding ABNF, and/or combining
    832    multiple message-header fields with the same field name following the
    833    rules about message headers in Section 4.2 of [Part1].  [[DISCUSS-
    834    header-specific-canonicalization: Should the matching requirement be
    835    relaxed so that it would be ok to use a cached response if the
    836    selecting request headers match after header-specific
    837    canonicalization? (see
    838    <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147>)]]
    839 
    840    A Vary header field-value of "*" always fails to match, and
    841    subsequent requests to that resource can only be properly interpreted
    842    by the origin server.
    843 
    844    If no stored response matches, the cache MAY forward the presented
    845    request to the origin server in a conditional request, and SHOULD
    846    include all ETags stored with potentially suitable responses in an
    847    If-None-Match request header.  If the server responds with 304 (Not
    848    Modified) and includes an entity tag or Content-Location that
    849    indicates the entity to be used, that cached response MUST be used to
    850 
    851 
    852 
    853 Fielding, et al.        Expires January 14, 2010               [Page 15]
    854 
    855 
    856 Internet-Draft              HTTP/1.1, Part 6                   July 2009
    857 
    858 
    859    satisfy the presented request, and SHOULD be used to update the
    860    corresponding stored response; see Section 2.7.
    861 
    862    If any of the stored responses contains only partial content, its
    863    entity-tag SHOULD NOT be included in the If-None-Match header field
    864    unless the request is for a range that would be fully satisfied by
    865    that stored response.
     773   case, it MAY return a previously stored response (see Section 2.3.3).
    866774
    867775   If a cache receives a successful response whose Content-Location
     
    870778   stored response, and whose Date is more recent than that of the
    871779   existing response, the existing response SHOULD NOT be returned in
    872    response to future requests and SHOULD be deleted from the
    873    cache.[[anchor9: DISCUSS: Not sure if this is necessary.]]
     780   response to future requests and SHOULD be deleted from the cache.
     781   [[anchor6: DISCUSS: Not sure if this is necessary.]]
     782
     7832.5.  Request Methods that Invalidate
     784
     785   Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
     786   for changing state on the origin server, intervening caches can use
     787   them to keep their contents up-to-date.
     788
     789   The following HTTP methods MUST cause a cache to invalidate the
     790   Request-URI as well as the URI(s) in the Location and Content-
     791   Location headers (if present):
     792
     793
     794
     795
     796Fielding, et al.        Expires January 14, 2010               [Page 14]
     797
     798
     799Internet-Draft              HTTP/1.1, Part 6                   July 2009
     800
     801
     802   o  PUT
     803
     804   o  DELETE
     805
     806   o  POST
     807
     808   An invalidation based on a URI from a Location or Content-Location
     809   header MUST NOT be performed if the host part of that URI differs
     810   from the host part in the Request-URI.  This helps prevent denial of
     811   service attacks.
     812
     813   [[anchor7: TODO: "host part" needs to be specified better.]]
     814
     815   A cache that passes through requests for methods it does not
     816   understand SHOULD invalidate the Request-URI.
     817
     818   Here, "invalidate" means that the cache will either remove all stored
     819   responses related to the Request-URI, or will mark these as "invalid"
     820   and in need of a mandatory validation before they can be returned in
     821   response to a subsequent request.
     822
     823   Note that this does not guarantee that all appropriate responses are
     824   invalidated.  For example, the request that caused the change at the
     825   origin server might not have gone through the cache where a response
     826   is stored.
     827
     828   [[anchor8: TODO: specify that only successful (2xx, 3xx?) responses
     829   invalidate.]]
     830
     8312.6.  Caching Negotiated Responses
     832
     833   When a cache receives a request that can be satisfied by a stored
     834   response that has a Vary header field (Section 3.5), it MUST NOT use
     835   that response unless all of the selecting request-headers nominated
     836   by the Vary header match in both the original request (i.e., that
     837   associated with the stored response), and the presented request.
     838
     839   The selecting request-headers from two requests are defined to match
     840   if and only if the selecting request-headers in the first request can
     841   be transformed to the selecting request-headers in the second request
     842   by adding or removing linear white space [[anchor9: [ref]]] at places
     843   where this is allowed by the corresponding ABNF, and/or combining
     844   multiple message-header fields with the same field name following the
     845   rules about message headers in Section 4.2 of [Part1].
     846
     847   If a header field is absent from a request, it can only match another
     848   request if it is also absent there.
     849
     850
     851
     852
     853Fielding, et al.        Expires January 14, 2010               [Page 15]
     854
     855
     856Internet-Draft              HTTP/1.1, Part 6                   July 2009
     857
     858
     859   A Vary header field-value of "*" always fails to match, and
     860   subsequent requests to that resource can only be properly interpreted
     861   by the origin server.
     862
     863   The stored response with matching selecting request-headers is known
     864   as the selected response.
     865
     866   If no selected response is available, the cache MAY forward the
     867   presented request to the origin server in a conditional request; see
     868   Section 2.4.
    874869
    8758702.7.  Combining Responses
    876871
    877872   When a cache receives a 304 (Not Modified) response or a 206 (Partial
    878    Content) response, it needs to update the stored response with the
    879    new one, so that the updated response can be sent to the client.
    880 
    881    If the status code is 304 (Not Modified), the cache SHOULD use the
    882    stored entity-body as the updated entity-body.  If the status code is
    883    206 (Partial Content) and the ETag or Last-Modified headers match
    884    exactly, the cache MAY combine the stored entity-body in the stored
    885    response with the updated entity-body received in the response and
    886    use the result as the updated entity-body (see Section 4 of [Part5]).
    887 
    888    The stored response headers are used for the updated response, except
    889    that
     873   Content) response (in this section, the "new" response"), it needs to
     874   created an updated response by combining the stored response with the
     875   new one, so that the updated response can be used to satisfy the
     876   request.
     877
     878   If the new response contains an ETag, it identifies the stored
     879   response to use. [[anchor10: may need language about Content-Location
     880   here]][[anchor11: cover case where INM with multiple etags was sent]]
     881
     882   If the status code is 206 (partial content), both the stored and new
     883   responses MUST have ETags, and those ETags MUST match using the
     884   strong comparison function (see Section 4 of [Part4]).  Otherwise,
     885   the responses MUST NOT be combined.
     886
     887   The stored response headers are used as those of the updated
     888   response, except that
    890889
    891890   o  any stored Warning headers with warn-code 1xx (see Section 3.6)
    892       MUST be deleted from the stored response and the forwarded
    893       response.
     891      MUST be deleted from the stored response and the updated response.
    894892
    895893   o  any stored Warning headers with warn-code 2xx MUST be retained in
    896       the stored response and the forwarded response.
    897 
    898    o  any headers provided in the 304 or 206 response MUST replace the
     894      the stored response and the updated response.
     895
     896   o  any headers provided in the new response MUST replace the
    899897      corresponding headers from the stored response.
    900898
    901    A cache MUST also replace any stored headers with corresponding
    902    headers received in the incoming response, except for Warning headers
    903    as described immediately above.  If a header field-name in the
    904    incoming response matches more than one header in the stored
    905    response, all such old headers MUST be replaced.  It MAY store the
    906    combined entity-body.
     899   If a header field-name in the new response matches more than one
     900   header in the stored response, all such stored headers MUST be
     901   replaced.
     902
     903   The updated response can [[[[anchor12: requirement?]]]] be used to
     904   replace the stored response in cache.  In the case of a 206 response,
     905   the combined entity-body MAY be stored.
     906
    907907
    908908
     
    914914
    915915
    916    [[anchor10: ISSUE: discuss how to handle HEAD updates]]
     916   [[anchor13: ISSUE: discuss how to handle HEAD updates]]
    917917
    918918
     
    10451045      by no more than the specified number of seconds.  If no value is
    10461046      assigned to max-stale, then the client is willing to accept a
    1047       stale response of any age. [[anchor11: of any staleness? --mnot]]
     1047      stale response of any age. [[anchor14: of any staleness? --mnot]]
    10481048
    10491049   min-fresh
     
    17281728   transfer encoding that may not be self delimiting); it was important
    17291729   to straighten out exactly how message lengths are computed. (see also
    1730    [Part1], [Part3] and [Part5]) [[anchor14: This used to refer to the
     1730   [Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the
    17311731   text about non-modifiable headers, and will have to be updated later
    17321732   on. --jre]]
    17331733
    17341734   Proxies should be able to add Content-Length when appropriate.
    1735    [[anchor15: This used to refer to the text about non-modifiable
     1735   [[anchor18: This used to refer to the text about non-modifiable
    17361736   headers, and will have to be updated later on. --jre]]
    17371737
     
    19841984      numeric protocol elements"
    19851985
     1986   Affected issues:
     1987
     1988   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non-
     1989      existant headers
     1990
     1991
     1992
     1993Fielding, et al.        Expires January 14, 2010               [Page 35]
     1994
     1995
     1996Internet-Draft              HTTP/1.1, Part 6                   July 2009
     1997
    19861998
    19871999Index
    19882000
    19892001   A
    1990 
    1991 
    1992 
    1993 Fielding, et al.        Expires January 14, 2010               [Page 35]
    1994 
    1995 
    1996 Internet-Draft              HTTP/1.1, Part 6                   July 2009
    1997 
    1998 
    19992002      age  6
    20002003      Age header  17
     
    20422045         Pragma  24
    20432046         pragma-directive  24
     2047
     2048
     2049
     2050Fielding, et al.        Expires January 14, 2010               [Page 36]
     2051
     2052
     2053Internet-Draft              HTTP/1.1, Part 6                   July 2009
     2054
     2055
    20442056         Pragma-v  24
    20452057         Vary  24
    20462058         Vary-v  24
    2047 
    2048 
    2049 
    2050 Fielding, et al.        Expires January 14, 2010               [Page 36]
    2051 
    2052 
    2053 Internet-Draft              HTTP/1.1, Part 6                   July 2009
    2054 
    2055 
    20562059         warn-agent  25
    20572060         warn-code  25
     
    20992102         Cache Directive  20
    21002103      proxy-revalidate
     2104
     2105
     2106
     2107Fielding, et al.        Expires January 14, 2010               [Page 37]
     2108
     2109
     2110Internet-Draft              HTTP/1.1, Part 6                   July 2009
     2111
     2112
    21012113         Cache Directive  21
    21022114      public
    21032115         Cache Directive  20
    2104 
    2105 
    2106 
    2107 Fielding, et al.        Expires January 14, 2010               [Page 37]
    2108 
    2109 
    2110 Internet-Draft              HTTP/1.1, Part 6                   July 2009
    2111 
    21122116
    21132117   S
     
    21462150   Email: jg@laptop.org
    21472151   URI:   http://www.laptop.org/
     2152
     2153
     2154
     2155
     2156
     2157
     2158
     2159
     2160
     2161
     2162
     2163
     2164Fielding, et al.        Expires January 14, 2010               [Page 38]
     2165
     2166
     2167Internet-Draft              HTTP/1.1, Part 6                   July 2009
    21482168
    21492169
     
    21562176
    21572177   Email: JeffMogul@acm.org
    2158 
    2159 
    2160 
    2161 
    2162 
    2163 
    2164 Fielding, et al.        Expires January 14, 2010               [Page 38]
    2165 
    2166 
    2167 Internet-Draft              HTTP/1.1, Part 6                   July 2009
    21682178
    21692179
     
    22092219
    22102220
    2211 
    2212 
    2213 
    2214 
    2215 
    2216 
    2217 
    2218 
    2219 
    2220 
    22212221Fielding, et al.        Expires January 14, 2010               [Page 39]
    22222222
Note: See TracChangeset for help on using the changeset viewer.