Ignore:
Timestamp:
08/07/12 18:15:03 (9 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1737 r1740  
    961961      <p id="rfc.section.2.5.p.4">Unless noted otherwise, recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    962962         except when they have a direct impact on security, since different applications of the protocol require different error handling
    963          strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field
    964          doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.
     963         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
     964         to be dangerous.
    965965      </p>
    966966      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
    … …  
    10011001      </p>
    10021002      <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
    1003          the client has attempted at least one normal request and determined from the response status or header fields (e.g., Server)
    1004          that the server improperly handles higher request versions.
     1003         the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    10051004      </p>
    10061005      <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
    … …  
    10111010         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    10121011         number correctly or when an intermediary is known to blindly forward the HTTP-version even when it doesn't conform to the
    1013          given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g.,
    1014          User-Agent) uniquely match the values sent by a client known to be in error.
     1012         given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g., <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a>) uniquely match the values sent by a client known to be in error.
    10151013      </p>
    10161014      <p id="rfc.section.2.6.p.13">The intention of HTTP's versioning design is that the major number will only be incremented if an incompatible message syntax
    … …  
    12091207                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12101208</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,
    1211          the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1209         the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12121210      </p>
    12131211      <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
    … …  
    12201218      </p>
    12211219      <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"
    1222          to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations
    1223          can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include
     1220         to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include
    12241221         conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
    12251222      </p>
    … …  
    14021399      <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    14031400      </p>
    1404       <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1401      <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    14051402      </p>
    14061403      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
    … …  
    19501947         </li>
    19511948      </ul>
    1952       <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
     1949      <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field value identical to that of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field in that response.
    19531950      </p>
    19541951      <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
    19551952      </p>
    19561953      <ul>
    1957          <li>Content-Encoding</li>
    1958          <li>Content-Range</li>
    1959          <li>Content-Type</li>
     1954         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
     1955         </li>
     1956         <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
     1957         </li>
     1958         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</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>)
     1959         </li>
    19601960      </ul>
    19611961      <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    … …  
    19661966         </p>
    19671967      </div>
    1968       <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1968      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    19691969      </p>
    19701970      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    19711971      <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19721972         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1973          on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, 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.
     1973         on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
    19741974      </p>
    19751975      <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.
    … …  
    20422042      <p id="rfc.section.6.2.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
    20432043      </p>
    2044       <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the User-Agent and Server header
    2045          fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
     2044      <p id="rfc.section.6.2.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of each recipient, analogous to the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> and <a href="p2-semantics.html#header.server" class="smpl">Server</a> header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.
    20462045      </p>
    20472046      <p id="rfc.section.6.2.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses
    … …  
    21192118      <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    21202119      </p>
    2121       <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2120      <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    21222121         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    21232122      </p>
    … …  
    21492148      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    21502149      <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2151          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     2150         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    21522151         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    21532152      </p>
    … …  
    21622161      </p>
    21632162      <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2164       <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2163      <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    21652164         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21662165         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    21692168      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21702169      <ul>
    2171          <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.
    2172          </li>
    2173          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     2170         <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</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>) with the "100-continue" expectation.
     2171         </li>
     2172         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
    21742173         </li>
    21752174      </ul>
    … …  
    21802179      <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    21812180      <ul>
    2182          <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    2183          </li>
    2184          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an Expect header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
     2181         <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
     2182         </li>
     2183         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
    21852184            with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
    21862185            expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
    … …  
    21922191            prematurely.
    21932192         </li>
    2194          <li>If an origin server receives a request that does not include an Expect header field with the "100-continue" expectation, the
    2195             request includes a request body, and the server responds with a final status code before reading the entire request body from
    2196             the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
     2193         <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final
     2194            status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    21972195            the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
    21982196            a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
    … …  
    22012199      <p id="rfc.section.6.4.3.p.5">Requirements for HTTP/1.1 proxies: </p>
    22022200      <ul>
    2203          <li>If a proxy receives a request that includes an Expect header field with the "100-continue" expectation, and the proxy either
    2204             knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server,
    2205             it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
     2201         <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1
     2202            or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
    22062203         </li>
    22072204         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code.
    … …  
    22092206         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
    22102207         </li>
    2211          <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
    2212             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>).
     2208         <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 <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field 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.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22132209         </li>
    22142210      </ul>
    … …  
    22472243      </p>
    22482244      <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
    2249          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>).
     2245         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.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22502246      </p>
    22512247      <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
    … …  
    25112507         <li>Pointer to specification text</li>
    25122508      </ul>
    2513       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2509      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    25142510      </p>
    25152511      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
    … …  
    26712667         that most implementations will choose substantially higher limits.
    26722668      </p>
    2673       <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2669      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    26742670      </p>
    26752671      <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
    … …  
    27162712      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    27172713      </h2>
    2718       <table>                     
     2714      <table>                       
    27192715         <tr>
    27202716            <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
    … …  
    27292725            <td class="reference"><b id="Part4">[Part4]</b></td>
    27302726            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), July&nbsp;2012.
     2727            </td>
     2728         </tr>
     2729         <tr>
     2730            <td class="reference"><b id="Part5">[Part5]</b></td>
     2731            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), July&nbsp;2012.
    27312732            </td>
    27322733         </tr>
    … …  
    37333734            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    37343735                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
    3735                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">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</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</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">3.3</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.17">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a>, <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3736                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">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</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</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">3.3</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.4.3</a>, <a href="#rfc.xref.Part2.24">6.5</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    37363737                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
    3737                         <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a></li>
     3738                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a></li>
    37383739                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    37393740                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    37403741                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    37413742                        <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</a>, <a href="#rfc.xref.Part2.9">3.3</a></li>
    3742                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li>
    3743                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a></li>
     3743                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.23">6.4.3</a></li>
     3744                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">6.4.3</a></li>
    37443745                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
    3745                         <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.5</a></li>
    3746                         <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">8.6</a></li>
    3747                         <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.25">8.6</a></li>
    3748                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.24">7.4</a></li>
     3746                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.5</a></li>
     3747                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">8.6</a></li>
     3748                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.26">8.6</a></li>
     3749                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li>
    37493750                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3.1</a></li>
     3751                        <li><em>Section 9.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">5.6.2</a></li>
     3752                        <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.6.2</a></li>
    37503753                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3751                         <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>
     3754                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.4.3</a></li>
    37523755                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
    37533756                     </ul>
    … …  
    37553758                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
    37563759                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
     3760                     </ul>
     3761                  </li>
     3762                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">5.6.2</a>, <a href="#Part5"><b>10.1</b></a><ul>
     3763                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">5.6.2</a></li>
    37573764                     </ul>
    37583765                  </li>
Note: See TracChangeset for help on using the changeset viewer.