Changeset 2030


Ignore:
Timestamp:
Dec 4, 2012, 4:58:55 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) Deal with first half of mnot p1 feedback; addresses #408

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2029 r2030  
    596596               </li>
    597597               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a><ul>
    598                      <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li>
    599                      <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li>
    600                      <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#field.length">Field Length</a></li>
    601                      <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#field.components">Field value components</a></li>
     598                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#field.extensibility">Field Extensibility</a></li>
     599                     <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#field.order">Field Order</a></li>
     600                     <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#whitespace">Whitespace</a></li>
     601                     <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#field.parsing">Field Parsing</a></li>
     602                     <li><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;&nbsp;&nbsp;<a href="#field.limits">Field Limits</a></li>
     603                     <li><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;&nbsp;&nbsp;<a href="#field.components">Field value components</a></li>
    602604                  </ul>
    603605               </li>
     
    735737         into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.
    736738      </p>
    737       <p id="rfc.section.1.p.5">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead,
     739      <p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead,
    738740         we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of
    739741         recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding
     
    791793      <div id="rfc.iref.r.1"></div>
    792794      <p id="rfc.section.2.1.p.2">The terms client and server refer only to the roles that these programs perform for a particular connection. The same program
    793          might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the
    794          term "<dfn>origin server</dfn>" to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term
    795          "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message.
     795         might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders
     796         (web-based robots), command-line tools, native applications, and mobile apps. The term "<dfn>origin server</dfn>" is used to refer to the program that can originate authoritative responses to a request. For general requirements, we use
     797         the terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" to refer to any component that sends or receives, respectively, a given message.
    796798      </p>
    797799      <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the differences between HTTP and MIME messages).
     
    10621064      <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    10631065         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    1064          even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> include a userinfo subcomponent (and its "@" delimiter) when transmitting an "http" URI in a message. Recipients of HTTP messages
    1065          that contain a URI reference <em class="bcp14">SHOULD</em> parse for the existence of userinfo and treat its presence as an error, likely indicating that the deprecated subcomponent
    1066          is being used to obscure the authority for the sake of phishing attacks.
     1066         even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST</em> exclude the userinfo subcomponent (and its "@" delimiter) when an "http" URI is transmitted within a message as a request
     1067         target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake
     1068         of phishing attacks.
    10671069      </p>
    10681070      <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a>&nbsp;<a id="https.uri" href="#https.uri">https URI scheme</a></h3>
     
    11491151      </p>
    11501152      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#request.line" class="smpl">request-line</a>   = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a>
    1151 </pre><p id="rfc.section.3.1.1.p.3">A server <em class="bcp14">MUST</em> be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message.
    1152       </p>
    1153       <div id="rfc.iref.m.2"></div>
     1153</pre><div id="rfc.iref.m.2"></div>
    11541154      <div id="method">
    1155          <p id="rfc.section.3.1.1.p.4">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
     1155         <p id="rfc.section.3.1.1.p.3">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    11561156      </div>
    11571157      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1158 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1158</pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    11591159      </p>
    11601160      <div id="rfc.iref.r.6"></div>
    1161       <p id="rfc.section.3.1.1.p.7">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
    1162       </p>
    1163       <p id="rfc.section.3.1.1.p.8">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line
     1161      <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
     1162      </p>
     1163      <p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line
    11641164         into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section&nbsp;3.5</a>).
    11651165      </p>
    1166       <p id="rfc.section.3.1.1.p.9">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
     1166      <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
    11671167         directly instead of properly encoding or excluding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
    11681168         crafted to bypass security filters along the request chain.
    11691169      </p>
    1170       <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
     1170      <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    11711171         it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    11721172      </p>
    1173       <p id="rfc.section.3.1.1.p.11">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.
     1173      <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
    11741174      </p>
    11751175      <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="status.line" href="#status.line">Status Line</a></h3>
     
    11781178      </p>
    11791179      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    1180 </pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message.
    1181       </p>
    1182       <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
     1180</pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    11831181         the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    11841182         for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     
    11861184      </p>
    11871185      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#status.line" class="smpl">status-code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    1188 </pre><p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
     1186</pre><p id="rfc.section.3.1.2.p.5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
    11891187         code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text
    11901188         clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
     
    12011199  <a href="#header.fields" class="smpl">obs-fold</a>       = <a href="#core.rules" class="smpl">CRLF</a> ( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
    12021200                 ; obsolete line folding
    1203                  ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
     1201                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>
    12041202</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    12051203         the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12061204      </p>
    1207       <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
    1208          new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this
    1209          specification and in many other specifications outside the standards process. New header fields can be introduced without
    1210          changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize
    1211          them.
    1212       </p>
    1213       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    1214       </p>
    1215       <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
     1205      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3>
     1206      <p id="rfc.section.3.2.1.p.1">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
     1207         new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this
     1208         specification and in many other specifications outside the core standard. New header fields can be introduced without changing
     1209         the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
     1210      </p>
     1211      <p id="rfc.section.3.2.1.p.2">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1212      </p>
     1213      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.order" href="#field.order">Field Order</a></h3>
     1214      <p id="rfc.section.3.2.2.p.1">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    12161215         to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include
    12171216         conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
    12181217      </p>
    1219       <p id="rfc.section.3.2.p.7">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)].
    1220          Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing
     1218      <p id="rfc.section.3.2.2.p.2">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)].
     1219      </p>
     1220      <p id="rfc.section.3.2.2.p.3">Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing
    12211221         the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by
    12221222         a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation
    12231223         of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message.
    12241224      </p>
    1225       <div class="note" id="rfc.section.3.2.p.8">
    1226          <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice can occur multiple times, but does not use the list syntax, and thus
    1227             cannot be combined into a single line (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.)
     1225      <div class="note" id="rfc.section.3.2.2.p.4">
     1226         <p> <b>Note:</b> In practice, the "Set-Cookie" header field (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on
     1227            multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle
     1228            "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.)
    12281229         </p>
    12291230      </div>
    1230       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="whitespace" href="#whitespace">Whitespace</a></h3>
     1231      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="whitespace" href="#whitespace">Whitespace</a></h3>
    12311232      <div id="rule.LWS">
    1232          <p id="rfc.section.3.2.1.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),
     1233         <p id="rfc.section.3.2.3.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),
    12331234            and BWS ("bad" whitespace).
    12341235         </p>
    12351236      </div>
    12361237      <div id="rule.OWS">
    1237          <p id="rfc.section.3.2.1.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting
     1238         <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be generated or be generated as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting
    12381239            the field value or forwarding the message downstream.
    12391240         </p>
    12401241      </div>
    12411242      <div id="rule.RWS">
    1242          <p id="rfc.section.3.2.1.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the
     1243         <p id="rfc.section.3.2.3.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be generated as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the
    12431244            message downstream.
    12441245         </p>
    12451246      </div>
    12461247      <div id="rule.BWS">
    1247          <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace, for historical reasons, but senders <em class="bcp14">SHOULD NOT</em> produce it in messages; recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
     1248         <p id="rfc.section.3.2.3.p.4">BWS is used where the grammar allows optional whitespace, for historical reasons, but senders <em class="bcp14">SHOULD NOT</em> generate it in messages; recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
    12481249         </p>
    12491250      </div>
    12501251      <div id="rule.whitespace">
    1251          <p id="rfc.section.3.2.1.p.5">      </p>
     1252         <p id="rfc.section.3.2.3.p.5">      </p>
    12521253      </div>
    12531254      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span>  <a href="#rule.whitespace" class="smpl">OWS</a>            = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> )
     
    12571258  <a href="#rule.whitespace" class="smpl">BWS</a>            = <a href="#rule.whitespace" class="smpl">OWS</a>
    12581259                 ; "bad" whitespace
    1259 </pre><h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="field.parsing" href="#field.parsing">Field Parsing</a></h3>
    1260       <p id="rfc.section.3.2.2.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
     1260</pre><h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="field.parsing" href="#field.parsing">Field Parsing</a></h3>
     1261      <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace
    12611262         have led to security vulnerabilities in request routing and response handling. Any received request message that contains
    12621263         whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream.
    12631264      </p>
    1264       <p id="rfc.section.3.2.2.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading
     1265      <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading
    12651266         or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace
    12661267         octet of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field).
    12671268      </p>
    1268       <p id="rfc.section.3.2.2.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
     1269      <p id="rfc.section.3.2.4.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    12691270         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1270          (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
     1271         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
    12711272         message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets
    12721273         (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
    12731274      </p>
    1274       <p id="rfc.section.3.2.2.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
    1275       </p>
    1276       <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="field.length" href="#field.length">Field Length</a></h3>
    1277       <p id="rfc.section.3.2.3.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a <a href="p2-semantics.html#status.4xx" class="smpl">4xx
    1278             (Client Error)</a> status code if the received header field(s) would be longer than the server wishes to handle.
    1279       </p>
    1280       <p id="rfc.section.3.2.3.p.2">A client that receives response header fields that are longer than it wishes to handle can only treat it as a server error.</p>
    1281       <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header field length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.
    1282       </p>
    1283       <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
     1275      <p id="rfc.section.3.2.4.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
     1276      </p>
     1277      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>
     1278      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole.
     1279         Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
     1280         semantics.
     1281      </p>
     1282      <p id="rfc.section.3.2.5.p.2">A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process.
     1283      </p>
     1284      <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MUST</em> be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such
     1285         that the dropped value(s) can be safely ignored without changing the response semantics.
     1286      </p>
     1287      <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
    12841288      <div id="rule.token.separators">
    1285          <p id="rfc.section.3.2.4.p.1">        Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These
     1289         <p id="rfc.section.3.2.6.p.1">        Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These
    12861290            special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    12871291         </p>
     
    13001304                 / "]" / "?" / "=" / "{" / "}"
    13011305</pre><div id="rule.quoted-string">
    1302          <p id="rfc.section.3.2.4.p.3">      A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
     1306         <p id="rfc.section.3.2.6.p.3">      A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
    13031307      </div>
    13041308      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span>  <a href="#rule.quoted-string" class="smpl">quoted-string</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
     
    13061310  <a href="#rule.quoted-string" class="smpl">obs-text</a>       = %x80-FF
    13071311</pre><div id="rule.quoted-pair">
    1308          <p id="rfc.section.3.2.4.p.5">  The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>
     1312         <p id="rfc.section.3.2.6.p.5">  The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>
    13091313      </div>
    13101314      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.48"></span>  <a href="#rule.quoted-pair" class="smpl">quoted-pair</a>    = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    1311 </pre><p id="rfc.section.3.2.4.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
    1312       </p>
    1313       <p id="rfc.section.3.2.4.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet).
     1315</pre><p id="rfc.section.3.2.6.p.7">Recipients that process the value of a quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
     1316      </p>
     1317      <p id="rfc.section.3.2.6.p.8">Senders <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that
     1318         string.
    13141319      </p>
    13151320      <div id="rule.comment">
    1316          <p id="rfc.section.3.2.4.p.9">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
     1321         <p id="rfc.section.3.2.6.p.9">    Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
    13171322            in fields containing "comment" as part of their field value definition.
    13181323         </p>
     
    13211326  <a href="#rule.comment" class="smpl">ctext</a>          = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    13221327</pre><div id="rule.quoted-cpair">
    1323          <p id="rfc.section.3.2.4.p.11">  The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>
     1328         <p id="rfc.section.3.2.6.p.11">  The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>
    13241329      </div>
    13251330      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>   = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    1326 </pre><p id="rfc.section.3.2.4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and
     1331</pre><p id="rfc.section.3.2.6.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and
    13271332         ")").
    13281333      </p>
     
    15311536      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2>
    15321537      <p id="rfc.section.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
    1533          indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary
     1538         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary
    15341539         for the recipient to verify that it has received the full message.
    15351540      </p>
     
    28182823      <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly
    28192824         negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0
    2820          persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header field to the next inbound server, which would result in a hung connection.
     2825         persistent connections are faulty; for example, if an HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header field to the next inbound server, which would result in a hung connection.
    28212826      </p>
    28222827      <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header field, targeted specifically at proxies. In practice,
     
    28432848      </p>
    28442849      <p id="rfc.section.A.2.p.5">Minimum supported sizes for various protocol elements have been suggested, to improve interoperability.</p>
    2845       <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>)
     2850      <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>)
    28462851      </p>
    28472852      <p id="rfc.section.A.2.p.7">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted
     
    28612866      </p>
    28622867      <p id="rfc.section.A.2.p.13">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed
    2863          where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section&nbsp;3.2.1</a>)
     2868         where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section&nbsp;3.2.3</a>)
    28642869      </p>
    28652870      <p id="rfc.section.A.2.p.14">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been
    2866          clarified. (<a href="#field.components" title="Field value components">Section&nbsp;3.2.4</a>)
    2867       </p>
    2868       <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section&nbsp;3.2.4</a>)
    2869       </p>
    2870       <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section&nbsp;3.2.4</a>)
     2871         clarified. (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
     2872      </p>
     2873      <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
     2874      </p>
     2875      <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
    28712876      </p>
    28722877      <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a>)
     
    29372942      <p id="rfc.section.B.p.9">For example, given these ABNF productions:</p>
    29382943      <div id="rfc.figure.u.63"></div><pre class="text">  example-list      = 1#example-list-elmt
    2939   example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section&nbsp;3.2.4</a>
     2944  example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>
    29402945</pre><p id="rfc.section.B.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p>
    29412946      <div id="rfc.figure.u.64"></div><pre class="text">  "foo,bar"
     
    31033108                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">4.1</a></li>
    31043109                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3105                   <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.10"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.12">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3110                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.10"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.12">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    31063111                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">4.2.1</a></li>
    31073112                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3108                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.9"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.11">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3113                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.9"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.11">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    31093114                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
    31103115               </ul>
     
    31303135                        <li><tt>authority</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>2.7</b></a></li>
    31313136                        <li><tt>authority-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.82"><b>5.3</b></a></li>
    3132                         <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.1</b></a></li>
     3137                        <li><tt>BWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>3.2.3</b></a></li>
    31333138                        <li><tt>chunk</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.63"><b>4.1</b></a></li>
    31343139                        <li><tt>chunk-data</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>4.1</b></a></li>
     
    31383143                        <li><tt>chunk-size</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.64"><b>4.1</b></a></li>
    31393144                        <li><tt>chunked-body</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.62"><b>4.1</b></a></li>
    3140                         <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.4</b></a></li>
     3145                        <li><tt>comment</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.49"><b>3.2.6</b></a></li>
    31413146                        <li><tt>Connection</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.1</b></a></li>
    31423147                        <li><tt>connection-option</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.92"><b>6.1</b></a></li>
     
    31443149                        <li>CR&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>1.2</b></a></li>
    31453150                        <li>CRLF&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>1.2</b></a></li>
    3146                         <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.4</b></a></li>
     3151                        <li><tt>ctext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.50"><b>3.2.6</b></a></li>
    31473152                        <li>CTL&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>1.2</b></a></li>
    31483153                        <li><tt>date2</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>4</b></a></li>
     
    31673172                        <li><tt>method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>3.1.1</b></a></li>
    31683173                        <li><tt>obs-fold</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.37"><b>3.2</b></a></li>
    3169                         <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.4</b></a></li>
     3174                        <li><tt>obs-text</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.47"><b>3.2.6</b></a></li>
    31703175                        <li>OCTET&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>1.2</b></a></li>
    31713176                        <li><tt>origin-form</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.80"><b>5.3</b></a></li>
    3172                         <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2.1</b></a></li>
     3177                        <li><tt>OWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.38"><b>3.2.3</b></a></li>
    31733178                        <li><tt>partial-URI</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>2.7</b></a></li>
    31743179                        <li><tt>path-absolute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>2.7</b></a></li>
     
    31773182                        <li><tt>protocol-version</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.88"><b>5.7</b></a></li>
    31783183                        <li><tt>pseudonym</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.90"><b>5.7</b></a></li>
    3179                         <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.4</b></a></li>
     3184                        <li><tt>qdtext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.46"><b>3.2.6</b></a></li>
    31803185                        <li><tt>qdtext-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.72"><b>4.1</b></a></li>
    31813186                        <li><tt>query</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>2.7</b></a></li>
    3182                         <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.2.4</b></a></li>
    3183                         <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.4</b></a></li>
     3187                        <li><tt>quoted-cpair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.51"><b>3.2.6</b></a></li>
     3188                        <li><tt>quoted-pair</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>3.2.6</b></a></li>
    31843189                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.71"><b>4.1</b></a></li>
    3185                         <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.4</b></a></li>
     3190                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>3.2.6</b></a></li>
    31863191                        <li><tt>rank</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.3</b></a></li>
    31873192                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>3.1.2</b></a></li>
     
    31903195                        <li><tt>request-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>3.1.1</b></a></li>
    31913196                        <li><tt>request-target</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.79"><b>5.3</b></a></li>
    3192                         <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2.1</b></a></li>
     3197                        <li><tt>RWS</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>3.2.3</b></a></li>
    31933198                        <li>SP&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>1.2</b></a></li>
    3194                         <li><tt>special</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.4</b></a></li>
     3199                        <li><tt>special</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.6</b></a></li>
    31953200                        <li><tt>start-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>3.1</b></a></li>
    31963201                        <li><tt>status-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2</b></a></li>
     
    31983203                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>4.3</b></a></li>
    31993204                        <li><tt>t-ranking</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>4.3</b></a></li>
    3200                         <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.4</b></a></li>
     3205                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>3.2.6</b></a></li>
    32013206                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>4.3</b></a></li>
    3202                         <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.4</b></a></li>
     3207                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.6</b></a></li>
    32033208                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>4.1.1</b></a></li>
    32043209                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>4.1</b></a></li>
     
    32133218                        <li>VCHAR&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>1.2</b></a></li>
    32143219                        <li><tt>Via</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.85"><b>5.7</b></a></li>
    3215                         <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.4</b></a></li>
     3220                        <li><tt>word</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.6</b></a></li>
    32163221                     </ul>
    32173222                  </li>
     
    32323237                  <li>interception proxy&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>2.3</b></a></li>
    32333238                  <li>intermediary&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>2.3</b></a></li>
    3234                   <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.2</a>, <a href="#ISO-8859-1"><b>10.2</b></a></li>
     3239                  <li><em>ISO-8859-1</em>&nbsp;&nbsp;<a href="#rfc.xref.ISO-8859-1.1">3.2.4</a>, <a href="#ISO-8859-1"><b>10.2</b></a></li>
    32353240               </ul>
    32363241            </li>
    32373242            <li><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul>
    3238                   <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2</a>, <a href="#Kri2001"><b>10.2</b></a></li>
     3243                  <li><em>Kri2001</em>&nbsp;&nbsp;<a href="#rfc.xref.Kri2001.1">3.2.2</a>, <a href="#Kri2001"><b>10.2</b></a></li>
    32393244               </ul>
    32403245            </li>
     
    32623267            </li>
    32633268            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3264                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3269                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    32653270                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    32663271                        <li><em>Section 3.1.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.8</a></li>
     
    32843289                        <li><em>Section 8.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.8</a></li>
    32853290                        <li><em>Section 8.4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.8</a></li>
    3286                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2</a></li>
     3291                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    32873292                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    32883293                     </ul>
     
    33263331                     </ul>
    33273332                  </li>
    3328                   <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li>
     3333                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2.4</a>, <a href="#RFC2047"><b>10.2</b></a></li>
    33293334                  <li><em>RFC2068</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.4">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul>
    33303335                        <li><em>Section 19.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li>
     
    33803385                     </ul>
    33813386                  </li>
    3382                   <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>
     3387                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="#RFC6265"><b>10.2</b></a></li>
    33833388               </ul>
    33843389            </li>
     
    34093414                     </ul>
    34103415                  </li>
    3411                   <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.2</a>, <a href="#USASCII"><b>10.1</b></a></li>
     3416                  <li><em>USASCII</em>&nbsp;&nbsp;<a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.4</a>, <a href="#USASCII"><b>10.1</b></a></li>
    34123417                  <li>user agent&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>2.1</b></a></li>
    34133418               </ul>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2029 r2030  
    185185</t>
    186186<t>
    187    One consequence of HTTP flexibility is that the protocol cannot be
     187   One consequence of this flexibility is that the protocol cannot be
    188188   defined in terms of what occurs behind the interface. Instead, we
    189189   are limited to defining the syntax of communication, the intent
     
    298298   The terms client and server refer only to the roles that
    299299   these programs perform for a particular connection.  The same program
    300    might act as a client on some connections and a server on others.  We use
    301    the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request,
    302    such as a WWW browser, editor, or spider (web-traversing robot), and
    303    the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate
    304    authoritative responses to a request.  For general requirements, we use
    305    the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message
    306    and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the
    307    message.
     300   might act as a client on some connections and a server on others.
     301   We use the term "<x:dfn>user agent</x:dfn>" to refer to any of the various
     302   client programs that initiate a request, including (but not limited to)
     303   browsers, spiders (web-based robots), command-line tools, native
     304   applications, and mobile apps.  The term "<x:dfn>origin server</x:dfn>" is
     305   used to refer to the program that can originate authoritative responses to
     306   a request. For general requirements, we use the terms
     307   "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" to refer to any
     308   component that sends or receives, respectively, a given message.
    308309</t>
    309310<t>
     
    887888   invocation options, configuration files, or bookmark lists, even
    888889   though such usage might expose a user identifier or password.
    889    Senders &MUST-NOT; include a userinfo subcomponent (and its "@"
    890    delimiter) when transmitting an "http" URI in a message.  Recipients
    891    of HTTP messages that contain a URI reference &SHOULD; parse for the
    892    existence of userinfo and treat its presence as an error, likely
    893    indicating that the deprecated subcomponent is being used to obscure
     890   Senders &MUST; exclude the userinfo subcomponent (and its "@"
     891   delimiter) when an "http" URI is transmitted within a message as a
     892   request target or header field value.
     893   Recipients of an "http" URI reference &SHOULD; parse for userinfo and
     894   treat its presence as an error, since it is likely being used to obscure
    894895   the authority for the sake of phishing attacks.
    895896</t>
     
    10681069  <x:ref>request-line</x:ref>   = <x:ref>method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-version</x:ref> <x:ref>CRLF</x:ref>
    10691070</artwork></figure>
    1070 <t>
    1071    A server &MUST; be able to parse any received message that begins
    1072    with a request-line and matches the ABNF rule for HTTP-message.
    1073 </t>
    10741071<iref primary="true" item="method"/>
    10751072<t anchor="method">
     
    11201117   Various ad-hoc limitations on request-line length are found in practice.
    11211118   It is &RECOMMENDED; that all HTTP senders and recipients support, at a
    1122    minimum, request-line lengths of up to 8000 octets.
     1119   minimum, request-line lengths of 8000 octets.
    11231120</t>
    11241121</section>
     
    11381135  <x:ref>status-line</x:ref> = <x:ref>HTTP-version</x:ref> <x:ref>SP</x:ref> <x:ref>status-code</x:ref> <x:ref>SP</x:ref> <x:ref>reason-phrase</x:ref> <x:ref>CRLF</x:ref>
    11391136</artwork></figure>
    1140 <t>
    1141    A client &MUST; be able to parse any received message that begins
    1142    with a status-line and matches the ABNF rule for HTTP-message.
    1143 </t>
    11441137<t>
    11451138   The status-code element is a 3-digit integer code describing the
     
    11931186   timestamp for the message in which it appears.
    11941187</t>
     1188
     1189<section title="Field Extensibility" anchor="field.extensibility">
    11951190<t>
    11961191   HTTP header fields are fully extensible: there is no limit on the
    11971192   introduction of new field names, each presumably defining new semantics,
    1198    or on the number of header fields used in a given message.  Existing
     1193   nor on the number of header fields used in a given message.  Existing
    11991194   fields are defined in each part of this specification and in many other
    1200    specifications outside the standards process.
     1195   specifications outside the core standard.
    12011196   New header fields can be introduced without changing the protocol version
    12021197   if their defined semantics allow them to be safely ignored by recipients
     
    12121207   Unrecognized header fields &SHOULD; be ignored by other recipients.
    12131208</t>
     1209</section>
     1210
     1211<section title="Field Order" anchor="field.order">
    12141212<t>
    12151213   The order in which header fields with differing field names are
     
    12271225   sent in a message unless the entire field value for that
    12281226   header field is defined as a comma-separated list [i.e., #(values)].
     1227</t>
     1228<t>
    12291229   Multiple header fields with the same field name can be combined into
    12301230   one "field-name: field-value" pair, without changing the semantics of the
     
    12381238<x:note>
    12391239  <t>
    1240    &Note; The "Set-Cookie" header field as implemented in
    1241    practice can occur multiple times, but does not use the list syntax, and
    1242    thus cannot be combined into a single line (<xref target="RFC6265"/>). (See Appendix A.2.3 of <xref target="Kri2001"/>
    1243    for details.)
    1244 </t>
     1240   &Note; In practice, the "Set-Cookie" header field (<xref target="RFC6265"/>)
     1241   often appears multiple times in a response message and does not use the
     1242   list syntax, violating the above requirements on multiple header fields
     1243   with the same name. Since it cannot be combined into a single field-value,
     1244   recipients ought to handle "Set-Cookie" as a special case while processing
     1245   header fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for details.)
     1246  </t>
    12451247</x:note>
     1248</section>
    12461249
    12471250<section title="Whitespace" anchor="whitespace">
     
    12531256<t anchor="rule.OWS">
    12541257   The OWS rule is used where zero or more linear whitespace octets might
    1255    appear. OWS &SHOULD; either not be produced or be produced as a single
     1258   appear. OWS &SHOULD; either not be generated or be generated as a single
    12561259   SP. Multiple OWS octets that occur within field-content &SHOULD; either
    12571260   be replaced with a single SP or transformed to all SP octets (each
     
    12611264<t anchor="rule.RWS">
    12621265   RWS is used when at least one linear whitespace octet is required to
    1263    separate field tokens. RWS &SHOULD; be produced as a single SP.
     1266   separate field tokens. RWS &SHOULD; be generated as a single SP.
    12641267   Multiple RWS octets that occur within field-content &SHOULD; either
    12651268   be replaced with a single SP or transformed to all SP octets before
     
    12681271<t anchor="rule.BWS">
    12691272   BWS is used where the grammar allows optional whitespace, for historical
    1270    reasons, but senders &SHOULD-NOT; produce it in messages;
     1273   reasons, but senders &SHOULD-NOT; generate it in messages;
    12711274   recipients &MUST; accept such bad optional whitespace and remove it before
    12721275   interpreting the field value or forwarding the message downstream.
     
    13111314   folding except within the message/http media type
    13121315   (<xref target="internet.media.type.message.http"/>).
    1313    HTTP senders &MUST-NOT; produce messages that include line folding
     1316   HTTP senders &MUST-NOT; generate messages that include line folding
    13141317   (i.e., that contain any field-value that matches the obs-fold rule) unless
    13151318   the message is intended for packaging within the message/http media type.
     
    13311334</section>
    13321335
    1333 <section title="Field Length" anchor="field.length">
    1334 <t>
    1335    HTTP does not place a pre-defined limit on the length of header fields,
    1336    either in isolation or as a set. A server &MUST; be prepared to receive
    1337    request header fields of unbounded length and respond with a <x:ref>4xx
    1338    (Client Error)</x:ref> status code if the received header field(s) would be
    1339    longer than the server wishes to handle.
    1340 </t>
    1341 <t>
    1342    A client that receives response header fields that are longer than it wishes
    1343    to handle can only treat it as a server error.
    1344 </t>
    1345 <t>
    1346    Various ad-hoc limitations on header field length are found in practice. It
    1347    is &RECOMMENDED; that all HTTP senders and recipients support messages whose
    1348    combined header fields have 4000 or more octets.
     1336<section title="Field Limits" anchor="field.limits">
     1337<t>
     1338   HTTP does not place a pre-defined limit on the length of each header field
     1339   or on the length of the header block as a whole.  Various ad-hoc
     1340   limitations on individual header field length are found in practice,
     1341   often depending on the specific field semantics.
     1342</t>
     1343<t>
     1344   A server &MUST; be prepared to receive request header fields of unbounded
     1345   length and respond with an appropriate <x:ref>4xx (Client Error)</x:ref>
     1346   status code if the received header field(s) are larger than the server
     1347   wishes to process.
     1348</t>
     1349<t>
     1350   A client &MUST; be prepared to receive response header fields of unbounded
     1351   length. A client &MAY; discard or truncate received header fields that are
     1352   larger than the client wishes to process if the field semantics are such
     1353   that the dropped value(s) can be safely ignored without changing the
     1354   response semantics.
    13491355</t>
    13501356</section>
     
    13981404</artwork></figure>
    13991405<t>
    1400    Recipients that process the value of the quoted-string &MUST; handle a
     1406   Recipients that process the value of a quoted-string &MUST; handle a
    14011407   quoted-pair as if it were replaced by the octet following the backslash.
    14021408</t>
    14031409<t>
    1404    Senders &SHOULD-NOT; escape octets in quoted-strings that do not require
    1405    escaping (i.e., other than DQUOTE and the backslash octet).
     1410   Senders &SHOULD-NOT; generate a quoted-pair in a quoted-string except where
     1411   necessary to quote DQUOTE and backslash octets occurring within that string.
    14061412</t>
    14071413<t anchor="rule.comment">
     
    18911897   transfer it as a series of chunks, each with its own size indicator,
    18921898   followed by an &OPTIONAL; trailer containing header fields. This
    1893    allows dynamically produced content to be transferred along with the
     1899   allows dynamically generated content to be transferred along with the
    18941900   information necessary for the recipient to verify that it has
    18951901   received the full message.
     
    47024708   with a "Connection: keep-alive" request header field. However, some
    47034709   experimental implementations of HTTP/1.0 persistent connections are faulty;
    4704    for example, if a HTTP/1.0 proxy server doesn't understand
     4710   for example, if an HTTP/1.0 proxy server doesn't understand
    47054711   <x:ref>Connection</x:ref>, it will erroneously forward that header field
    47064712   to the next inbound server, which would result in a hung connection.
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2027 r2030  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 4, 2013";
     451       content: "Expires June 7, 2013";
    452452  }
    453453  @bottom-right {
     
    496496      <meta name="dct.creator" content="Reschke, J. F.">
    497497      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    498       <meta name="dct.issued" scheme="ISO8601" content="2012-12-01">
     498      <meta name="dct.issued" scheme="ISO8601" content="2012-12-04">
    499499      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    500500      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    524524            <tr>
    525525               <td class="left">Intended status: Standards Track</td>
    526                <td class="right">December 1, 2012</td>
     526               <td class="right">December 4, 2012</td>
    527527            </tr>
    528528            <tr>
    529                <td class="left">Expires: June 4, 2013</td>
     529               <td class="left">Expires: June 7, 2013</td>
    530530               <td class="right"></td>
    531531            </tr>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on June 4, 2013.</p>
     557      <p>This Internet-Draft will expire on June 7, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    26512651      <div id="rfc.iref.74"></div>
    26522652      <h3 id="rfc.section.7.5.7"><a href="#rfc.section.7.5.7">7.5.7</a>&nbsp;<a id="status.408" href="#status.408">408 Request Timeout</a></h3>
    2653       <p id="rfc.section.7.5.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time.
     2653      <p id="rfc.section.7.5.7.p.1">The server did not receive a complete request message within the time that it was prepared to wait. If the client has sent
     2654         a request, it <em class="bcp14">MAY</em> repeat that request, possibly on a new connection if the server indicates that the present connection is being closed.
    26542655      </p>
    26552656      <div id="rfc.iref.74"></div>
     
    32213222         a zero-length payload body.
    32223223      </p>
    3223       <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status
     3224      <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that would cause a response containing that status
    32243225         code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields
    32253226         (e.g., what fields are required and what fields can modify the semantics). A response that can transfer a payload ought to
     
    34733474      <p id="rfc.section.9.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
    34743475         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    3475          quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3476         quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    34763477      </p>
    34773478      <p id="rfc.section.9.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
     
    37973798      </h2>
    37983799      <p id="rfc.section.10.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports.
    3799          A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
     3800         An HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.
    38003801      </p>
    38013802      <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
     
    41544155         trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section&nbsp;8.4.1</a>)
    41554156      </p>
    4156       <p id="rfc.section.C.p.30">The requirement to produce a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
     4157      <p id="rfc.section.C.p.30">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
    41574158      </p>
    41584159      <p id="rfc.section.C.p.31">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section&nbsp;3.1.1.2</a>)
     
    41814182      <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
    41824183      </p>
    4183       <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4184   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    4185   <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     4184      <div id="rfc.figure.u.65"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4185  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     4186  <a href="#imported.abnf" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    41864187  <a href="#imported.abnf" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    41874188  <a href="#imported.abnf" class="smpl">absolute-URI</a>  = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4188   <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4189  <a href="#imported.abnf" class="smpl">comment</a>       = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    41894190  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;comment, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    41904191  <a href="#imported.abnf" class="smpl">partial-URI</a>   = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    4191   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4192   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    4193   <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     4192  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4193  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     4194  <a href="#imported.abnf" class="smpl">word</a>          = &lt;word, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    41944195</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    41954196      <div id="rfc.figure.u.66"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     
    45414542                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a></li>
    45424543                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">6.5.3</a>, <a href="#rfc.xref.Part1.28">8.4.2</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.52">D</a></li>
    4543                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>
    4544                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>
     4544                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>
     4545                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>
    45454546                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li>
    45464547                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">7.3.6</a>, <a href="#rfc.xref.Part1.30">9.1.2</a></li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2027 r2030  
    32223222  <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/>
    32233223<t>
    3224    The client did not produce a request within the time that the server
    3225    was prepared to wait. The client &MAY; repeat the request without
    3226    modifications at any later time.
     3224   The server did not receive a complete request message within the time that
     3225   it was prepared to wait. If the client has sent a request, it &MAY; repeat
     3226   that request, possibly on a new connection if the server indicates that the
     3227   present connection is being closed.
    32273228</t>
    32283229</section>
     
    41244125<t>
    41254126   A definition for a new status code ought to explain the request
    4126    conditions that produce a response containing that status code (e.g.,
     4127   conditions that would cause a response containing that status code (e.g.,
    41274128   combinations of request header fields and/or method(s)) along with any
    41284129   dependencies on response header fields (e.g., what fields are required
     
    47554756   Since tunneled data is opaque to the proxy, there are additional
    47564757   risks to tunneling to other well-known or reserved ports.
    4757    A HTTP client CONNECTing to port 25 could relay spam
     4758   An HTTP client CONNECTing to port 25 could relay spam
    47584759   via SMTP, for example. As such, proxies &SHOULD; restrict CONNECT
    47594760   access to a small number of known ports.
     
    58065807</t>
    58075808<t>
    5808   The requirement to produce a <x:ref>Via</x:ref> header field has been moved
     5809  The requirement to generate a <x:ref>Via</x:ref> header field has been moved
    58095810  from the description of the <x:ref>Server</x:ref> header field to
    58105811  &header-via;.
  • draft-ietf-httpbis/latest/p6-cache.html

    r2027 r2030  
    452452  }
    453453  @bottom-center {
    454        content: "Expires June 4, 2013";
     454       content: "Expires June 7, 2013";
    455455  }
    456456  @bottom-right {
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2012-12-01">
     500      <meta name="dct.issued" scheme="ISO8601" content="2012-12-04">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: June 4, 2013</td>
     526               <td class="left">Expires: June 7, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">December 1, 2012</td>
     535               <td class="right">December 4, 2012</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on June 4, 2013.</p>
     561      <p>This Internet-Draft will expire on June 7, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    700700      </p>
    701701      <ul class="empty">
    702          <li>A conformant implementation of a HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define
     702         <li>A conformant implementation of an HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define
    703703            conformance for HTTP/1.0 caches.
    704704         </li>
     
    14361436      <p id="rfc.section.7.3.p.8">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
    14371437         are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use
    1438          of 32-bit integers for time values), and many caches will evict a response far sooner than that. Therefore, senders ought
    1439          not produce them.
     1438         of 32-bit integers for time values), and many caches will evict a response far sooner than that.
    14401439      </p>
    14411440      <p id="rfc.section.7.3.p.9">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires values to a response unless these values were associated with the resource by a system or user with a reliable
     
    19471946      <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
    19481947      </p>
    1949       <div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1948      <div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    19501949  <a href="#imported.abnf" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    1951   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    1952   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1950  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     1951  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    19531952
    19541953  <a href="#imported.abnf" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
     
    21262125                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.17">B</a></li>
    21272126                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.12">B</a></li>
    2128                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">B</a></li>
    2129                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a></li>
     2127                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">B</a></li>
     2128                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a></li>
    21302129                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a></li>
    21312130                        <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">B</a></li>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2027 r2030  
    175175   <x:dfn>cache</x:dfn>
    176176   <list>
    177       <t>A conformant implementation of a HTTP cache. Note that this implies
     177      <t>A conformant implementation of an HTTP cache. Note that this implies
    178178        an HTTP/1.1 cache; this specification does not define conformance
    179179        for HTTP/1.0 caches.</t>
     
    16261626   problems (e.g., clock overflows due to use of 32-bit integers for
    16271627   time values), and many caches will evict a response far sooner than
    1628    that. Therefore, senders ought not produce them.
     1628   that.
    16291629</t>
    16301630<t>
Note: See TracChangeset for help on using the changeset viewer.