Changeset 1848 for draft-ietf-httpbis/latest
- Timestamp:
- 02/09/12 05:29:11 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1847 r1848 1200 1200 </p> 1201 1201 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <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"">[Part1]</cite></a> for a general definition of their syntax.1204 </p>1205 1202 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request.fields" href="#request.fields">Request-modifier Header Fields</a></h2> 1206 1203 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="response.fields" href="#response.fields">Status-modifier Header Fields</a></h2> … … 1251 1248 <tr> 1252 1249 <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.1 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a></td> 1254 1251 </tr> 1255 1252 <tr> … … 1291 1288 <tr> 1292 1289 <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.1 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a></td> 1294 1291 </tr> 1295 1292 <tr> … … 1302 1299 <h2 id="rfc.section.4.6"><a href="#rfc.section.4.6">4.6</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1303 1300 <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.1 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 1305 1302 </p> 1306 1303 <div id="rfc.table.u.2"> … … 1627 1624 <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 1628 1625 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.1 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1630 1627 </p> 1631 1628 <div id="rfc.iref.23"></div> 1632 1629 <div id="rfc.iref.s.4"></div> 1633 1630 <h3 id="rfc.section.5.2.2"><a href="#rfc.section.5.2.2">5.2.2</a> <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.1 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1631 <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"">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1635 1632 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1636 1633 </p> … … 1687 1684 <div id="rfc.iref.s.9"></div> 1688 1685 <h3 id="rfc.section.5.3.4"><a href="#rfc.section.5.3.4">5.3.4</a> <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.1 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[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>). 1690 1687 </p> 1691 1688 <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 … … 1722 1719 another input action. 1723 1720 </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.1 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 1725 1722 </p> 1726 1723 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1981 1978 <div id="rfc.iref.s.35"></div> 1982 1979 <h3 id="rfc.section.5.5.15"><a href="#rfc.section.5.5.15">5.5.15</a> <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.1 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>) specifying the required protocols. 1984 1981 </p> 1985 1982 <div id="rfc.figure.u.4"></div> … … 2046 2043 <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 2047 2044 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"">[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"">[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. 2049 2046 </p> 2050 2047 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> … … 2175 2172 </p> 2176 2173 <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.2 1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 2178 2175 </li> 2179 2176 </ul> … … 2181 2178 </p> 2182 2179 <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.2 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 2184 2181 </li> 2185 2182 </ul> … … 2187 2184 </p> 2188 2185 <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.2 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. 2190 2187 </li> 2191 2188 </ul> … … 2283 2280 <tr> 2284 2281 <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.2 4"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a></td> 2286 2283 </tr> 2287 2284 <tr> … … 2293 2290 </div> 2294 2291 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <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.2 5"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[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. 2296 2293 </p> 2297 2294 <div id="rfc.iref.r.1"></div> … … 2312 2309 in an HTTP message, it is referred to as the payload of the message. 2313 2310 </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.2 6"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[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. 2315 2312 </p> 2316 2313 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> 2317 2314 <p id="rfc.section.8.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 2318 2315 <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.2 7"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following2316 <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"">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 2320 2317 rules are used (with the first applicable one being selected): 2321 2318 </p> … … 2792 2789 </p> 2793 2790 <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.2 8"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME2791 </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"">[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 2795 2792 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. 2796 2793 </p> … … 2886 2883 </p> 2887 2884 <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.2 9"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>. It does not support any expect-params. 2889 2886 </li> 2890 2887 </ul> … … 2997 2994 <h2 id="rfc.section.10.17"><a href="#rfc.section.10.17">10.17</a> <a id="header.server" href="#header.server">Server</a></h2> 2998 2995 <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 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"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2996 <p id="rfc.section.10.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 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"">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 3000 2997 identifying the application. 3001 2998 </p> … … 3003 3000 </pre><p id="rfc.section.10.17.p.4">Example:</p> 3004 3001 <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.3 1"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[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"">[Part1]</cite></a>). 3006 3003 </p> 3007 3004 <div class="note" id="rfc.section.10.17.p.7"> … … 3019 3016 user agent limitations. 3020 3017 </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 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.3 2"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance3018 <p id="rfc.section.10.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 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"">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 3022 3019 for identifying the application. 3023 3020 </p> … … 3056 3053 specific to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3057 3054 </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.3 3"><cite title="HTTP/1.1, part 1: Message Routing and Syntax"">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing3055 <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"">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing 3059 3056 algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods 3060 3057 can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain … … 3399 3396 </p> 3400 3397 <h3 id="rfc.section.11.3.1"><a href="#rfc.section.11.3.1">11.3.1</a> <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"">[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 3402 3402 with "X-" if they are to be registered (either immediately or in the future). 3403 3403 </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"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3404 <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"">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 3405 3405 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>. 3406 3406 </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 allowed3407 <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 3408 3408 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 3409 3409 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"">[Part1]</cite></a>). 3410 3410 </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 like3411 <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 3412 3412 these: 3413 3413 </p> … … 3415 3415 "http://without-a-comma.example.com/" 3416 3416 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 inside3417 </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 3418 3418 double-quotes will likely cause unnecessary confusion. 3419 3419 </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 10.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing3420 <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 10.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 3421 3421 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 3422 3422 it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section 6.5</a>). 3423 3423 </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> 3425 3425 <ul> 3426 3426 <li> … … 5033 5033 </li> 5034 5034 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5035 <li><em>Part1</em> <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> <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> 5036 5036 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5037 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.1 7">5.3.4</a></li>5037 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.16">5.3.4</a></li> 5038 5038 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 5039 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1. 20">5.6.6</a></li>5039 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.19">5.6.6</a></li> 5040 5040 <li><em>Section 2.7</em> <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> <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> <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> 5042 5042 <li><em>Section 3.2.1</em> <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> 5043 5043 <li><em>Section 3.2.4</em> <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> <a href="#rfc.xref.Part1.1 8">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> <a href="#rfc.xref.Part1.2 4">7.1</a></li>5044 <li><em>Section 3.3</em> <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> <a href="#rfc.xref.Part1.23">7.1</a></li> 5046 5046 <li><em>Section 4</em> <a href="#rfc.xref.Part1.40">11.4.1</a></li> 5047 5047 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.38">11.3.1</a></li> 5048 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.2 1">6.4</a>, <a href="#rfc.xref.Part1.42">11.4.2</a></li>5048 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.20">6.4</a>, <a href="#rfc.xref.Part1.42">11.4.2</a></li> 5049 5049 <li><em>Section 4.2</em> <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> <a href="#rfc.xref.Part1.2 2">6.4</a>, <a href="#rfc.xref.Part1.43">11.4.2</a></li>5051 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.2 3">6.4</a>, <a href="#rfc.xref.Part1.44">11.4.2</a></li>5052 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 3">4.5</a></li>5050 <li><em>Section 4.2.2</em> <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> <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> <a href="#rfc.xref.Part1.12">4.5</a></li> 5053 5053 <li><em>Section 5.3</em> <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> <a href="#rfc.xref.Part1.1 2">4.5</a></li>5055 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.1 4">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> <a href="#rfc.xref.Part1.8">3.3.7</a>, <a href="#rfc.xref.Part1.3 1">10.17</a>, <a href="#rfc.xref.Part1.46">C</a></li>5054 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.11">4.5</a></li> 5055 <li><em>Section 5.5</em> <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> <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> 5057 5057 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.37">11.3.1</a></li> 5058 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.1 5">5.2.1</a>, <a href="#rfc.xref.Part1.29">10.11</a></li>5059 <li><em>Section 6.4</em> <a href="#rfc.xref.Part1.1 6">5.2.2</a>, <a href="#rfc.xref.Part1.19">5.5.15</a></li>5058 <li><em>Section 6.3</em> <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> <a href="#rfc.xref.Part1.15">5.2.2</a>, <a href="#rfc.xref.Part1.18">5.5.15</a></li> 5060 5060 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.9">3.3.7</a></li> 5061 5061 <li><em>Section 9</em> <a href="#rfc.xref.Part1.45">13</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1847 r1848 959 959 960 960 <section title="Header Fields" anchor="header.fields"> 961 <t>962 Header fields are key value pairs that can be used to communicate data about963 the message, its payload, the target resource, or about the connection964 itself (i.e., control data). See &header-fields; for a general definition965 of their syntax.966 </t>967 961 968 962 <section title="Request-modifier Header Fields" anchor="request.fields"> … … 4236 4230 <section title="Considerations for New Header Fields" anchor="considerations.for.new.header.fields"> 4237 4231 <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> 4238 4238 The requirements for header field names are defined in 4239 4239 <xref target="RFC3864" x:fmt="of" x:sec="4.1"/>. Authors of specifications
Note: See TracChangeset
for help on using the changeset viewer.