Changeset 2257 for draft-ietf-httpbis


Ignore:
Timestamp:
19/05/13 19:13:12 (7 years ago)
Author:
fielding@…
Message:

(editorial) #441: clarify handling of whitspace in request-line; clarify how a server initiates a close and remove the Apache-ism of "lingering close" that might be confused with SO_LINGER; fix the pseudo-code example explaining chunk parsing

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

Legend:

Unmodified
Added
Removed

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

    r2253 r2257  
    11661166      <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
    11671167      </p>
    1168       <p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line
    1169          into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section&nbsp;3.5</a>).
    1170       </p>
    1171       <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
    1172          directly instead of properly encoding or excluding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
     1168      <p id="rfc.section.3.1.1.p.7">Recipients typically parse the request-line into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section&nbsp;3.5</a>), since no whitespace is allowed in the three components. Unfortunately, some user agents fail to properly encode or exclude
     1169         whitespace found in hypertext references, resulting in those disallowed characters being sent in a request-target.
     1170      </p>
     1171      <p id="rfc.section.3.1.1.p.8">Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
    11731172         crafted to bypass security filters along the request chain.
    11741173      </p>
    … …  
    16201619      <p id="rfc.section.4.1.2.p.1">A process for decoding the chunked transfer coding can be represented in pseudo-code as:</p>
    16211620      <div id="rfc.figure.u.34"></div><pre class="text">  length := 0
    1622   read chunk-size, chunk-ext (if any) and CRLF
     1621  read chunk-size, chunk-ext (if any), and CRLF
    16231622  while (chunk-size &gt; 0) {
    16241623     read chunk-data and CRLF
    16251624     append chunk-data to decoded-body
    16261625     length := length + chunk-size
    1627      read chunk-size and CRLF
     1626     read chunk-size, chunk-ext (if any), and CRLF
    16281627  }
    16291628  read header-field
    … …  
    20882087      <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request.
    20892088      </p>
    2090       <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
    2091       </p>
    2092       <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
     2089      <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
     2090      </p>
     2091      <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a close of the connection (see below) after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.
    20932092      </p>
    20942093      <p id="rfc.section.6.6.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close;
    … …  
    21012100         can be read and interpreted by the client's HTTP parser.
    21022101      </p>
    2103       <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the
    2104          read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client
    2105          or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing
    2106          the server's last response. It is then safe for the server to fully close the connection.
     2102      <p id="rfc.section.6.6.p.7">To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by
     2103         closing only the write side of the read/write connection. The server then continues to read from the connection until it receives
     2104         a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's
     2105         acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection.
    21072106      </p>
    21082107      <p id="rfc.section.6.6.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p>

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

    r2253 r2257  
    10881088</t>
    10891089<t>
    1090    No whitespace is allowed inside the method, request-target, and
    1091    protocol version.  Hence, recipients typically parse the request-line
    1092    into its component parts by splitting on whitespace
    1093    (see <xref target="message.robustness"/>).
    1094 </t>
    1095 <t>
    1096    Unfortunately, some user agents fail to properly encode hypertext
    1097    references that have embedded whitespace, sending the characters directly
    1098    instead of properly encoding or excluding the disallowed characters.
     1090   Recipients typically parse the request-line into its component parts by
     1091   splitting on whitespace (see <xref target="message.robustness"/>), since
     1092   no whitespace is allowed in the three components.
     1093   Unfortunately, some user agents fail to properly encode or exclude
     1094   whitespace found in hypertext references, resulting in those disallowed
     1095   characters being sent in a request-target.
     1096</t>
     1097<t>
    10991098   Recipients of an invalid request-line &SHOULD; respond with either a
    11001099   <x:ref>400 (Bad Request)</x:ref> error or a <x:ref>301 (Moved Permanently)</x:ref>
    … …  
    20212020<figure><artwork type="code">
    20222021  length := 0
    2023   read chunk-size, chunk-ext (if any) and CRLF
     2022  read chunk-size, chunk-ext (if any), and CRLF
    20242023  while (chunk-size &gt; 0) {
    20252024     read chunk-data and CRLF
    20262025     append chunk-data to decoded-body
    20272026     length := length + chunk-size
    2028      read chunk-size and CRLF
     2027     read chunk-size, chunk-ext (if any), and CRLF
    20292028  }
    20302029  read header-field
    … …  
    30283027<t>
    30293028   A server that receives a <x:ref>close</x:ref> connection option &MUST;
    3030    initiate a lingering close (see below) of the connection after it sends the
     3029   initiate a close of the connection (see below) after it sends the
    30313030   final response to the request that contained <x:ref>close</x:ref>.
    30323031   The server &SHOULD; send a <x:ref>close</x:ref> connection option
    … …  
    30363035<t>
    30373036   A server that sends a <x:ref>close</x:ref> connection option &MUST;
    3038    initiate a lingering close of the connection after it sends the
     3037   initiate a close of the connection (see below) after it sends the
    30393038   response containing <x:ref>close</x:ref>. The server &MUST-NOT; process
    30403039   any further requests received on that connection.
    … …  
    30583057</t>
    30593058<t>
    3060    To avoid the TCP reset problem, a server can perform a lingering close on a
    3061    connection by closing only the write side of the read/write connection
    3062    (a half-close) and continuing to read from the connection until the
    3063    connection is closed by the client or the server is reasonably certain
    3064    that its own TCP stack has received the client's acknowledgement of the
    3065    packet(s) containing the server's last response. It is then safe for the
    3066    server to fully close the connection.
     3059   To avoid the TCP reset problem, servers typically close a connection in
     3060   stages. First, the server performs a half-close by closing only the write
     3061   side of the read/write connection. The server then continues to read from
     3062   the connection until it receives a corresponding close by the client, or
     3063   until the server is reasonably certain that its own TCP stack has received
     3064   the client's acknowledgement of the packet(s) containing the server's last
     3065   response. Finally, the server fully closes the connection.
    30673066</t>
    30683067<t>
Note: See TracChangeset for help on using the changeset viewer.