Ignore:
Timestamp:
Feb 6, 2008, 11:15:29 AM (12 years ago)
Author:
julian.reschke@…
Message:

Add sections that for now normatively reference the ABNF syntax and basic rules from Part1, also start work on referencing ABNF rules adopted from other parts (ongoing); relates to #36.

File:
1 edited

Legend:

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

    r204 r205  
    690690      <dl class="empty">
    691691         <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of
    692             entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 3</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     692            entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    693693         </dd>
    694694      </dl>
     
    696696      </p>
    697697      <dl class="empty">
    698          <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
     698         <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.
    699699         </dd>
    700700      </dl>
     
    702702      </p>
    703703      <dl class="empty">
    704          <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
     704         <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).
    705705         </dd>
    706706      </dl>
     
    949949                   ; US-ASCII double-quote mark (34)
    950950</pre><p id="rfc.section.2.2.p.3">HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;B</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described
    951          in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     951         in <a href="p3-payload.html#media.types" title="Media Types">Section 3.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    952952      </p>
    953953      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.12"></span>  CRLF           = CR LF
     
    10331033  relativeURI   = &lt;relativeURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.7"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-5">Section 5</a>&gt;
    10341034  uri-host      = &lt;host, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.8"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2.2">Section 3.2.2</a>&gt;
    1035 </pre><p id="rfc.section.3.2.1.p.3">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1035</pre><p id="rfc.section.3.2.1.p.3">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    10361036      </p>
    10371037      <p id="rfc.section.3.2.1.p.4"> </p>
     
    11291129      </p>
    11301130      <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry
    1131          contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    1132       </p>
    1133       <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1131         contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
     1132      </p>
     1133      <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    11341134      </p>
    11351135      <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     
    12261226      </p>
    12271227      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="message.headers" href="#message.headers">Message Headers</a></h2>
    1228       <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc2822#section-2.1">Section 2.1</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.3"><cite title="Internet Message Format">[RFC2822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
     1228      <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc2822#section-2.1">Section 2.1</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.3"><cite title="Internet Message Format">[RFC2822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
    12291229         field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding
    12301230         each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated,
     
    12641264      <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    12651265      <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    1266          in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<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>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
     1266         in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length
    12671267         and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented
    12681268         the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response.
     
    13241324         to the entity being transferred. These header fields apply only to the message being transmitted.
    13251325      </p>
    1326       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  general-header = Cache-Control            ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 15.2</a>
     1326      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.67"></span>  general-header = Cache-Control            ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>
    13271327                 | Connection               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
    13281328                 | Date                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
    1329                  | Pragma                   ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 15.4</a>
     1329                 | Pragma                   ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>
    13301330                 | Trailer                  ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a>
    13311331                 | Transfer-Encoding        ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
    13321332                 | Upgrade                  ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a>
    13331333                 | Via                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>
    1334                  | Warning                  ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 15.6</a>
     1334                 | Warning                  ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>
    13351335</pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    13361336         or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize
     
    13431343      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.68"></span>  Request       = Request-Line              ; <a href="#request-line" title="Request-Line">Section&nbsp;5.1</a>
    13441344                  *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1345                    | request-header         ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>
    1346                    | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1345                   | request-header         ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>
     1346                   | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
    13471347                  CRLF
    13481348                  [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
     
    13751375</pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
    13761376      </p>
    1377       <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1377      <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13781378      </p>
    13791379      <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
     
    14211421      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  Response      = Status-Line               ; <a href="#status-line" title="Status-Line">Section&nbsp;6.1</a>
    14221422                  *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1423                    | response-header        ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>
    1424                    | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1423                   | response-header        ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>
     1424                   | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>
    14251425                  CRLF
    14261426                  [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
     
    14331433</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    14341434      <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
    1435          are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
     1435         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
    14361436         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    14371437         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
     
    15031503      <p id="rfc.section.7.1.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.
    15041504      </p>
    1505       <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     1505      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    15061506         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request.
    15071507      </p>
     
    15281528      </p>
    15291529      <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    1530          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent 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
     1530         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent 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
    15311531         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.
    15321532      </p>
     
    15461546      </p>
    15471547      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    1548       <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[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
     1548      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[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
    15491549         to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    15501550         be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
     
    15531553      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    15541554      <ul>
    1555          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    1556          </li>
    1557          <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     1555         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     1556         </li>
     1557         <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    15581558         </li>
    15591559      </ul>
     
    15991599         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    16001600            an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
    1601             of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1601            of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    16021602         </li>
    16031603      </ul>
     
    17651765         <li>
    17661766            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    1767                is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 2.4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
     1767               is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")
    17681768            </p>
    17691769         </li>
     
    26982698                  <li class="indline1"><em>Pad1995</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li>
    26992699                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.2.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.3</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a>, <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a>, <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">
    2700                         <li class="indline1"><em>Section 2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.4">4.3</a></li>
    2701                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a></li>
    2702                         <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li>
    2703                         <li class="indline1"><em>Section 7.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>
    2704                         <li class="indline1"><em>Section 7.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>
    2705                         <li class="indline1"><em>Section 8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>
    2706                         <li class="indline1"><em>Section 8.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
    2707                         <li class="indline1"><em>Section 8.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>
    2708                         <li class="indline1"><em>Section 8.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.2.1</a></li>
    2709                         <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
     2700                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.4">4.3</a></li>
     2701                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a></li>
     2702                        <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li>
     2703                        <li class="indline1"><em>Section 8.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>
     2704                        <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>
     2705                        <li class="indline1"><em>Section 9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>
     2706                        <li class="indline1"><em>Section 9.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
     2707                        <li class="indline1"><em>Section 9.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>
     2708                        <li class="indline1"><em>Section 9.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.2.1</a></li>
     2709                        <li class="indline1"><em>Section 10.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
    27102710                     </ul>
    27112711                  </li>
    27122712                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.4</a>, <a class="iref" href="#rfc.xref.Part3.5">2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">B</a>, <a class="iref" href="#rfc.xref.Part3.13">D.3</a><ul class="ind">
    2713                         <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a></li>
    2714                         <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">2.2</a></li>
    2715                         <li class="indline1"><em>Section 2.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.5</a></li>
    2716                         <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.3</a></li>
    2717                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>
    2718                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a></li>
     2713                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a></li>
     2714                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">2.2</a></li>
     2715                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.5</a></li>
     2716                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.3</a></li>
     2717                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li>
     2718                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a></li>
    27192719                        <li class="indline1"><em>Section A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.4</a></li>
    27202720                     </ul>
     
    27232723                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a>, <a class="iref" href="#rfc.xref.Part6.3">4.5</a>, <a class="iref" href="#rfc.xref.Part6.4">4.5</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.6">D.3</a><ul class="ind">
    27242724                        <li class="indline1"><em>Section 1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a></li>
    2725                         <li class="indline1"><em>Section 15.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">4.5</a></li>
    2726                         <li class="indline1"><em>Section 15.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">4.5</a></li>
    2727                         <li class="indline1"><em>Section 15.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>
     2725                        <li class="indline1"><em>Section 16.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">4.5</a></li>
     2726                        <li class="indline1"><em>Section 16.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">4.5</a></li>
     2727                        <li class="indline1"><em>Section 16.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.5">4.5</a></li>
    27282728                     </ul>
    27292729                  </li>
Note: See TracChangeset for help on using the changeset viewer.