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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.