Ignore:
Timestamp:
02/09/12 05:29:11 (7 years ago)
Author:
fielding@…
Message:

(editorial) missed moving an intro para for header fields

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

Legend:

Unmodified
Added
Removed

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

    r1847 r1848  
    12001200      </p>
    12011201      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
    1202       <p id="rfc.section.4.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource,
    1203          or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of their syntax.
    1204       </p>
    12051202      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="request.fields" href="#request.fields">Request-modifier Header Fields</a></h2>
    12061203      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="response.fields" href="#response.fields">Status-modifier Header Fields</a></h2>
    … …  
    12511248               <tr>
    12521249                  <td class="left">Host</td>
    1253                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     1250                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
    12541251               </tr>
    12551252               <tr>
    … …  
    12911288               <tr>
    12921289                  <td class="left">TE</td>
    1293                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     1290                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
    12941291               </tr>
    12951292               <tr>
    … …  
    13021299      <h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
    13031300      <p id="rfc.section.4.6.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    1304          status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     1301         status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    13051302      </p>
    13061303      <div id="rfc.table.u.2">
    … …  
    16271624      <p id="rfc.section.5.2.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    16281625         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    1629          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1626         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    16301627      </p>
    16311628      <div id="rfc.iref.23"></div>
    16321629      <div id="rfc.iref.s.4"></div>
    16331630      <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    1634       <p id="rfc.section.5.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1631      <p id="rfc.section.5.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    16351632         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    16361633      </p>
    … …  
    16871684      <div id="rfc.iref.s.9"></div>
    16881685      <h3 id="rfc.section.5.3.4"><a href="#rfc.section.5.3.4">5.3.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1689       <p id="rfc.section.5.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     1686      <p id="rfc.section.5.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    16901687      </p>
    16911688      <p id="rfc.section.5.3.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code
    … …  
    17221719         another input action.
    17231720      </p>
    1724       <p id="rfc.section.5.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     1721      <p id="rfc.section.5.3.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    17251722      </p>
    17261723      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    19811978      <div id="rfc.iref.s.35"></div>
    19821979      <h3 id="rfc.section.5.5.15"><a href="#rfc.section.5.5.15">5.5.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    1983       <p id="rfc.section.5.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
     1980      <p id="rfc.section.5.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) specifying the required protocols.
    19841981      </p>
    19851982      <div id="rfc.figure.u.4"></div>
    … …  
    20462043      <p id="rfc.section.5.6.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    20472044         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    2048          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
     2045         in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    20492046      </p>
    20502047      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    … …  
    21752172      </p>
    21762173      <ul class="empty">
    2177          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     2174         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    21782175         </li>
    21792176      </ul>
    … …  
    21812178      </p>
    21822179      <ul class="empty">
    2183          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     2180         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    21842181         </li>
    21852182      </ul>
    … …  
    21872184      </p>
    21882185      <ul class="empty">
    2189          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
     2186         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>.
    21902187         </li>
    21912188      </ul>
    … …  
    22832280               <tr>
    22842281                  <td class="left">Content-Length</td>
    2285                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
     2282                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a></td>
    22862283               </tr>
    22872284               <tr>
    … …  
    22932290      </div>
    22942291      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    2295       <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
     2292      <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
    22962293      </p>
    22972294      <div id="rfc.iref.r.1"></div>
    … …  
    23122309         in an HTTP message, it is referred to as the payload of the message.
    23132310      </p>
    2314       <p id="rfc.section.8.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
     2311      <p id="rfc.section.8.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> that might have been applied to ensure safe and proper transfer of the message.
    23152312      </p>
    23162313      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
    23172314      <p id="rfc.section.8.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    23182315      <p id="rfc.section.8.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    2319       <p id="rfc.section.8.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     2316      <p id="rfc.section.8.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    23202317         rules are used (with the first applicable one being selected):
    23212318      </p>
    … …  
    27922789      </p>
    27932790      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
    2794 </pre><p id="rfc.section.10.8.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     2791</pre><p id="rfc.section.10.8.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    27952792         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    27962793      </p>
    … …  
    28862883      </p>
    28872884      <ul class="empty">
    2888          <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. It does not support any expect-params.
     2885         <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>. It does not support any expect-params.
    28892886         </li>
    28902887      </ul>
    … …  
    29972994      <h2 id="rfc.section.10.17"><a href="#rfc.section.10.17">10.17</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    29982995      <p id="rfc.section.10.17.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    2999       <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     2996      <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    30002997         identifying the application.
    30012998      </p>
    … …  
    30033000</pre><p id="rfc.section.10.17.p.4">Example:</p>
    30043001      <div id="rfc.figure.u.58"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    3005 </pre><p id="rfc.section.10.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
     3002</pre><p id="rfc.section.10.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the <a href="#header.server" class="smpl">Server</a> header field. Instead, it <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.via" class="smpl">Via</a> field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    30063003      </p>
    30073004      <div class="note" id="rfc.section.10.17.p.7">
    … …  
    30193016         user agent limitations.
    30203017      </p>
    3021       <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
     3018      <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance
    30223019         for identifying the application.
    30233020      </p>
    … …  
    30563053         specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    30573054      </p>
    3058       <p id="rfc.section.11.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
     3055      <p id="rfc.section.11.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
    30593056         algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
    30603057         can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
    … …  
    33993396      </p>
    34003397      <h3 id="rfc.section.11.3.1"><a href="#rfc.section.11.3.1">11.3.1</a>&nbsp;<a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3>
    3401       <p id="rfc.section.11.3.1.p.1">The requirements for header field names are defined in <a href="http://tools.ietf.org/html/rfc3864#section-4.1">Section 4.1</a> of <a href="#RFC3864" id="rfc.xref.RFC3864.2"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them
     3398      <p id="rfc.section.11.3.1.p.1">Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource,
     3399         or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.
     3400      </p>
     3401      <p id="rfc.section.11.3.1.p.2">The requirements for header field names are defined in <a href="http://tools.ietf.org/html/rfc3864#section-4.1">Section 4.1</a> of <a href="#RFC3864" id="rfc.xref.RFC3864.2"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them
    34023402         with "X-" if they are to be registered (either immediately or in the future).
    34033403      </p>
    3404       <p id="rfc.section.11.3.1.p.2">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     3404      <p id="rfc.section.11.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Appendix B</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
    34053405         can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>.
    34063406      </p>
    3407       <p id="rfc.section.11.3.1.p.3">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
     3407      <p id="rfc.section.11.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
    34083408         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    34093409         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.35"><cite title="HTTP/1.1, part 1: Message Routing and Syntax&#34;">[Part1]</cite></a>).
    34103410      </p>
    3411       <p id="rfc.section.11.3.1.p.4">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
     3411      <p id="rfc.section.11.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
    34123412         these:
    34133413      </p>
    … …  
    34153415                     "http://without-a-comma.example.com/"
    34163416  Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
    3417 </pre><p id="rfc.section.11.3.1.p.6">Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside
     3417</pre><p id="rfc.section.11.3.1.p.7">Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside
    34183418         double-quotes will likely cause unnecessary confusion.
    34193419      </p>
    3420       <p id="rfc.section.11.3.1.p.7">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;10.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
     3420      <p id="rfc.section.11.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;10.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    34213421         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    34223422         it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section&nbsp;6.5</a>).
    34233423      </p>
    3424       <p id="rfc.section.11.3.1.p.8">Authors of specifications defining new header fields are advised to consider documenting: </p>
     3424      <p id="rfc.section.11.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p>
    34253425      <ul>
    34263426         <li>
    … …  
    50335033            </li>
    50345034            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    5035                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.3.1</a>, <a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.9">3.3.7</a>, <a href="#rfc.xref.Part1.10">3.3.8</a>, <a href="#rfc.xref.Part1.11">4</a>, <a href="#rfc.xref.Part1.12">4.5</a>, <a href="#rfc.xref.Part1.13">4.5</a>, <a href="#rfc.xref.Part1.14">4.6</a>, <a href="#rfc.xref.Part1.15">5.2.1</a>, <a href="#rfc.xref.Part1.16">5.2.2</a>, <a href="#rfc.xref.Part1.17">5.3.4</a>, <a href="#rfc.xref.Part1.18">5.3.6</a>, <a href="#rfc.xref.Part1.19">5.5.15</a>, <a href="#rfc.xref.Part1.20">5.6.6</a>, <a href="#rfc.xref.Part1.21">6.4</a>, <a href="#rfc.xref.Part1.22">6.4</a>, <a href="#rfc.xref.Part1.23">6.4</a>, <a href="#rfc.xref.Part1.24">7.1</a>, <a href="#rfc.xref.Part1.25">7.2</a>, <a href="#rfc.xref.Part1.26">8</a>, <a href="#rfc.xref.Part1.27">8.1</a>, <a href="#rfc.xref.Part1.28">10.8</a>, <a href="#rfc.xref.Part1.29">10.11</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.31">10.17</a>, <a href="#rfc.xref.Part1.32">10.18</a>, <a href="#rfc.xref.Part1.33">11.1.2</a>, <a href="#rfc.xref.Part1.34">11.3.1</a>, <a href="#rfc.xref.Part1.35">11.3.1</a>, <a href="#rfc.xref.Part1.36">11.3.1</a>, <a href="#rfc.xref.Part1.37">11.3.1</a>, <a href="#rfc.xref.Part1.38">11.3.1</a>, <a href="#rfc.xref.Part1.39">11.4</a>, <a href="#rfc.xref.Part1.40">11.4.1</a>, <a href="#rfc.xref.Part1.41">11.4.1</a>, <a href="#rfc.xref.Part1.42">11.4.2</a>, <a href="#rfc.xref.Part1.43">11.4.2</a>, <a href="#rfc.xref.Part1.44">11.4.2</a>, <a href="#rfc.xref.Part1.45">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">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>, <a href="#rfc.xref.Part1.57">D</a><ul>
     5035                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.3.1</a>, <a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.9">3.3.7</a>, <a href="#rfc.xref.Part1.10">3.3.8</a>, <a href="#rfc.xref.Part1.11">4.5</a>, <a href="#rfc.xref.Part1.12">4.5</a>, <a href="#rfc.xref.Part1.13">4.6</a>, <a href="#rfc.xref.Part1.14">5.2.1</a>, <a href="#rfc.xref.Part1.15">5.2.2</a>, <a href="#rfc.xref.Part1.16">5.3.4</a>, <a href="#rfc.xref.Part1.17">5.3.6</a>, <a href="#rfc.xref.Part1.18">5.5.15</a>, <a href="#rfc.xref.Part1.19">5.6.6</a>, <a href="#rfc.xref.Part1.20">6.4</a>, <a href="#rfc.xref.Part1.21">6.4</a>, <a href="#rfc.xref.Part1.22">6.4</a>, <a href="#rfc.xref.Part1.23">7.1</a>, <a href="#rfc.xref.Part1.24">7.2</a>, <a href="#rfc.xref.Part1.25">8</a>, <a href="#rfc.xref.Part1.26">8.1</a>, <a href="#rfc.xref.Part1.27">10.8</a>, <a href="#rfc.xref.Part1.28">10.11</a>, <a href="#rfc.xref.Part1.29">10.17</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.31">10.18</a>, <a href="#rfc.xref.Part1.32">11.1.2</a>, <a href="#rfc.xref.Part1.33">11.3.1</a>, <a href="#rfc.xref.Part1.34">11.3.1</a>, <a href="#rfc.xref.Part1.35">11.3.1</a>, <a href="#rfc.xref.Part1.36">11.3.1</a>, <a href="#rfc.xref.Part1.37">11.3.1</a>, <a href="#rfc.xref.Part1.38">11.3.1</a>, <a href="#rfc.xref.Part1.39">11.4</a>, <a href="#rfc.xref.Part1.40">11.4.1</a>, <a href="#rfc.xref.Part1.41">11.4.1</a>, <a href="#rfc.xref.Part1.42">11.4.2</a>, <a href="#rfc.xref.Part1.43">11.4.2</a>, <a href="#rfc.xref.Part1.44">11.4.2</a>, <a href="#rfc.xref.Part1.45">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">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>, <a href="#rfc.xref.Part1.57">D</a><ul>
    50365036                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    5037                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">5.3.4</a></li>
     5037                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">5.3.4</a></li>
    50385038                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li>
    5039                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">5.6.6</a></li>
     5039                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.6.6</a></li>
    50405040                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a></li>
    5041                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">4</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.32">10.18</a>, <a href="#rfc.xref.Part1.36">11.3.1</a></li>
     5041                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">10.17</a>, <a href="#rfc.xref.Part1.31">10.18</a>, <a href="#rfc.xref.Part1.33">11.3.1</a>, <a href="#rfc.xref.Part1.36">11.3.1</a></li>
    50425042                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a></li>
    50435043                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">11.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.55">D</a></li>
    5044                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">5.3.6</a>, <a href="#rfc.xref.Part1.25">7.2</a>, <a href="#rfc.xref.Part1.26">8</a>, <a href="#rfc.xref.Part1.33">11.1.2</a></li>
    5045                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">7.1</a></li>
     5044                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">5.3.6</a>, <a href="#rfc.xref.Part1.24">7.2</a>, <a href="#rfc.xref.Part1.25">8</a>, <a href="#rfc.xref.Part1.32">11.1.2</a></li>
     5045                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">7.1</a></li>
    50465046                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.40">11.4.1</a></li>
    50475047                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.38">11.3.1</a></li>
    5048                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">6.4</a>, <a href="#rfc.xref.Part1.42">11.4.2</a></li>
     5048                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">6.4</a>, <a href="#rfc.xref.Part1.42">11.4.2</a></li>
    50495049                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.39">11.4</a>, <a href="#rfc.xref.Part1.41">11.4.1</a></li>
    5050                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">6.4</a>, <a href="#rfc.xref.Part1.43">11.4.2</a></li>
    5051                         <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.4</a>, <a href="#rfc.xref.Part1.44">11.4.2</a></li>
    5052                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">4.5</a></li>
     5050                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">6.4</a>, <a href="#rfc.xref.Part1.43">11.4.2</a></li>
     5051                        <li><em>Section 4.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">6.4</a>, <a href="#rfc.xref.Part1.44">11.4.2</a></li>
     5052                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">4.5</a></li>
    50535053                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.7">3.3.1</a>, <a href="#rfc.xref.Part1.10">3.3.8</a></li>
    5054                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">4.5</a></li>
    5055                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.14">4.6</a>, <a href="#rfc.xref.Part1.27">8.1</a>, <a href="#rfc.xref.Part1.28">10.8</a></li>
    5056                         <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.31">10.17</a>, <a href="#rfc.xref.Part1.46">C</a></li>
     5054                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">4.5</a></li>
     5055                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.13">4.6</a>, <a href="#rfc.xref.Part1.26">8.1</a>, <a href="#rfc.xref.Part1.27">10.8</a></li>
     5056                        <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.30">10.17</a>, <a href="#rfc.xref.Part1.46">C</a></li>
    50575057                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">11.3.1</a></li>
    5058                         <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">5.2.1</a>, <a href="#rfc.xref.Part1.29">10.11</a></li>
    5059                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">5.2.2</a>, <a href="#rfc.xref.Part1.19">5.5.15</a></li>
     5058                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">5.2.1</a>, <a href="#rfc.xref.Part1.28">10.11</a></li>
     5059                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">5.2.2</a>, <a href="#rfc.xref.Part1.18">5.5.15</a></li>
    50605060                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.3.7</a></li>
    50615061                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">13</a></li>

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

    r1847 r1848  
    959959
    960960<section title="Header Fields" anchor="header.fields">
    961 <t>
    962    Header fields are key value pairs that can be used to communicate data about
    963    the message, its payload, the target resource, or about the connection
    964    itself (i.e., control data).  See &header-fields; for a general definition
    965    of their syntax.
    966 </t>
    967961
    968962<section title="Request-modifier Header Fields" anchor="request.fields">
    … …  
    42364230<section title="Considerations for New Header Fields" anchor="considerations.for.new.header.fields">
    42374231<t>
     4232   Header fields are key:value pairs that can be used to communicate data about
     4233   the message, its payload, the target resource, or the connection
     4234   (i.e., control data).  See &header-fields; for a general definition
     4235   of header field syntax in HTTP messages.
     4236</t>
     4237<t>
    42384238   The requirements for header field names are defined in
    42394239   <xref target="RFC3864" x:fmt="of" x:sec="4.1"/>.  Authors of specifications
Note: See TracChangeset for help on using the changeset viewer.