Ignore:
Timestamp:
Feb 17, 2012, 10:49:12 PM (8 years ago)
Author:
fielding@…
Message:

Revert [1471] and move the 1xx note to a normaltive section on associating
one or more responses to the corresponding request(s). Requirements do not
belong in the intro and the text provided was not sufficient to answer #300.

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1535 r1537  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 16, 2012";
     462       content: "Expires August 20, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    510510      <meta name="dct.creator" content="Reschke, J. F.">
    511511      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    512       <meta name="dct.issued" scheme="ISO8601" content="2012-02-13">
     512      <meta name="dct.issued" scheme="ISO8601" content="2012-02-17">
    513513      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    542542            </tr>
    543543            <tr>
    544                <td class="left">Expires: August 16, 2012</td>
     544               <td class="left">Expires: August 20, 2012</td>
    545545               <td class="right">HP</td>
    546546            </tr>
    … …  
    595595            <tr>
    596596               <td class="left"></td>
    597                <td class="right">February 13, 2012</td>
     597               <td class="right">February 17, 2012</td>
    598598            </tr>
    599599         </tbody>
    … …  
    628628         in progress”.
    629629      </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>
    631631      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    632632      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    697697               <li>4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
    698698               <li>4.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
     699               <li>4.4&nbsp;&nbsp;&nbsp;<a href="#associating.request.response">Associating Response to Request</a></li>
    699700            </ul>
    700701         </li>
    … …  
    919920      <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&nbsp;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&nbsp;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&nbsp;3.3</a>).
    920921      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>
    928926      <div id="rfc.figure.u.2"></div>
    929927      <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
    … …  
    986984         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    987985         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.
    989987      </p>
    990988      <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
    … …  
    11541152      </p>
    11551153      <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&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;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&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;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.
    11571155      </p>
    11581156      <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
    … …  
    12481246      <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>
    12491247      <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 considerations
     1248</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
    12511249         for new methods.
    12521250      </p>
    … …  
    12601258                 / <a href="#uri" class="smpl">authority</a>
    12611259</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>).
    12631261      </p>
    12641262      <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.
    … …  
    12741272      <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>
    12751273</pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a>&nbsp;<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 considerations
     1274      <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
    12771275         for new status codes.
    12781276      </p>
    … …  
    12931291  <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> )
    12941292</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.
    12961294      </p>
    12971295      <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
    … …  
    13011299         them.
    13021300      </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&nbsp;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&nbsp;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.
    13041302      </p>
    13051303      <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"
    … …  
    16071605      </p>
    16081606      <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,
    16101608         </p>
    16111609      </div>
    … …  
    16881686      </p>
    16891687      <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&nbsp;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>&nbsp;<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.
    16901696      </p>
    16911697      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    … …  
    38083814            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38093815                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    3810                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.1</a></li>
    3812                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3813                         <li><em>Section 4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
     3818                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
     3819                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
    38143820                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">4.1</a></li>
    3816                         <li><em>Section 7.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">4.1</a></li>
     3822                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">4.4</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li>
    38173823                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a></li>
    3818                         <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
     3824                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    38193825                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">8.7</a></li>
    38203826                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">10.6</a></li>
    3821                         <li><em>Section 7.4.12</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
     3827                        <li><em>Section 7.4.12</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    38233829                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li>
    38243830                     </ul>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1535 r1537  
    432432</t>
    433433<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
    436437   includes the protocol version, a success or error code, and textual
    437438   reason phrase (<xref target="status.line"/>),
    438    followed by MIME-like header fields containing server
     439   possibly followed by MIME-like header fields containing server
    439440   information, resource metadata, and payload metadata
    440441   (<xref target="header.fields"/>),
    … …  
    442443   a message body containing the payload body (if any,
    443444   <xref target="message.body"/>).
    444 </t>
    445 <t>
    446    Note that 1xx responses (&status-1xx;) are not final; therefore, a server
    447    can send zero or more 1xx responses, followed by exactly one final response
    448    (with any other status code).
    449445</t>
    450446<t>
    … …  
    20332029   be treated as equivalent to an absolute path of "/".
    20342030</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>
    20352050</section>
    20362051</section>
Note: See TracChangeset for help on using the changeset viewer.