Ignore:
Timestamp:
Jul 5, 2012, 10:06:19 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status code range definitions

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1725 r1727  
    12821282      </p>
    12831283      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="field.length" href="#field.length">Field Length</a></h3>
    1284       <p id="rfc.section.3.2.3.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a 4xx status code if the received header
    1285          field(s) would be longer than the server wishes to handle.
     1284      <p id="rfc.section.3.2.3.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a <a href="p2-semantics.html#status.4xx" class="smpl">4xx
     1285            (Client Error)</a> status code if the received header field(s) would be longer than the server wishes to handle.
    12861286      </p>
    12871287      <p id="rfc.section.3.2.3.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p>
     
    13761376      <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    13771377         status code (<a href="#status-code">Paragraph&nbsp;3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
    1378          Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    1379          Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304
     1378         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304
    13801379            (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
    13811380      </p>
     
    14531452         </li>
    14541453         <li>
    1455             <p>Any successful (2xx) response to a CONNECT request implies that the connection will become a tunnel immediately after the
    1456                empty line that concludes the header fields. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in such a message.
     1454            <p>Any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request implies that the connection will become a tunnel immediately after the empty line that concludes
     1455               the header fields. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in such a message.
    14571456            </p>
    14581457         </li>
     
    19771976         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
    19781977      </p>
    1979       <p id="rfc.section.5.7.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.
     1978      <p id="rfc.section.5.7.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-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    19801979      </p>
    19811980      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="connection.management" href="#connection.management">Connection Management</a></h1>
     
    20212020      <p id="rfc.section.6.1.p.12">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
    20222021      </p>
    2023       <p id="rfc.section.6.1.p.13">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
     2022      <p id="rfc.section.6.1.p.13">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code.
    20242023      </p>
    20252024      <div id="rfc.iref.v.1"></div>
     
    22142213         </li>
    22152214         <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect header field
    2216             with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2215            with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22172216         </li>
    22182217      </ul>
     
    22512250      </p>
    22522251      <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2253          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2252         is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22542253      </p>
    22552254      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
Note: See TracChangeset for help on using the changeset viewer.