Ignore:
Timestamp:
Oct 23, 2011, 1:20:31 PM (8 years ago)
Author:
julian.reschke@…
Message:

Rephrase description of conformance; explain how the spec handles error handling (see #186)

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1451 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 22, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-10-20">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: April 22, 2012</td>
     442               <td class="left">Expires: April 25, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">October 20, 2011</td>
     495               <td class="right">October 23, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on April 22, 2012.</p>
     525      <p>This Internet-Draft will expire on April 25, 2012.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    542542      <ul class="toc">
    543543         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    544                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     544               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    545545               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    546546                     <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
    … …  
    726726         reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    727727      </p>
    728       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     728      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    729729      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    730730         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    731731      </p>
    732       <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the
    733          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    734          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    735          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     732      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     733         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     734      </p>
     735      <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
     736         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     737      </p>
     738      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
     739      </p>
     740      <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
     741         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     742         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     743         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     744         error recovery could lead to dangerous consequences.
    736745      </p>
    737746      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    738       <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF, with the list rule expanded.
     747      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF, with the list rule expanded.
    739748      </p>
    740749      <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
    … …  
    743752      </p>
    744753      <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a id="core.rules" href="#core.rules">Core Rules</a></h3>
    745       <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
    746       </p>
    747       <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    748   <a href="#core.rules" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    749   <a href="#core.rules" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    750   <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    751   <a href="#core.rules" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     754      <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
     755      </p>
     756      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
     757  <a href="#core.rules" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
     758  <a href="#core.rules" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
     759  <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     760  <a href="#core.rules" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    752761</pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    753762      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
    754       <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    755   <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    756   <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    757   <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>&gt;
    758   <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     763      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     764  <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
     765  <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     766  <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>&gt;
     767  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    759768</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    760       <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     769      <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    761770      </p>
    762771      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#core.rules" class="smpl">token</a>
    … …  
    837846         to a single application, so that this is clear.
    838847      </p>
    839       <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
     848      <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
    840849         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    841850         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    … …  
    846855      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
    847856      <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource,
    848          or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.
     857         or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.
    849858      </p>
    850859      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2>
    … …  
    854863         with "X-" if they are to be registered (either immediately or in the future).
    855864      </p>
    856       <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     865      <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    857866         can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
    858867      </p>
    859868      <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    860869         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    861          quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     870         quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    862871      </p>
    863872      <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
    … …  
    874883      <ul>
    875884         <li>
    876             <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     885            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    877886            </p>
    878887            <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default
    … …  
    886895         </li>
    887896         <li>
    888             <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     897            <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    889898            </p>
    890899         </li>
    … …  
    897906         </li>
    898907         <li>
    899             <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     908            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    900909            </p>
    901910         </li>
    … …  
    948957               <tr>
    949958                  <td class="left">Host</td>
    950                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     959                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    951960               </tr>
    952961               <tr>
    … …  
    988997               <tr>
    989998                  <td class="left">TE</td>
    990                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     999                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    9911000               </tr>
    9921001               <tr>
    … …  
    9991008      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
    10001009      <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    1001          Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1010         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    10021011      </p>
    10031012      <div id="rfc.table.u.3">
    … …  
    13211330         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    13221331      </p>
    1323       <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
     1332      <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
    13241333         to ensure safe and proper transfer of the message.
    13251334      </p>
    … …  
    13271336      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    13281337      <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    1329       <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     1338      <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    13301339         rules are used (with the first applicable one being selected):
    13311340      </p>
    … …  
    15501559      </p>
    15511560      <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1552          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1561         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    15531562         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    15541563         infinite loop.
    15551564      </p>
    1556       <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1565      <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    15571566      </p>
    15581567      <div id="rfc.iref.c.1"></div>
    … …  
    15621571         forwarding of packets until the connection is closed.
    15631572      </p>
    1564       <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1573      <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    15651574         For example,
    15661575      </p>
    … …  
    16261635      <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    16271636         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    1628          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1637         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    16291638      </p>
    16301639      <div id="rfc.iref.23"></div>
    16311640      <div id="rfc.iref.s.3"></div>
    16321641      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    1633       <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1642      <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    16341643         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    16351644      </p>
    … …  
    16831692      <div id="rfc.iref.s.7"></div>
    16841693      <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1685       <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1694      <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    16861695      </p>
    16871696      <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code
    … …  
    17181727         another input action.
    17191728      </p>
    1720       <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1729      <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    17211730      </p>
    17221731      <div id="rfc.iref.30"></div>
    … …  
    20142023      <div id="rfc.iref.s.37"></div>
    20152024      <h3 id="rfc.section.7.4.19"><a href="#rfc.section.7.4.19">7.4.19</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    2016       <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
     2025      <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
    20172026      </p>
    20182027      <div id="rfc.figure.u.8"></div>
    … …  
    20742083      <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    20752084         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2076          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
     2085         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    20772086      </p>
    20782087      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="http.date" href="#http.date">Date/Time Formats</a></h1>
    … …  
    22302239      </p>
    22312240      <p id="rfc.section.9.3.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    2232       <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
     2241      <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
    22332242      </p>
    22342243      <div id="rfc.iref.f.1"></div>
    … …  
    23342343      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    23352344      <p id="rfc.section.9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2336       <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2345      <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    23372346         identifying the application.
    23382347      </p>
    … …  
    23402349</pre><p id="rfc.section.9.9.p.4">Example:</p>
    23412350      <div id="rfc.figure.u.33"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2342 </pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2351</pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    23432352      </p>
    23442353      <div class="note" id="rfc.section.9.9.p.7">
    … …  
    23562365         user agent limitations.
    23572366      </p>
    2358       <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     2367      <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    23592368         for identifying the application.
    23602369      </p>
    … …  
    28282837      </p>
    28292838      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2830       <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     2839      <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    28312840      </p>
    28322841      <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References
    … …  
    29882997      </p>
    29892998      <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    2990          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.9</a>)
     2999         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.9</a>)
    29913000      </p>
    29923001      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    33693378      <ul>
    33703379         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/160">http://tools.ietf.org/wg/httpbis/trac/ticket/160</a>&gt;: "Redirects and non-GET methods"
     3380         </li>
     3381         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>&gt;: "Document HTTP's error-handling philosophy"
    33713382         </li>
    33723383         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/310">http://tools.ietf.org/wg/httpbis/trac/ticket/310</a>&gt;: "clarify 303 redirect on HEAD"
    … …  
    35503561            </li>
    35513562            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3552                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.15">2.2.1</a>, <a href="#rfc.xref.Part1.16">3</a>, <a href="#rfc.xref.Part1.17">3.1</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.2</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.3</a>, <a href="#rfc.xref.Part1.25">5</a>, <a href="#rfc.xref.Part1.26">5.1</a>, <a href="#rfc.xref.Part1.27">6.8</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.9</a>, <a href="#rfc.xref.Part1.30">7.1.1</a>, <a href="#rfc.xref.Part1.31">7.1.2</a>, <a href="#rfc.xref.Part1.32">7.2.4</a>, <a href="#rfc.xref.Part1.33">7.2.6</a>, <a href="#rfc.xref.Part1.34">7.4.19</a>, <a href="#rfc.xref.Part1.35">7.5.6</a>, <a href="#rfc.xref.Part1.36">9.3</a>, <a href="#rfc.xref.Part1.37">9.9</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.10</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul>
    3553                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    3554                         <li><em>Section 1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">3.1</a></li>
    3555                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li>
    3556                         <li><em>Section 2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.2.4</a></li>
    3557                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">7.5.6</a></li>
    3558                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a></li>
    3559                         <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.9</a></li>
    3560                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.16">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li>
    3561                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.18">3.1</a></li>
    3562                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2.2.1</a>, <a href="#rfc.xref.Part1.25">5</a>, <a href="#rfc.xref.Part1.33">7.2.6</a></li>
    3563                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.24">3.3</a>, <a href="#rfc.xref.Part1.26">5.1</a></li>
    3564                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
    3565                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.37">9.9</a>, <a href="#rfc.xref.Part1.40">9.10</a></li>
    3566                         <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">7.1.1</a>, <a href="#rfc.xref.Part1.36">9.3</a></li>
    3567                         <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">3.1</a></li>
    3568                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.2</a></li>
    3569                         <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
    3570                         <li><em>Section 8.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.4.19</a></li>
    3571                         <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">6.8</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>
    3572                         <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a></li>
    3573                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">12</a></li>
     3563                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.19</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">9.3</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.44">A</a><ul>
     3564                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
     3565                        <li><em>Section 1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3.1</a></li>
     3566                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li>
     3567                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
     3568                        <li><em>Section 2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.2.4</a></li>
     3569                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">7.5.6</a></li>
     3570                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li>
     3571                        <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.9</a></li>
     3572                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li>
     3573                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.19">3.1</a></li>
     3574                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li>
     3575                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>
     3576                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
     3577                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li>
     3578                        <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">9.3</a></li>
     3579                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
     3580                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
     3581                        <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
     3582                        <li><em>Section 8.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li>
     3583                        <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.44">A</a></li>
     3584                        <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a></li>
     3585                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">12</a></li>
    35743586                     </ul>
    35753587                  </li>
Note: See TracChangeset for help on using the changeset viewer.