Changeset 1900
- Timestamp:
- 16/09/12 06:35:33 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1898 r1900 890 890 </p> 891 891 <p id="rfc.section.3.p.4">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 5.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in 892 the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section 5.3.3</a>) represents an anonymous resource for providing data to be processed, such as a specific encoding format for the information 893 that a user entered within an HTML form. 894 </p> 895 <p id="rfc.section.3.p.5">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section 5.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.2.1</a>), whereas the same response to POST might contain either a representation of the processing result or a current representation 896 of the target resource after applying the processing. Response messages with an error status code usually contain a representation 897 that describes the error and what next steps are suggested for resolving it. 898 </p> 899 <p id="rfc.section.3.p.6">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.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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. 892 the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section 5.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within 893 an HTML form. 894 </p> 895 <p id="rfc.section.3.p.5">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section 5.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.2.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a 896 current representation of the target resource after applying the processing. Some responses only contain the representation's 897 header fields as the payload. Response messages with an error status code usually contain a representation that describes 898 the error and what next steps are suggested for resolving it. 900 899 </p> 901 900 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="associating.representation.with.resource" href="#associating.representation.with.resource">Associating a Representation with its Resource</a></h2> 902 901 <p id="rfc.section.3.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 903 902 <p id="rfc.section.3.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 904 <p id="rfc.section.3.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. 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following903 <p id="rfc.section.3.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.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 905 904 rules are used (with the first applicable one being selected): 906 905 </p> … … 1029 1028 </p> 1030 1029 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></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> 1031 </pre><p id="rfc.section.3.2.4.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. 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1030 </pre><p id="rfc.section.3.2.4.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.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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 1032 1031 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. 1033 1032 </p> … … 1220 1219 <tr> 1221 1220 <td class="left">Content-Length</td> 1222 <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. 10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>1221 <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.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1223 1222 </tr> 1224 1223 <tr> … … 1230 1229 </div> 1231 1230 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 1232 <p id="rfc.section.4.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.1 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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.1231 <p id="rfc.section.4.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.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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. 1233 1232 </p> 1234 1233 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="methods" href="#methods">Request Methods</a></h1> … … 1502 1501 its behavior to blind forwarding of packets until the connection is closed. 1503 1502 </p> 1504 <p id="rfc.section.5.3.6.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1503 <p id="rfc.section.5.3.6.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1505 1504 For example, 1506 1505 </p> … … 1547 1546 body to make more detailed queries on the server. 1548 1547 </p> 1549 <p id="rfc.section.5.3.7.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.1548 <p id="rfc.section.5.3.7.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 1550 1549 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 1551 1550 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be … … 1565 1564 </p> 1566 1565 <p id="rfc.section.5.3.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1567 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding1566 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1568 1567 messages in an infinite loop. 1569 1568 </p> 1570 <p id="rfc.section.5.3.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1569 <p id="rfc.section.5.3.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1571 1570 </p> 1572 1571 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> … … 1589 1588 <tr> 1590 1589 <td class="left">Host</td> 1591 <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 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>1590 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1592 1591 </tr> 1593 1592 <tr> … … 2001 2000 <tr> 2002 2001 <td class="left">TE</td> 2003 <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 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>2002 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 2004 2003 </tr> 2005 2004 <tr> … … 2055 2054 user agent limitations. 2056 2055 </p> 2057 <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9.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.1 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2056 <p id="rfc.section.6.5.3.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9.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.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2058 2057 for identifying the application. 2059 2058 </p> … … 2339 2338 <div id="rfc.iref.55"></div> 2340 2339 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 2341 <p id="rfc.section.7.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.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined2340 <p id="rfc.section.7.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.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 2342 2341 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 2343 2342 </p> … … 2390 2389 <div id="rfc.iref.56"></div> 2391 2390 <h3 id="rfc.section.7.3.4"><a href="#rfc.section.7.3.4">7.3.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 2392 <p id="rfc.section.7.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. 20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2391 <p id="rfc.section.7.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.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2393 2392 </p> 2394 2393 <p id="rfc.section.7.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 … … 2423 2422 another input action. 2424 2423 </p> 2425 <p id="rfc.section.7.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.2 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.2424 <p id="rfc.section.7.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.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 2426 2425 </p> 2427 2426 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2660 2659 <div id="rfc.iref.58"></div> 2661 2660 <h3 id="rfc.section.7.5.15"><a href="#rfc.section.7.5.15">7.5.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2662 <p id="rfc.section.7.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.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) specifying the required protocols.2661 <p id="rfc.section.7.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.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) specifying the required protocols. 2663 2662 </p> 2664 2663 <div id="rfc.figure.u.33"></div> … … 2719 2718 <p id="rfc.section.7.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 2720 2719 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2721 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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.2720 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[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. 2722 2721 </p> 2723 2722 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 2724 2723 <p id="rfc.section.8.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 2725 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.2 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).2724 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.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 2726 2725 </p> 2727 2726 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> … … 2934 2933 <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a> <a id="header.server" href="#header.server">Server</a></h3> 2935 2934 <p id="rfc.section.8.4.2.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2936 <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9.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.2 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2935 <p id="rfc.section.8.4.2.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 9.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.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2937 2936 identifying the application. 2938 2937 </p> … … 2940 2939 </pre><p id="rfc.section.8.4.2.p.4">Example:</p> 2941 2940 <div id="rfc.figure.u.46"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2942 </pre><p id="rfc.section.8.4.2.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.2 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).2941 </pre><p id="rfc.section.8.4.2.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.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 2943 2942 </p> 2944 2943 <div class="note" id="rfc.section.8.4.2.p.7"> … … 3075 3074 </p> 3076 3075 <ul class="empty"> 3077 <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 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.3076 <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.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 3078 3077 </li> 3079 3078 </ul> … … 3081 3080 </p> 3082 3081 <ul class="empty"> 3083 <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 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.3082 <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.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 3084 3083 </li> 3085 3084 </ul> … … 3087 3086 </p> 3088 3087 <ul class="empty"> 3089 <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 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.3088 <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.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 3090 3089 </li> 3091 3090 </ul> … … 3178 3177 specific to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3179 3178 </p> 3180 <p id="rfc.section.10.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. 30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing3179 <p id="rfc.section.10.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.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing 3181 3180 algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods 3182 3181 can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain … … 3522 3521 <h3 id="rfc.section.10.3.1"><a href="#rfc.section.10.3.1">10.3.1</a> <a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> 3523 3522 <p id="rfc.section.10.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, 3524 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.3 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.3523 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.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3525 3524 </p> 3526 3525 <p id="rfc.section.10.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 3527 3526 with "X-" if they are to be registered (either immediately or in the future). 3528 3527 </p> 3529 <p id="rfc.section.10.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.3 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3528 <p id="rfc.section.10.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.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 3530 3529 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>. 3531 3530 </p> 3532 3531 <p id="rfc.section.10.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 3533 3532 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 3534 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.3 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3533 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.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3535 3534 </p> 3536 3535 <p id="rfc.section.10.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 … … 3550 3549 <ul> 3551 3550 <li> 3552 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3551 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3553 3552 </p> 3554 3553 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 3566 3565 </li> 3567 3566 <li> 3568 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3567 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3569 3568 </p> 3570 3569 </li> … … 3577 3576 </li> 3578 3577 <li> 3579 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3578 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3580 3579 </p> 3581 3580 </li> … … 3743 3742 <p id="rfc.section.10.3.2.p.2">The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 3744 3743 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h2> 3745 <p id="rfc.section.10.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.3744 <p id="rfc.section.10.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 3746 3745 </p> 3747 3746 <h3 id="rfc.section.10.4.1"><a href="#rfc.section.10.4.1">10.4.1</a> <a id="content.coding.procedure" href="#content.coding.procedure">Procedure</a></h3> … … 3753 3752 <li>Pointer to specification text</li> 3754 3753 </ul> 3755 <p id="rfc.section.10.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.3 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3754 <p id="rfc.section.10.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3756 3755 </p> 3757 3756 <p id="rfc.section.10.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.3"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 3773 3772 <td class="left">compress</td> 3774 3773 <td class="left">UNIX "compress" program method</td> 3775 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1. 40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>3774 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> 3776 3775 </td> 3777 3776 </tr> … … 3780 3779 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 3781 3780 </td> 3782 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>3781 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> 3783 3782 </td> 3784 3783 </tr> … … 3786 3785 <td class="left">gzip</td> 3787 3786 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 3788 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>3787 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> 3789 3788 </td> 3790 3789 </tr> … … 3878 3877 </p> 3879 3878 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 3880 <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.3879 <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 3881 3880 </p> 3882 3881 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References … … 4189 4188 </p> 4190 4189 <p id="rfc.section.C.p.16">In the description of the "<a href="#header.server" class="smpl">Server</a>" header field, the "<a href="p1-messaging.html#header.via" class="smpl">Via</a>" field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field 4191 in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.4 4"><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 8.4.2</a>)4190 in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.43"><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 8.4.2</a>) 4192 4191 </p> 4193 4192 <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 9.3</a>) … … 4214 4213 (any visible US-ASCII character). 4215 4214 </p> 4216 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:4217 </p> 4218 <div id="rfc.figure.u.64"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 6"><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>>4219 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 7"><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>>4220 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 8"><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>>4221 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.4 9"><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>>4222 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <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>>4223 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 1"><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>>4224 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 2"><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>>4225 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 3"><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>>4226 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5 4"><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>>4227 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5 5"><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>>4228 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.5 6"><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>>4215 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>: 4216 </p> 4217 <div id="rfc.figure.u.64"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, 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>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 4218 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, 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>> 4219 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, 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>> 4220 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4221 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, 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>> 4222 <a href="#imported.abnf" class="smpl">comment</a> = <comment, 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#field.components" title="Field value components">Section 3.2.4</a>> 4223 <a href="#imported.abnf" class="smpl">field-name</a> = <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#header.fields" title="Header Fields">Section 3.2</a>> 4224 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4225 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, 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#field.components" title="Field value components">Section 3.2.4</a>> 4226 <a href="#imported.abnf" class="smpl">token</a> = <token, 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>> 4227 <a href="#imported.abnf" class="smpl">word</a> = <word, 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>> 4229 4228 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4230 4229 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 5148 5147 </li> 5149 5148 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5150 <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 </a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2.4</a>, <a href="#rfc.xref.Part1.10">4.1</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.12">5.3.6</a>, <a href="#rfc.xref.Part1.13">5.3.7</a>, <a href="#rfc.xref.Part1.14">5.3.8</a>, <a href="#rfc.xref.Part1.15">5.3.8</a>, <a href="#rfc.xref.Part1.16">6.1</a>, <a href="#rfc.xref.Part1.17">6.5</a>, <a href="#rfc.xref.Part1.18">6.5.3</a>, <a href="#rfc.xref.Part1.19">7.2.2</a>, <a href="#rfc.xref.Part1.20">7.3.4</a>, <a href="#rfc.xref.Part1.21">7.3.6</a>, <a href="#rfc.xref.Part1.22">7.5.15</a>, <a href="#rfc.xref.Part1.23">7.6.6</a>, <a href="#rfc.xref.Part1.24">8</a>, <a href="#rfc.xref.Part1.25">8.4.2</a>, <a href="#rfc.xref.Part1.26">8.4.2</a>, <a href="#rfc.xref.Part1.27">9.4</a>, <a href="#rfc.xref.Part1.28">9.4</a>, <a href="#rfc.xref.Part1.29">9.4</a>, <a href="#rfc.xref.Part1.30">10.1.2</a>, <a href="#rfc.xref.Part1.31">10.3.1</a>, <a href="#rfc.xref.Part1.32">10.3.1</a>, <a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.34">10.3.1</a>, <a href="#rfc.xref.Part1.35">10.3.1</a>, <a href="#rfc.xref.Part1.36">10.3.1</a>, <a href="#rfc.xref.Part1.37">10.4</a>, <a href="#rfc.xref.Part1.38">10.4.1</a>, <a href="#rfc.xref.Part1.39">10.4.1</a>, <a href="#rfc.xref.Part1.40">10.4.2</a>, <a href="#rfc.xref.Part1.41">10.4.2</a>, <a href="#rfc.xref.Part1.42">10.4.2</a>, <a href="#rfc.xref.Part1.43">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.44">C</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</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><ul>5149 <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.1</a>, <a href="#rfc.xref.Part1.8">3.2.4</a>, <a href="#rfc.xref.Part1.9">4.1</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">5.3.6</a>, <a href="#rfc.xref.Part1.12">5.3.7</a>, <a href="#rfc.xref.Part1.13">5.3.8</a>, <a href="#rfc.xref.Part1.14">5.3.8</a>, <a href="#rfc.xref.Part1.15">6.1</a>, <a href="#rfc.xref.Part1.16">6.5</a>, <a href="#rfc.xref.Part1.17">6.5.3</a>, <a href="#rfc.xref.Part1.18">7.2.2</a>, <a href="#rfc.xref.Part1.19">7.3.4</a>, <a href="#rfc.xref.Part1.20">7.3.6</a>, <a href="#rfc.xref.Part1.21">7.5.15</a>, <a href="#rfc.xref.Part1.22">7.6.6</a>, <a href="#rfc.xref.Part1.23">8</a>, <a href="#rfc.xref.Part1.24">8.4.2</a>, <a href="#rfc.xref.Part1.25">8.4.2</a>, <a href="#rfc.xref.Part1.26">9.4</a>, <a href="#rfc.xref.Part1.27">9.4</a>, <a href="#rfc.xref.Part1.28">9.4</a>, <a href="#rfc.xref.Part1.29">10.1.2</a>, <a href="#rfc.xref.Part1.30">10.3.1</a>, <a href="#rfc.xref.Part1.31">10.3.1</a>, <a href="#rfc.xref.Part1.32">10.3.1</a>, <a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.34">10.3.1</a>, <a href="#rfc.xref.Part1.35">10.3.1</a>, <a href="#rfc.xref.Part1.36">10.4</a>, <a href="#rfc.xref.Part1.37">10.4.1</a>, <a href="#rfc.xref.Part1.38">10.4.1</a>, <a href="#rfc.xref.Part1.39">10.4.2</a>, <a href="#rfc.xref.Part1.40">10.4.2</a>, <a href="#rfc.xref.Part1.41">10.4.2</a>, <a href="#rfc.xref.Part1.42">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</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><ul> 5151 5150 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 5152 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1. 20">7.3.4</a></li>5151 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.19">7.3.4</a></li> 5153 5152 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 5154 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.2 3">7.6.6</a></li>5155 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.4 9">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a></li>5156 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.1 8">6.5.3</a>, <a href="#rfc.xref.Part1.25">8.4.2</a>, <a href="#rfc.xref.Part1.31">10.3.1</a>, <a href="#rfc.xref.Part1.34">10.3.1</a>, <a href="#rfc.xref.Part1.52">D</a></li>5157 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.4 6">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>5158 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.3 3">10.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>5159 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1. 7">3</a>, <a href="#rfc.xref.Part1.11">4.2</a>, <a href="#rfc.xref.Part1.21">7.3.6</a>, <a href="#rfc.xref.Part1.30">10.1.2</a></li>5160 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1. 10">4.1</a></li>5161 <li><em>Section 4</em> <a href="#rfc.xref.Part1.3 8">10.4.1</a></li>5162 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.3 6">10.3.1</a></li>5163 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.2 7">9.4</a>, <a href="#rfc.xref.Part1.40">10.4.2</a></li>5164 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.3 7">10.4</a>, <a href="#rfc.xref.Part1.39">10.4.1</a></li>5165 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.2 8">9.4</a>, <a href="#rfc.xref.Part1.41">10.4.2</a></li>5166 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.2 9">9.4</a>, <a href="#rfc.xref.Part1.42">10.4.2</a></li>5167 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 7">6.5</a></li>5168 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.1 2">5.3.6</a>, <a href="#rfc.xref.Part1.13">5.3.7</a></li>5169 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.1 6">6.1</a></li>5170 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1. 8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2.4</a>, <a href="#rfc.xref.Part1.24">8</a></li>5171 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.1 4">5.3.8</a>, <a href="#rfc.xref.Part1.26">8.4.2</a>, <a href="#rfc.xref.Part1.44">C</a></li>5172 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.3 5">10.3.1</a></li>5173 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.1 9">7.2.2</a>, <a href="#rfc.xref.Part1.22">7.5.15</a></li>5174 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.1 5">5.3.8</a></li>5175 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 3">12</a></li>5176 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.3 2">10.3.1</a></li>5153 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.22">7.6.6</a></li> 5154 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.52">D</a></li> 5155 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.17">6.5.3</a>, <a href="#rfc.xref.Part1.24">8.4.2</a>, <a href="#rfc.xref.Part1.30">10.3.1</a>, <a href="#rfc.xref.Part1.33">10.3.1</a>, <a href="#rfc.xref.Part1.51">D</a></li> 5156 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a></li> 5157 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.32">10.3.1</a>, <a href="#rfc.xref.Part1.50">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></li> 5158 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.20">7.3.6</a>, <a href="#rfc.xref.Part1.29">10.1.2</a></li> 5159 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.9">4.1</a></li> 5160 <li><em>Section 4</em> <a href="#rfc.xref.Part1.37">10.4.1</a></li> 5161 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.35">10.3.1</a></li> 5162 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.26">9.4</a>, <a href="#rfc.xref.Part1.39">10.4.2</a></li> 5163 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.36">10.4</a>, <a href="#rfc.xref.Part1.38">10.4.1</a></li> 5164 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.27">9.4</a>, <a href="#rfc.xref.Part1.40">10.4.2</a></li> 5165 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.28">9.4</a>, <a href="#rfc.xref.Part1.41">10.4.2</a></li> 5166 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.16">6.5</a></li> 5167 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.11">5.3.6</a>, <a href="#rfc.xref.Part1.12">5.3.7</a></li> 5168 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.15">6.1</a></li> 5169 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1</a>, <a href="#rfc.xref.Part1.8">3.2.4</a>, <a href="#rfc.xref.Part1.23">8</a></li> 5170 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.13">5.3.8</a>, <a href="#rfc.xref.Part1.25">8.4.2</a>, <a href="#rfc.xref.Part1.43">C</a></li> 5171 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.34">10.3.1</a></li> 5172 <li><em>Section 6.3</em> <a href="#rfc.xref.Part1.18">7.2.2</a>, <a href="#rfc.xref.Part1.21">7.5.15</a></li> 5173 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.14">5.3.8</a></li> 5174 <li><em>Section 9</em> <a href="#rfc.xref.Part1.42">12</a></li> 5175 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.31">10.3.1</a></li> 5177 5176 </ul> 5178 5177 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1898 r1900 316 316 if the request is successfully applied, whereas a representation in the 317 317 payload of a POST request (<xref target="POST"/>) represents an anonymous 318 resource for providing data to be processed, such as a specific encoding319 format for the information thata user entered within an HTML form.318 resource for providing data to be processed, such as the information that 319 a user entered within an HTML form. 320 320 </t> 321 321 <t> … … 323 323 (<xref target="GET"/>) contains a representation of the target resource, 324 324 as observed at the time of the message origination date 325 (<xref target="header.date"/>), whereas the same response to POST might 326 contain either a representation of the processing result or a current 327 representation of the target resource after applying the processing. 328 Response messages with an error status code usually contain a 329 representation that describes the error and what next steps are suggested 325 (<xref target="header.date"/>), whereas the same status code in a response 326 to POST might contain either a representation of the processing result or 327 a current representation of the target resource after applying the 328 processing. Some responses only contain the representation's header fields 329 as the payload. Response messages with an error status code usually contain 330 a representation that describes the error and what next steps are suggested 330 331 for resolving it. 331 </t>332 <t>333 A representation body is only present in a message when a message body is334 present, as described in &message-body;. The representation body is obtained335 from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that336 might have been applied to ensure safe and proper transfer of the message.337 332 </t> 338 333
Note: See TracChangeset
for help on using the changeset viewer.