Changeset 1452 for draft-ietf-httpbis


Ignore:
Timestamp:
23/10/11 20:20:31 (9 years ago)
Author:
julian.reschke@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
14 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1451 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 22, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-10-20">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    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>
    … …  
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on April 22, 2012.</p>
     528      <p>This Internet-Draft will expire on April 25, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    545545      <ul class="toc">
    546546         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    547                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     547               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    548548               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    549549                     <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">ABNF Extension: #rule</a></li>
    … …  
    751751         thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.
    752752      </p>
    753       <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>
     753      <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>
    754754      <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"
    755755         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>.
    756756      </p>
    757       <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
    758          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    759          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    760          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     757      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     758         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section&nbsp;2</a> for definitions of these terms.
     759      </p>
     760      <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
     761         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     762      </p>
     763      <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.
     764      </p>
     765      <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
     766         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     767         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     768         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     769         error recovery could lead to dangerous consequences.
    761770      </p>
    762771      <div id="rfc.iref.g.1"></div>
    … …  
    34753484      <p id="rfc.section.C.18.p.1">Closed issues: </p>
    34763485      <ul>
     3486         <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"
     3487         </li>
    34773488         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>&gt;: "Explain header registration"
    34783489         </li>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1450 r1452  
    300300</t>
    301301
    302 <section title="Requirements" anchor="intro.requirements">
     302<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    303303<t>
    304304   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    307307</t>
    308308<t>
    309    An implementation is not compliant if it fails to satisfy one or more
    310    of the "MUST" or "REQUIRED" level requirements for the protocols it
    311    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    312    level and all the "SHOULD" level requirements for its protocols is said
    313    to be "unconditionally compliant"; one that satisfies all the "MUST"
    314    level requirements but not all the "SHOULD" level requirements for its
    315    protocols is said to be "conditionally compliant".
     309   This document defines conformance criteria for several roles in HTTP
     310   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     311   Origin Servers, Intermediaries, Proxies and Gateways. See <xref target="architecture"/>
     312   for definitions of these terms.
     313</t>
     314<t>
     315   An implementation is considered conformant if it complies with all of the
     316   requirements associated with its role(s). Note that SHOULD-level requirements
     317   are relevant here, unless one of the documented exceptions is applicable.
     318</t>
     319<t>
     320   This document also uses ABNF to define valid protocol elements
     321   (<xref target="notation"/>). In addition to the prose requirements placed
     322   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     323</t>
     324<t>
     325   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     326   protocol element from an invalid construct. However, HTTP does not define
     327   specific error handling mechanisms, except in cases where it has direct
     328   impact on security. This is because different uses of the protocol require
     329   different error handling strategies; for example, a Web browser may wish to
     330   transparently recover from a response where the Location header field
     331   doesn't parse according to the ABNF, whereby in a systems control protocol
     332   using HTTP, this type of error recovery could lead to dangerous consequences.
    316333</t>
    317334</section>
    … …  
    58615878  <list style="symbols">
    58625879    <t>
     5880      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     5881      "Document HTTP's error-handling philosophy"
     5882    </t>
     5883    <t>
    58635884      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>:
    58645885      "Explain header registration"

  • 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>

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

    r1451 r1452  
    1616  <!ENTITY ID-YEAR "2011">
    1717  <!ENTITY mdash "&#8212;">
     18  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY acks                       "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    2526  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2627  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    27   <!ENTITY agent-driven-negotiation    "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     28  <!ENTITY agent-driven-negotiation   "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2930  <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    301302</t>
    302303
    303 <section title="Requirements" anchor="intro.requirements">
     304<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    304305<t>
    305306   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    308309</t>
    309310<t>
    310    An implementation is not compliant if it fails to satisfy one or more
    311    of the "MUST" or "REQUIRED" level requirements for the protocols it
    312    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    313    level and all the "SHOULD" level requirements for its protocols is said
    314    to be "unconditionally compliant"; one that satisfies all the "MUST"
    315    level requirements but not all the "SHOULD" level requirements for its
    316    protocols is said to be "conditionally compliant".
     311   This document defines conformance criteria for several roles in HTTP
     312   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     313   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     314   for definitions of these terms.
     315</t>
     316<t>
     317   An implementation is considered conformant if it complies with all of the
     318   requirements associated with its role(s). Note that SHOULD-level requirements
     319   are relevant here, unless one of the documented exceptions is applicable.
     320</t>
     321<t>
     322   This document also uses ABNF to define valid protocol elements
     323   (<xref target="notation"/>). In addition to the prose requirements placed
     324   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     325</t>
     326<t>
     327   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     328   protocol element from an invalid construct. However, HTTP does not define
     329   specific error handling mechanisms, except in cases where it has direct
     330   impact on security. This is because different uses of the protocol require
     331   different error handling strategies; for example, a Web browser may wish to
     332   transparently recover from a response where the Location header field
     333   doesn't parse according to the ABNF, whereby in a systems control protocol
     334   using HTTP, this type of error recovery could lead to dangerous consequences.
    317335</t>
    318336</section>
    … …  
    46414659    </t>
    46424660    <t>
     4661      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     4662      "Document HTTP's error-handling philosophy"
     4663    </t>
     4664    <t>
    46434665      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/310"/>:
    46444666      "clarify 303 redirect on HEAD"

  • draft-ietf-httpbis/latest/p3-payload.html

    r1443 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 4, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-10-02">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <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 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: April 4, 2012</td>
     436               <td class="left">Expires: April 25, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">October 2, 2011</td>
     493               <td class="right">October 23, 2011</td>
    494494            </tr>
    495495         </tbody>
    … …  
    519519         in progress”.
    520520      </p>
    521       <p>This Internet-Draft will expire on April 4, 2012.</p>
     521      <p>This Internet-Draft will expire on April 25, 2012.</p>
    522522      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523523      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    539539         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    540540               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#terminology">Terminology</a></li>
    541                <li>1.2&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     541               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    542542               <li>1.3&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    543543                     <li>1.3.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
    … …  
    659659         </li>
    660660      </ul>
    661       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     661      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    662662      <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    663663         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>.
    664664      </p>
    665       <p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the
    666          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    667          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    668          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     665      <p id="rfc.section.1.2.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     666         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     667      </p>
     668      <p id="rfc.section.1.2.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
     669         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     670      </p>
     671      <p id="rfc.section.1.2.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.3</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
     672      </p>
     673      <p id="rfc.section.1.2.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
     674         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     675         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     676         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     677         error recovery could lead to dangerous consequences.
    669678      </p>
    670679      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    671       <p id="rfc.section.1.3.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.1"><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;D</a> shows the collected ABNF, with the list rule expanded.
     680      <p id="rfc.section.1.3.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;D</a> shows the collected ABNF, with the list rule expanded.
    672681      </p>
    673682      <p id="rfc.section.1.3.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
    … …  
    676685      </p>
    677686      <h3 id="rfc.section.1.3.1"><a href="#rfc.section.1.3.1">1.3.1</a>&nbsp;<a id="core.rules" href="#core.rules">Core Rules</a></h3>
    678       <p id="rfc.section.1.3.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
    679       </p>
    680       <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.3"><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;
    681   <a href="#core.rules" class="smpl">token</a>          = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    682   <a href="#core.rules" class="smpl">word</a>           = &lt;word, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     687      <p id="rfc.section.1.3.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>:
     688      </p>
     689      <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;
     690  <a href="#core.rules" class="smpl">token</a>          = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     691  <a href="#core.rules" class="smpl">word</a>           = &lt;word, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    683692</pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    684693      <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p>
    685       <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.6"><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;
    686   <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    687   <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, 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#quality.values" title="Quality Values">Section 5.3</a>&gt;
     694      <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.7"><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;
     695  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     696  <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, 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#quality.values" title="Quality Values">Section 5.3</a>&gt;
    688697</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    689698      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2>
    … …  
    717726      </p>
    718727      <ul class="empty">
    719          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     728         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    720729         </li>
    721730      </ul>
    … …  
    723732      </p>
    724733      <ul class="empty">
    725          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     734         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    726735         </li>
    727736      </ul>
    … …  
    729738      </p>
    730739      <ul class="empty">
    731          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     740         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</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>.
    732741         </li>
    733742      </ul>
    … …  
    741750         <li>Pointer to specification text</li>
    742751      </ul>
    743       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</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>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     752      <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</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>).
    744753      </p>
    745754      <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
    … …  
    841850               <tr>
    842851                  <td class="left">Content-Length</td>
    843                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</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></td>
     852                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</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></td>
    844853               </tr>
    845854               <tr>
    … …  
    851860      </div>
    852861      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    853       <p id="rfc.section.3.2.p.1">A payload 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.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     862      <p id="rfc.section.3.2.p.1">A payload 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.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    854863         safe and proper transfer of the message.
    855864      </p>
    … …  
    987996         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
    988997      </p>
    989       <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.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> for more information.
     998      <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</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 more information.
    990999      </p>
    9911000      <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    … …  
    10401049      <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    10411050         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1042          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</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>). The default value is q=1.
     1051         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.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>). The default value is q=1.
    10431052      </p>
    10441053      <div class="note" id="rfc.section.6.1.p.5">
    … …  
    11701179         </li>
    11711180         <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable
    1172             unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.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>, a qvalue of 0 means "not acceptable".)
     1181            unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.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>, a qvalue of 0 means "not acceptable".)
    11731182         </li>
    11741183         <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
    … …  
    12841293      </p>
    12851294      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1286 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.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>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1295</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    12871296         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    12881297      </p>
    … …  
    14321441                  <td class="left">compress</td>
    14331442                  <td class="left">UNIX "compress" program method</td>
    1434                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.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>
     1443                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.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>
    14351444                  </td>
    14361445               </tr>
    … …  
    14391448                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    14401449                  </td>
    1441                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</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>
     1450                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</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>
    14421451                  </td>
    14431452               </tr>
    … …  
    14451454                  <td class="left">gzip</td>
    14461455                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    1447                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.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>
     1456                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.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>
    14481457                  </td>
    14491458               </tr>
    … …  
    14821491      </p>
    14831492      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1484       <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>.
     1493      <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>.
    14851494      </p>
    14861495      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    … …  
    17201729      </p>
    17211730      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
    1722       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</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>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
     1731      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</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>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
    17231732      </p>
    17241733      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    … …  
    20322041      </ul>
    20332042      <h2 id="rfc.section.E.18"><a href="#rfc.section.E.18">E.18</a>&nbsp;<a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p3-payload-16</a></h2>
    2034       <p id="rfc.section.E.18.p.1">None yet.</p>
     2043      <p id="rfc.section.E.18.p.1">Closed issues: </p>
     2044      <ul>
     2045         <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"
     2046         </li>
     2047      </ul>
    20352048      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    20362049      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a>
    … …  
    21212134            </li>
    21222135            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2123                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.24">A.6</a><ul>
    2124                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
    2125                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.3.1</a></li>
    2126                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a></li>
    2127                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a></li>
    2128                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.2</a></li>
    2129                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.7</a></li>
    2130                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2.1</a></li>
    2131                         <li><em>Section 5.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li>
    2132                         <li><em>Section 5.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
    2133                         <li><em>Section 5.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
    2134                         <li><em>Section 5.1.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
    2135                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li>
    2136                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">3.1</a></li>
    2137                         <li><em>Section 8.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">A.6</a></li>
    2138                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">9</a></li>
     2136                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.3</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">2.2.1</a>, <a href="#rfc.xref.Part1.15">3.1</a>, <a href="#rfc.xref.Part1.16">3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a>, <a href="#rfc.xref.Part1.20">6.7</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">7.2</a>, <a href="#rfc.xref.Part1.24">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.25">A.6</a><ul>
     2137                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.3</a></li>
     2138                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.3.1</a></li>
     2139                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
     2140                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a></li>
     2141                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li>
     2142                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">3.2</a></li>
     2143                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">6.7</a></li>
     2144                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
     2145                        <li><em>Section 5.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
     2146                        <li><em>Section 5.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">2.2.1</a></li>
     2147                        <li><em>Section 5.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
     2148                        <li><em>Section 5.1.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li>
     2149                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li>
     2150                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.1</a></li>
     2151                        <li><em>Section 8.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">A.6</a></li>
     2152                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">9</a></li>
    21392153                     </ul>
    21402154                  </li>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1443 r1452  
    1616  <!ENTITY ID-YEAR "2011">
    1717  <!ENTITY mdash "&#8212;">
     18  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation                 "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY notation-abnf            "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    267268</section>
    268269
    269 <section title="Requirements" anchor="intro.requirements">
     270<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    270271<t>
    271272   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    274275</t>
    275276<t>
    276    An implementation is not compliant if it fails to satisfy one or more
    277    of the "MUST" or "REQUIRED" level requirements for the protocols it
    278    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    279    level and all the "SHOULD" level requirements for its protocols is said
    280    to be "unconditionally compliant"; one that satisfies all the "MUST"
    281    level requirements but not all the "SHOULD" level requirements for its
    282    protocols is said to be "conditionally compliant".
     277   This document defines conformance criteria for several roles in HTTP
     278   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     279   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     280   for definitions of these terms.
     281</t>
     282<t>
     283   An implementation is considered conformant if it complies with all of the
     284   requirements associated with its role(s). Note that SHOULD-level requirements
     285   are relevant here, unless one of the documented exceptions is applicable.
     286</t>
     287<t>
     288   This document also uses ABNF to define valid protocol elements
     289   (<xref target="notation"/>). In addition to the prose requirements placed
     290   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     291</t>
     292<t>
     293   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     294   protocol element from an invalid construct. However, HTTP does not define
     295   specific error handling mechanisms, except in cases where it has direct
     296   impact on security. This is because different uses of the protocol require
     297   different error handling strategies; for example, a Web browser may wish to
     298   transparently recover from a response where the Location header field
     299   doesn't parse according to the ABNF, whereby in a systems control protocol
     300   using HTTP, this type of error recovery could lead to dangerous consequences.
    283301</t>
    284302</section>
    … …  
    30353053<section title="Since draft-ietf-httpbis-p3-payload-16" anchor="changes.since.16">
    30363054<t>
    3037   None yet.
     3055  Closed issues:
     3056  <list style="symbols">
     3057    <t>
     3058      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     3059      "Document HTTP's error-handling philosophy"
     3060    </t>
     3061  </list>
    30383062</t>
    30393063</section>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1443 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 4, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-10-02">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    430430            </tr>
    431431            <tr>
    432                <td class="left">Expires: April 4, 2012</td>
     432               <td class="left">Expires: April 25, 2012</td>
    433433               <td class="right">J. Mogul</td>
    434434            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">October 2, 2011</td>
     489               <td class="right">October 23, 2011</td>
    490490            </tr>
    491491         </tbody>
    … …  
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on April 4, 2012.</p>
     519      <p>This Internet-Draft will expire on April 25, 2012.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    536536      <ul class="toc">
    537537         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    538                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     538               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    539539               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    540540            </ul>
    … …  
    625625         selected representation.
    626626      </p>
    627       <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>
     627      <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>
    628628      <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"
    629629         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>.
    630630      </p>
    631       <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
    632          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    633          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    634          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     631      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     632         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     633      </p>
     634      <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
     635         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     636      </p>
     637      <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.
     638      </p>
     639      <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
     640         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     641         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     642         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     643         error recovery could lead to dangerous consequences.
    635644      </p>
    636645      <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>
    637       <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.1"><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.
     646      <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.
    638647      </p>
    639648      <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
    … …  
    641650         character).
    642651      </p>
    643       <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:
    644       </p>
    645       <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#notation" class="smpl">OWS</a>           = &lt;OWS, 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>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    646   <a href="#notation" class="smpl">quoted-string</a> = &lt;quoted-string, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     652      <p id="rfc.section.1.2.p.3">The ABNF 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> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:
     653      </p>
     654      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#notation" 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;
     655  <a href="#notation" class="smpl">quoted-string</a> = &lt;quoted-string, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    647656  <a href="#notation" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>&gt;
    648657</pre><div id="rfc.iref.m.1"></div>
    … …  
    882891         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct
    883892            from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings
    884             (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.
     893            (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.
    885894         </p>
    886895      </div>
    … …  
    11881197      <p id="rfc.section.5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    11891198      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1190       <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1199      <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    11911200      </p>
    11921201      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1193       <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1202      <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    11941203      </p>
    11951204      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    … …  
    14211430      </ul>
    14221431      <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a>&nbsp;<a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p4-conditional-16</a></h2>
    1423       <p id="rfc.section.C.18.p.1">None yet.</p>
     1432      <p id="rfc.section.C.18.p.1">Closed issues: </p>
     1433      <ul>
     1434         <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"
     1435         </li>
     1436      </ul>
    14241437      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    14251438      <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a>
    … …  
    14841497            </li>
    14851498            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1486                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">2.3.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
    1487                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
    1488                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    1489                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.2</a></li>
    1490                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2.3.3</a></li>
    1491                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">7</a></li>
     1499                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">1.2</a>, <a href="#rfc.xref.Part1.6">2.3.3</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
     1500                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
     1501                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.2</a></li>
     1502                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
     1503                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2</a></li>
     1504                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2.3.3</a></li>
     1505                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">7</a></li>
    14921506                     </ul>
    14931507                  </li>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1443 r1452  
    1515  <!ENTITY ID-MONTH "October">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1718  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    254255</t>
    255256
    256 <section title="Requirements" anchor="intro.requirements">
     257<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    257258<t>
    258259   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    261262</t>
    262263<t>
    263    An implementation is not compliant if it fails to satisfy one or more
    264    of the "MUST" or "REQUIRED" level requirements for the protocols it
    265    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    266    level and all the "SHOULD" level requirements for its protocols is said
    267    to be "unconditionally compliant"; one that satisfies all the "MUST"
    268    level requirements but not all the "SHOULD" level requirements for its
    269    protocols is said to be "conditionally compliant".
     264   This document defines conformance criteria for several roles in HTTP
     265   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     266   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     267   for definitions of these terms.
     268</t>
     269<t>
     270   An implementation is considered conformant if it complies with all of the
     271   requirements associated with its role(s). Note that SHOULD-level requirements
     272   are relevant here, unless one of the documented exceptions is applicable.
     273</t>
     274<t>
     275   This document also uses ABNF to define valid protocol elements
     276   (<xref target="notation"/>). In addition to the prose requirements placed
     277   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     278</t>
     279<t>
     280   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     281   protocol element from an invalid construct. However, HTTP does not define
     282   specific error handling mechanisms, except in cases where it has direct
     283   impact on security. This is because different uses of the protocol require
     284   different error handling strategies; for example, a Web browser may wish to
     285   transparently recover from a response where the Location header field
     286   doesn't parse according to the ABNF, whereby in a systems control protocol
     287   using HTTP, this type of error recovery could lead to dangerous consequences.
    270288</t>
    271289</section>
    … …  
    18251843<section title="Since draft-ietf-httpbis-p4-conditional-16" anchor="changes.since.16">
    18261844<t>
    1827   None yet.
     1845  Closed issues:
     1846  <list style="symbols">
     1847    <t>
     1848      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     1849      "Document HTTP's error-handling philosophy"
     1850    </t>
     1851  </list>
    18281852</t>
    18291853</section>

  • draft-ietf-httpbis/latest/p5-range.html

    r1443 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 4, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    406406      <meta name="dct.creator" content="Reschke, J. F.">
    407407      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    408       <meta name="dct.issued" scheme="ISO8601" content="2011-10-02">
     408      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    409409      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    410410      <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    432432            </tr>
    433433            <tr>
    434                <td class="left">Expires: April 4, 2012</td>
     434               <td class="left">Expires: April 25, 2012</td>
    435435               <td class="right">J. Mogul</td>
    436436            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">October 2, 2011</td>
     491               <td class="right">October 23, 2011</td>
    492492            </tr>
    493493         </tbody>
    … …  
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on April 4, 2012.</p>
     519      <p>This Internet-Draft will expire on April 25, 2012.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    536536      <ul class="toc">
    537537         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    538                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     538               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    539539               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    540540                     <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
    … …  
    626626         requests for byte ranges.
    627627      </p>
    628       <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>
     628      <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>
    629629      <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"
    630630         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>.
    631631      </p>
    632       <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
    633          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    634          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    635          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     632      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     633         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     634      </p>
     635      <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
     636         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     637      </p>
     638      <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.
     639      </p>
     640      <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
     641         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     642         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     643         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     644         error recovery could lead to dangerous consequences.
    636645      </p>
    637646      <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>
    638       <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.1"><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;C</a> shows the collected ABNF, with the list rule expanded.
     647      <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;C</a> shows the collected ABNF, with the list rule expanded.
    639648      </p>
    640649      <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
    … …  
    643652      </p>
    644653      <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>
    645       <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:
    646       </p>
    647       <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.3"><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;
    648   <a href="#core.rules" class="smpl">token</a>      = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     654      <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> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:
     655      </p>
     656      <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;
     657  <a href="#core.rules" class="smpl">token</a>      = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    649658  <a href="#core.rules" class="smpl">HTTP-date</a>  = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>&gt;
    650659</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>
    … …  
    10461055      </p>
    10471056      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1048       <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1057      <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    10491058      </p>
    10501059      <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
    … …  
    14091418      </ul>
    14101419      <h2 id="rfc.section.D.18"><a href="#rfc.section.D.18">D.18</a>&nbsp;<a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p5-range-16</a></h2>
    1411       <p id="rfc.section.D.18.p.1">None yet.</p>
     1420      <p id="rfc.section.D.18.p.1">Closed issues: </p>
     1421      <ul>
     1422         <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"
     1423         </li>
     1424      </ul>
    14121425      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    14131426      <p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a>
    … …  
    14841497            </li>
    14851498            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1486                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</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">8</a>, <a href="#Part1"><b>9.1</b></a><ul>
    1487                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
    1488                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2.1</a></li>
    1489                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.2.1</a></li>
    1490                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">8</a></li>
     1499                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">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">8</a>, <a href="#Part1"><b>9.1</b></a><ul>
     1500                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
     1501                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.2.1</a></li>
     1502                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
     1503                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a></li>
     1504                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">8</a></li>
    14911505                     </ul>
    14921506                  </li>

  • draft-ietf-httpbis/latest/p5-range.xml

    r1443 r1452  
    1515  <!ENTITY ID-MONTH "October">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1718  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    242243</t>
    243244
    244 <section title="Requirements" anchor="intro.requirements">
     245<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    245246<t>
    246247   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    249250</t>
    250251<t>
    251    An implementation is not compliant if it fails to satisfy one or more
    252    of the "MUST" or "REQUIRED" level requirements for the protocols it
    253    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    254    level and all the "SHOULD" level requirements for its protocols is said
    255    to be "unconditionally compliant"; one that satisfies all the "MUST"
    256    level requirements but not all the "SHOULD" level requirements for its
    257    protocols is said to be "conditionally compliant".
     252   This document defines conformance criteria for several roles in HTTP
     253   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     254   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     255   for definitions of these terms.
     256</t>
     257<t>
     258   An implementation is considered conformant if it complies with all of the
     259   requirements associated with its role(s). Note that SHOULD-level requirements
     260   are relevant here, unless one of the documented exceptions is applicable.
     261</t>
     262<t>
     263   This document also uses ABNF to define valid protocol elements
     264   (<xref target="notation"/>). In addition to the prose requirements placed
     265   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     266</t>
     267<t>
     268   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     269   protocol element from an invalid construct. However, HTTP does not define
     270   specific error handling mechanisms, except in cases where it has direct
     271   impact on security. This is because different uses of the protocol require
     272   different error handling strategies; for example, a Web browser may wish to
     273   transparently recover from a response where the Location header field
     274   doesn't parse according to the ABNF, whereby in a systems control protocol
     275   using HTTP, this type of error recovery could lead to dangerous consequences.
    258276</t>
    259277</section>
    … …  
    17651783<section title="Since draft-ietf-httpbis-p5-range-16" anchor="changes.since.16">
    17661784<t>
    1767   None yet.
     1785  Closed issues:
     1786  <list style="symbols">
     1787    <t>
     1788      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     1789      "Document HTTP's error-handling philosophy"
     1790    </t>
     1791  </list>
    17681792</t>
    17691793</section>

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

    r1449 r1452  
    362362  }
    363363  @bottom-center {
    364        content: "Expires April 20, 2012";
     364       content: "Expires April 25, 2012";
    365365  }
    366366  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-10-18">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <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 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: April 20, 2012</td>
     436               <td class="left">Expires: April 25, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    499499            <tr>
    500500               <td class="left"></td>
    501                <td class="right">October 18, 2011</td>
     501               <td class="right">October 23, 2011</td>
    502502            </tr>
    503503         </tbody>
    … …  
    529529         in progress”.
    530530      </p>
    531       <p>This Internet-Draft will expire on April 20, 2012.</p>
     531      <p>This Internet-Draft will expire on April 25, 2012.</p>
    532532      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    533533      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    550550               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.purpose">Purpose</a></li>
    551551               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#intro.terminology">Terminology</a></li>
    552                <li>1.3&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     552               <li>1.3&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    553553               <li>1.4&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    554554                     <li>1.4.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
    … …  
    727727         </li>
    728728      </ul>
    729       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     729      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    730730      <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    731731         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>.
    732732      </p>
    733       <p id="rfc.section.1.3.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the
    734          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    735          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    736          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     733      <p id="rfc.section.1.3.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     734         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     735      </p>
     736      <p id="rfc.section.1.3.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
     737         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     738      </p>
     739      <p id="rfc.section.1.3.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
     740      </p>
     741      <p id="rfc.section.1.3.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
     742         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     743         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     744         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     745         error recovery could lead to dangerous consequences.
    737746      </p>
    738747      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    739       <p id="rfc.section.1.4.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.1"><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.
     748      <p id="rfc.section.1.4.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.
    740749      </p>
    741750      <p id="rfc.section.1.4.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
    … …  
    744753      </p>
    745754      <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a>&nbsp;<a id="core.rules" href="#core.rules">Core Rules</a></h3>
    746       <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
    747       </p>
    748       <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.3"><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">quoted-string</a> = &lt;quoted-string, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    750   <a href="#core.rules" class="smpl">token</a>         = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     755      <p id="rfc.section.1.4.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>:
     756      </p>
     757      <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;
     758  <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     759  <a href="#core.rules" class="smpl">token</a>         = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    751760</pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    752761      <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p>
    753       <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, 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#header.fields" title="Header Fields">Section 3.2</a>&gt;
     762      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, 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#header.fields" title="Header Fields">Section 3.2</a>&gt;
    754763  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>&gt;
    755   <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    756   <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, 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#header.via" title="Via">Section 8.8</a>&gt;
    757   <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, 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;
     764  <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     765  <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, 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#header.via" title="Via">Section 8.8</a>&gt;
     766  <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, 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;
    758767</pre><h2 id="rfc.section.1.5"><a href="#rfc.section.1.5">1.5</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h2>
    759768      <p id="rfc.section.1.5.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
    … …  
    815824         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    816825      </p>
    817       <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire
     826      <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire
    818827         response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message-body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content)
    819828         response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does
    … …  
    827836      </p>
    828837      <ul>
    829          <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
     838         <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>) and that of the stored response match, and
    830839         </li>
    831840         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    … …  
    10601069         to keep their contents up-to-date.
    10611070      </p>
    1062       <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request
     1071      <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request
    10631072         with an unsafe method is received.
    10641073      </p>
    10651074      <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part
    1066          in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    1067       </p>
    1068       <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<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>) when it receives a non-error response to a request with a method whose safety is unknown.
     1075         in the effective request URI (<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>). This helps prevent denial of service attacks.
     1076      </p>
     1077      <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<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>) when it receives a non-error response to a request with a method whose safety is unknown.
    10691078      </p>
    10701079      <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all
    … …  
    10931102      <ul>
    10941103         <li>adding or removing whitespace, where allowed in the header field's syntax</li>
    1095          <li>combining multiple 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.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
     1104         <li>combining multiple 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.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
    10961105         </li>
    10971106         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
    … …  
    17041713      </p>
    17051714      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1706       <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>.
     1715      <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>.
    17071716      </p>
    17081717      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    … …  
    20752084      <p id="rfc.section.C.18.p.1">Closed issues: </p>
    20762085      <ul>
     2086         <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"
     2087         </li>
    20772088         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/317">http://tools.ietf.org/wg/httpbis/trac/ticket/317</a>&gt;: "Cache-Control directive case sensitivity"
    20782089         </li>
    … …  
    22112222            </li>
    22122223            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2213                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">2.1</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.5</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.7</a>, <a href="#rfc.xref.Part1.16">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
    2214                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a></li>
    2215                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.4.1</a></li>
    2216                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a></li>
    2217                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.15">2.7</a></li>
    2218                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a></li>
    2219                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.5</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a></li>
    2220                         <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.4.2</a></li>
    2221                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">7</a></li>
     2224                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.7</a>, <a href="#rfc.xref.Part1.17">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
     2225                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.4</a></li>
     2226                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.4.1</a></li>
     2227                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
     2228                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li>
     2229                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.16">2.7</a></li>
     2230                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li>
     2231                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li>
     2232                        <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.4.2</a></li>
     2233                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">7</a></li>
    22222234                     </ul>
    22232235                  </li>

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

    r1449 r1452  
    1515  <!ENTITY ID-MONTH "October">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1718  <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    388389</section>
    389390
    390 <section anchor="intro.requirements" title="Requirements">
     391<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    391392<t>
    392393   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    395396</t>
    396397<t>
    397    An implementation is not compliant if it fails to satisfy one or more of
    398    the "MUST" or "REQUIRED" level requirements for the protocols it
    399    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    400    level and all the "SHOULD" level requirements for its protocols is said to
    401    be "unconditionally compliant"; one that satisfies all the "MUST" level
    402    requirements but not all the "SHOULD" level requirements for its protocols
    403    is said to be "conditionally compliant".
     398   This document defines conformance criteria for several roles in HTTP
     399   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     400   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     401   for definitions of these terms.
     402</t>
     403<t>
     404   An implementation is considered conformant if it complies with all of the
     405   requirements associated with its role(s). Note that SHOULD-level requirements
     406   are relevant here, unless one of the documented exceptions is applicable.
     407</t>
     408<t>
     409   This document also uses ABNF to define valid protocol elements
     410   (<xref target="notation"/>). In addition to the prose requirements placed
     411   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     412</t>
     413<t>
     414   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     415   protocol element from an invalid construct. However, HTTP does not define
     416   specific error handling mechanisms, except in cases where it has direct
     417   impact on security. This is because different uses of the protocol require
     418   different error handling strategies; for example, a Web browser may wish to
     419   transparently recover from a response where the Location header field
     420   doesn't parse according to the ABNF, whereby in a systems control protocol
     421   using HTTP, this type of error recovery could lead to dangerous consequences.
    404422</t>
    405423</section>
    … …  
    28952913  <list style="symbols">
    28962914    <t>
     2915      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     2916      "Document HTTP's error-handling philosophy"
     2917    </t>
     2918    <t>
    28972919      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/317"/>:
    28982920      "Cache-Control directive case sensitivity"

  • draft-ietf-httpbis/latest/p7-auth.html

    r1443 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 4, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-10-02">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: April 4, 2012</td>
     437               <td class="left">Expires: April 25, 2012</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">October 2, 2011</td>
     490               <td class="right">October 23, 2011</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on April 4, 2012.</p>
     518      <p>This Internet-Draft will expire on April 25, 2012.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    535535      <ul class="toc">
    536536         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    537                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     537               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    538538               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    539539                     <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
    … …  
    612612         provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.
    613613      </p>
    614       <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>
     614      <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>
    615615      <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"
    616616         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>.
    617617      </p>
    618       <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
    619          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    620          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    621          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     618      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     619         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     620      </p>
     621      <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
     622         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     623      </p>
     624      <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.
     625      </p>
     626      <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
     627         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     628         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     629         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     630         error recovery could lead to dangerous consequences.
    622631      </p>
    623632      <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>
    624       <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.1"><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.
     633      <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.
    625634      </p>
    626635      <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
    … …  
    629638      </p>
    630639      <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>
    631       <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
    632       </p>
    633       <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">BWS</a>           = &lt;BWS, 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>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    634   <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;
    635   <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
    636   <a href="#core.rules" class="smpl">token</a>         = &lt;token, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     640      <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>:
     641      </p>
     642      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">BWS</a>           = &lt;BWS, 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;
     643  <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;
     644  <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, 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#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
     645  <a href="#core.rules" class="smpl">token</a>         = &lt;token, 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;
    637646</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1>
    638647      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2>
    … …  
    695704      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.r.2"></span><span id="rfc.iref.r.3"></span><span id="rfc.iref.g.6"></span>  realm       = "realm" <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> realm-value
    696705  realm-value = quoted-string
    697 </pre><p id="rfc.section.2.2.p.3">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; 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.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
     706</pre><p id="rfc.section.2.2.p.3">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; 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.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
    698707         on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
    699708         database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific
    … …  
    727736            <p>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep
    728737               their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over
    729                which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     738               which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    730739            </p>
    731740         </li>
    … …  
    800809      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    801810      <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable
    802          to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
     811         to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
    803812      </p>
    804813      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    … …  
    824833      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    825834      <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
    826          applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     835         applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    827836      </p>
    828837      <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the
    … …  
    944953         Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
    945954      </p>
    946       <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision.
     955      <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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> for the Acknowledgments related to this document revision.
    947956      </p>
    948957      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    … …  
    11741183      </ul>
    11751184      <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a>&nbsp;<a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p7-auth-16</a></h2>
    1176       <p id="rfc.section.C.18.p.1">None yet.</p>
     1185      <p id="rfc.section.C.18.p.1">Closed issues: </p>
     1186      <ul>
     1187         <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"
     1188         </li>
     1189      </ul>
    11771190      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    11781191      <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a>
    … …  
    12291242            </li>
    12301243            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1231                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</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">2.2</a>, <a href="#rfc.xref.Part1.8">2.3.1</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a>, <a href="#rfc.xref.Part1.11">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
    1232                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
    1233                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a></li>
    1234                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">2.3.1</a></li>
    1235                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li>
    1236                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a></li>
    1237                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">7</a></li>
     1244                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">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">2.2</a>, <a href="#rfc.xref.Part1.9">2.3.1</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a>, <a href="#rfc.xref.Part1.12">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
     1245                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
     1246                        <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></li>
     1247                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
     1248                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">2.3.1</a></li>
     1249                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li>
     1250                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a></li>
     1251                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">7</a></li>
    12381252                     </ul>
    12391253                  </li>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1443 r1452  
    1616  <!ENTITY ID-YEAR "2011">
    1717  <!ENTITY mdash "&#8212;">
     18  <!ENTITY architecture                 "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation                     "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    230231</t>
    231232
    232 <section title="Requirements" anchor="intro.requirements">
     233<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    233234<t>
    234235   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    … …  
    237238</t>
    238239<t>
    239    An implementation is not compliant if it fails to satisfy one or more
    240    of the "MUST" or "REQUIRED" level requirements for the protocols it
    241    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    242    level and all the "SHOULD" level requirements for its protocols is said
    243    to be "unconditionally compliant"; one that satisfies all the "MUST"
    244    level requirements but not all the "SHOULD" level requirements for its
    245    protocols is said to be "conditionally compliant".
     240   This document defines conformance criteria for several roles in HTTP
     241   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     242   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     243   for definitions of these terms.
     244</t>
     245<t>
     246   An implementation is considered conformant if it complies with all of the
     247   requirements associated with its role(s). Note that SHOULD-level requirements
     248   are relevant here, unless one of the documented exceptions is applicable.
     249</t>
     250<t>
     251   This document also uses ABNF to define valid protocol elements
     252   (<xref target="notation"/>). In addition to the prose requirements placed
     253   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     254</t>
     255<t>
     256   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     257   protocol element from an invalid construct. However, HTTP does not define
     258   specific error handling mechanisms, except in cases where it has direct
     259   impact on security. This is because different uses of the protocol require
     260   different error handling strategies; for example, a Web browser may wish to
     261   transparently recover from a response where the Location header field
     262   doesn't parse according to the ABNF, whereby in a systems control protocol
     263   using HTTP, this type of error recovery could lead to dangerous consequences.
    246264</t>
    247265</section>
    … …  
    13891407<section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16">
    13901408<t>
    1391   None yet.
     1409  Closed issues:
     1410  <list style="symbols">
     1411    <t>
     1412      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     1413      "Document HTTP's error-handling philosophy"
     1414    </t>
     1415  </list>
    13921416</t>
    13931417</section>
Note: See TracChangeset for help on using the changeset viewer.