Changeset 1537 for draft-ietf-httpbis/latest
- Timestamp:
- 18/02/12 06:49:12 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1535 r1537 460 460 } 461 461 @bottom-center { 462 content: "Expires August 16, 2012";462 content: "Expires August 20, 2012"; 463 463 } 464 464 @bottom-right { … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-1 3">512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-17"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: August 16, 2012</td>544 <td class="left">Expires: August 20, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">February 1 3, 2012</td>597 <td class="right">February 17, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on August 16, 2012.</p>630 <p>This Internet-Draft will expire on August 20, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 697 697 <li>4.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 698 698 <li>4.3 <a href="#effective.request.uri">Effective Request URI</a></li> 699 <li>4.4 <a href="#associating.request.response">Associating Response to Request</a></li> 699 700 </ul> 700 701 </li> … … 919 920 <p id="rfc.section.2.1.p.6">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request-Line">Section 3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 920 921 </p> 921 <p id="rfc.section.2.1.p.7">A server responds to the client's request by sending an HTTP <dfn>response</dfn> message, beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase 922 (<a href="#status.line" title="Response Status-Line">Section 3.1.2</a>), followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 923 </p> 924 <p id="rfc.section.2.1.p.8">Note that 1xx responses (<a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) are not final; therefore, a server can send zero or more 1xx responses, followed by exactly one final response (with any 925 other status code). 926 </p> 927 <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 922 <p id="rfc.section.2.1.p.7">A server responds to the client's request by sending one or more HTTP <dfn>response</dfn> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason 923 phrase (<a href="#status.line" title="Response Status-Line">Section 3.1.2</a>), possibly followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 924 </p> 925 <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 928 926 <div id="rfc.figure.u.2"></div> 929 927 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 986 984 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 987 985 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 988 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.986 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 989 987 </p> 990 988 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1154 1152 </p> 1155 1153 <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1156 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 4</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.1154 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 4</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1157 1155 </p> 1158 1156 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1248 1246 <p id="rfc.section.3.1.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1249 1247 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1250 </pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations1248 </pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations 1251 1249 for new methods. 1252 1250 </p> … … 1260 1258 / <a href="#uri" class="smpl">authority</a> 1261 1259 </pre><p id="rfc.section.3.1.1.2.p.3">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1262 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1260 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1263 1261 </p> 1264 1262 <p id="rfc.section.3.1.1.2.p.4">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets. … … 1274 1272 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status.line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1275 1273 </pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a> <a id="status.code" href="#status.code">Status Code</a></h4> 1276 <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations1274 <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1277 1275 for new status codes. 1278 1276 </p> … … 1293 1291 <a href="#header.fields" class="smpl">field-content</a> = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1294 1292 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1295 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1293 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1296 1294 </p> 1297 1295 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1301 1299 them. 1302 1300 </p> 1303 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1301 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1304 1302 </p> 1305 1303 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1607 1605 </p> 1608 1606 <div id="authority-form"> 1609 <p id="rfc.section.4.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example,1607 <p id="rfc.section.4.1.p.12"><span id="rfc.iref.a.3"></span> The "authority form" of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than CONNECT, is used to establish a tunnel through one or more proxies (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). For example, 1610 1608 </p> 1611 1609 </div> … … 1688 1686 </p> 1689 1687 <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 1688 </p> 1689 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="associating.request.response" href="#associating.request.response">Associating Response to Request</a></h2> 1690 <p id="rfc.section.4.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1691 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1692 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1693 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request. 1694 </p> 1695 <p id="rfc.section.4.4.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. 1690 1696 </p> 1691 1697 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> … … 3808 3814 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3809 3815 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3810 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2. 1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">4.1</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>3811 <li><em>Section 2</em> <a href="#rfc.xref.Part2. 4">3.1.1.1</a></li>3812 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2. 8">3.2</a></li>3813 <li><em>Section 4</em> <a href="#rfc.xref.Part2. 3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a></li>3816 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3817 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3818 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3819 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li> 3814 3820 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a></li> 3815 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2. 9">4.1</a></li>3816 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2. 1">2.1</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>3821 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.8">4.1</a></li> 3822 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li> 3817 3823 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.12">6.2.3</a></li> 3818 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2. 2">2.3</a></li>3824 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> 3819 3825 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.16">8.7</a></li> 3820 3826 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.18">10.6</a></li> 3821 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2. 5">3.1.1.2</a>, <a href="#rfc.xref.Part2.17">10.6</a></li>3822 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2. 7">3.2</a></li>3827 <li><em>Section 7.4.12</em> <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.17">10.6</a></li> 3828 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li> 3823 3829 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li> 3824 3830 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1535 r1537 432 432 </t> 433 433 <t> 434 A server responds to the client's request by sending an HTTP <x:dfn>response</x:dfn> 435 message, beginning with a status line that 434 A server responds to the client's request by sending one or more HTTP 435 <x:dfn>response</x:dfn> 436 messages, each beginning with a status line that 436 437 includes the protocol version, a success or error code, and textual 437 438 reason phrase (<xref target="status.line"/>), 438 followed by MIME-like header fields containing server439 possibly followed by MIME-like header fields containing server 439 440 information, resource metadata, and payload metadata 440 441 (<xref target="header.fields"/>), … … 442 443 a message body containing the payload body (if any, 443 444 <xref target="message.body"/>). 444 </t>445 <t>446 Note that 1xx responses (&status-1xx;) are not final; therefore, a server447 can send zero or more 1xx responses, followed by exactly one final response448 (with any other status code).449 445 </t> 450 446 <t> … … 2033 2029 be treated as equivalent to an absolute path of "/". 2034 2030 </t> 2031 </section> 2032 2033 <section title="Associating Response to Request" anchor="associating.request.response"> 2034 <t> 2035 HTTP does not include a request identifier for associating a given 2036 request message with its corresponding one or more response messages. 2037 Hence, it relies on the order of response arrival to correspond exactly 2038 to the order in which requests are made on the same connection. 2039 More than one response message per request only occurs when one or more 2040 informational responses (1xx, see &status-1xx;) precede a final response 2041 to the same request. 2042 </t> 2043 <t> 2044 A client that uses persistent connections and sends more than one request 2045 per connection &MUST; maintain a list of outstanding requests in the 2046 order sent on that connection and &MUST; associate each received response 2047 message to the highest ordered request that has not yet received a final 2048 (non-1xx) response. 2049 </t> 2035 2050 </section> 2036 2051 </section>
Note: See TracChangeset
for help on using the changeset viewer.