Ignore:
Timestamp:
Jul 8, 2012, 11:15:03 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1739 r1740  
    332332   impact on security. This is because different uses of the protocol require
    333333   different error handling strategies; for example, a Web browser might wish to
    334    transparently recover from a response where the Location header field
    335    doesn't parse according to the ABNF, whereby in a systems control protocol
    336    using HTTP, this type of error recovery could lead to dangerous consequences.
     334   transparently recover from a response where the <x:ref>Location</x:ref>
     335   header field doesn't parse according to the ABNF, whereby in a systems
     336   control protocol using HTTP, this type of error recovery could lead to
     337   dangerous consequences.
    337338</t>
    338339</section>
    … …  
    580581<t>
    581582   When more than one suitable response is stored, a cache &MUST; use the
    582    most recent response (as determined by the Date header field). It can also
    583    forward a request with "Cache-Control: max-age=0" or "Cache-Control:
    584    no-cache" to disambiguate which response to use.
     583   most recent response (as determined by the <x:ref>Date</x:ref> header
     584   field). It can also forward a request with "Cache-Control: max-age=0" or
     585   "Cache-Control: no-cache" to disambiguate which response to use.
    585586</t>
    586587<t>
    … …  
    662663      <t>If the <x:ref>Expires</x:ref> response header field
    663664      (<xref target="header.expires" />) is present, use its value minus the
    664       value of the Date response header field, or</t>
     665      value of the <x:ref>Date</x:ref> response header field, or</t>
    665666      <t>Otherwise, no explicit expiration time is present in the response. A
    666667      heuristic freshness lifetime might be applicable; see <xref
    … …  
    742743   <list>
    743744      <t>
    744          HTTP/1.1 requires origin servers to send a Date header field, if possible,
    745          with every response, giving the time at which the response was
    746          generated. The term "date_value" denotes the value of the Date
    747          header field, in a form appropriate for arithmetic operations. See
     745         HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header
     746         field, if possible, with every response, giving the time at which the
     747         response was generated. The term "date_value" denotes the value of the
     748         Date header field, in a form appropriate for arithmetic operations. See
    748749         &header-date; for the definition of the Date header field, and for
    749750         requirements regarding responses without it.
    … …  
    10221023<t>
    10231024   A cache &MUST; invalidate the effective Request URI
    1024    (&effective-request-uri;) as well as the URI(s) in the Location
    1025    and Content-Location response header fields (if present) when a non-error
    1026    response to a request with an unsafe method is received.
    1027 </t>
    1028 <t>
    1029    However, a cache &MUST-NOT; invalidate a URI from a Location or
    1030    Content-Location response header field if the host part of that URI differs
    1031    from the host part in the effective request URI (&effective-request-uri;).
    1032    This helps prevent denial of service attacks.
     1025   (&effective-request-uri;) as well as the URI(s) in the <x:ref>Location</x:ref>
     1026   and <x:ref>Content-Location</x:ref> response header fields (if present) when
     1027   a non-error response to a request with an unsafe method is received.
     1028</t>
     1029<t>
     1030   However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>
     1031   or <x:ref>Content-Location</x:ref> response header field if the host part of
     1032   that URI differs from the host part in the effective request URI
     1033   (&effective-request-uri;). This helps prevent denial of service attacks.
    10331034</t>
    10341035<t>
    … …  
    11221123<t>
    11231124   If multiple selected responses are available, the most recent response
    1124    (as determined by the Date header field) is used; see <xref
     1125   (as determined by the <x:ref>Date</x:ref> header field) is used; see <xref
    11251126   target="constructing.responses.from.caches"/>.
    11261127</t>
    … …  
    13601361   The no-transform request directive indicates that an intermediary
    13611362   (whether or not it implements a cache) &MUST-NOT; change the
    1362    Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type request
    1363    header fields, nor the request representation.
     1363   <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or
     1364   <x:ref>Content-Type</x:ref> request header fields, nor the request
     1365   representation.
    13641366</t>
    13651367</section>
    … …  
    15891591   The no-transform response directive indicates that an intermediary
    15901592   (regardless of whether it implements a cache) &MUST-NOT; change the
    1591    Content-Encoding, <x:ref>Content-Range</x:ref> or Content-Type response
    1592    header fields, nor the response representation.
     1593   <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Range</x:ref> or
     1594   <x:ref>Content-Type</x:ref> response header fields, nor the response
     1595   representation.
    15931596</t>
    15941597</section>
    … …  
    19121915   If an implementation sends a message with one or more Warning header fields to a
    19131916   receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include
    1914    in each warning-value a warn-date that matches the Date header field in the
    1915    message.
     1917   in each warning-value a warn-date that matches the <x:ref>Date</x:ref> header
     1918   field in the message.
    19161919</t>
    19171920<t>
    19181921   If a system receives a message with a warning-value that includes
    1919    a warn-date, and that warn-date is different from the Date value in the
    1920    response, then that warning-value &MUST; be deleted from the message before
    1921    storing, forwarding, or using it. (preventing the consequences of naive
    1922    caching of Warning header fields.) If all of the warning-values are deleted
    1923    for this reason, the Warning header field &MUST; be deleted as well.
     1922   a warn-date, and that warn-date is different from the <x:ref>Date</x:ref>
     1923   value in the response, then that warning-value &MUST; be deleted from the
     1924   message before storing, forwarding, or using it. (preventing the consequences
     1925   of naive caching of Warning header fields.) If all of the warning-values are
     1926   deleted for this reason, the Warning header field &MUST; be deleted as well.
    19241927</t>
    19251928<t>
    … …  
    23092312      <x:defines>5xx (Server Error)</x:defines>
    23102313      <x:defines>504 (Gateway Timeout)</x:defines>
     2314      <x:defines>Content-Encoding</x:defines>
     2315      <x:defines>Content-Location</x:defines>
     2316      <x:defines>Content-Type</x:defines>
     2317      <x:defines>Date</x:defines>
     2318      <x:defines>Location</x:defines>
    23112319    </x:source>
    23122320  </reference>
    … …  
    25322540</t>
    25332541<t>
    2534   Remove requirement to consider Content-Location in successful responses
    2535   in order to determine the appropriate response to use.
     2542  Remove requirement to consider <x:ref>Content-Location</x:ref> in successful
     2543  responses in order to determine the appropriate response to use.
    25362544  (<xref target="validation.model" />)
    25372545</t>
Note: See TracChangeset for help on using the changeset viewer.