Ignore:
Timestamp:
Mar 5, 2010, 2:05:58 AM (10 years ago)
Author:
julian.reschke@…
Message:

clarify header normalization vs matching request headers (see #147)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r770 r771  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-03-04">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-03-05">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: September 5, 2010</td>
     430               <td class="left">Expires: September 6, 2010</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">March 4, 2010</td>
     491               <td class="right">March 5, 2010</td>
    492492            </tr>
    493493         </tbody>
     
    519519      <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
    520520      </p>
    521       <p>This Internet-Draft will expire in September 5, 2010.</p>
     521      <p>This Internet-Draft will expire in September 6, 2010.</p>
    522522      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523523      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    952952         (i.e., that associated with the stored response), and the presented request.
    953953      </p>
    954       <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    955          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="TODO-missing-ref">[<a href="#TODO-missing-ref" class="smpl">TODO-missing-ref</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    956          name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    957       </p>
    958       <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p>
     954      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if those in the first request can be transformed
     955         to those in the second request by applying any of the following:
     956      </p>
     957      <ul>
     958         <li>adding or removing whitespace, where allowed in the header's syntax</li>
     959         <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
     960         </li>
     961         <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification
     962            (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
     963         </li>
     964      </ul>
     965      <p id="rfc.section.2.6.p.3">If (after any normalisation that may take place) a header field is absent from a request, it can only match another request
     966         if it is also absent there.
     967      </p>
    959968      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
    960969         by the origin server.
     
    17351744      <p id="rfc.section.C.10.p.1">Closed issues: </p>
    17361745      <ul>
     1746         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/147">http://tools.ietf.org/wg/httpbis/trac/ticket/147</a>&gt;: "serving negotiated responses from cache: header-specific canonicalization"
     1747         </li>
    17371748         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/197">http://tools.ietf.org/wg/httpbis/trac/ticket/197</a>&gt;: "Effect of CC directives on history lists"
    17381749         </li>
Note: See TracChangeset for help on using the changeset viewer.