Ignore:
Timestamp:
11/10/11 07:20:37 (11 years ago)
Author:
julian.reschke@…
Message:

note the implications of not using the list syntax (see #231)

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

Legend:

Unmodified
Added
Removed

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

    r1445 r1446  
    959959         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    960960         that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
    961          a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
     961         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="ERROR: Anchor 'status.203' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.203' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    962962      </p>
    963963      <p id="rfc.section.2.4.p.7"><span id="rfc.iref.g.16"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
    … …  
    11081108      </p>
    11091109      <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1110          and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;4</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1110         and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;4</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="ERROR: Anchor 'status.code.and.reason.phrase' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.code.and.reason.phrase' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    11111111      </p>
    11121112      <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
    … …  
    11981198      <p id="rfc.section.3.1.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    11991199      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1200 </pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations
     1200</pre><p id="rfc.section.3.1.1.1.p.3">See <a href="p2-semantics.html#method" title="ERROR: Anchor 'method' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'method' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations
    12011201         for new methods.
    12021202      </p>
    … …  
    12101210                 / <a href="#uri" class="smpl">authority</a>
    12111211</pre><p id="rfc.section.3.1.1.2.p.3">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    1212          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1212         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="ERROR: Anchor 'status.414' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.414' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    12131213      </p>
    12141214      <p id="rfc.section.3.1.1.2.p.4">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.
    … …  
    12241224      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#status.line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    12251225</pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a>&nbsp;<a id="status.code" href="#status.code">Status Code</a></h4>
    1226       <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
     1226      <p id="rfc.section.3.1.2.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="ERROR: Anchor 'status.code.and.reason.phrase' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.code.and.reason.phrase' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
    12271227         for new status codes.
    12281228      </p>
    … …  
    12431243  <a href="#header.fields" class="smpl">field-content</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12441244</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,
    1245          the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1245         the Date header field is defined in <a href="p2-semantics.html#header.date" title="ERROR: Anchor 'header.date' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'header.date' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12461246      </p>
    12471247      <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
    … …  
    12511251         them.
    12521252      </p>
    1253       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1253      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="ERROR: Anchor 'considerations.for.creating.header.fields' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'considerations.for.creating.header.fields' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;8.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    12541254      </p>
    12551255      <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"
    … …  
    14761476      <p id="rfc.section.4.1.p.7">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    14771477      </p>
    1478       <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1478      <p id="rfc.section.4.1.p.8"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="ERROR: Anchor 'CONNECT' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'CONNECT' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    14791479      </p>
    14801480      <p id="rfc.section.4.1.p.9"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
    … …  
    17881788      <p id="rfc.section.6.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.
    17891789      </p>
    1790       <p id="rfc.section.6.1.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 6.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
     1790      <p id="rfc.section.6.1.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="ERROR: Anchor 'idempotent.methods' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'idempotent.methods' in Part2 not found in source file 'p2-semantics.xml'.</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
    17911791         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.
    17921792      </p>
    … …  
    18741874      </p>
    18751875      <p id="rfc.section.6.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
    1876          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.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 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
     1876         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="ERROR: Anchor 'idempotent.methods' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'idempotent.methods' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[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
    18771877         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.
    18781878      </p>
    … …  
    19011901      </p>
    19021902      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.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>
    1903       <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.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
     1903      <p id="rfc.section.6.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="ERROR: Anchor 'status.100' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.100' in Part2 not found in source file 'p2-semantics.xml'.</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
    19041904         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    19051905         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    19081908      <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    19091909      <ul>
    1910          <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 header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</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.
    1911          </li>
    1912          <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.3</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.
     1910         <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 header field (<a href="p2-semantics.html#header.expect" title="ERROR: Anchor 'header.expect' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'header.expect' in Part2 not found in source file 'p2-semantics.xml'.</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.
     1911         </li>
     1912         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="ERROR: Anchor 'header.expect' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'header.expect' in Part2 not found in source file 'p2-semantics.xml'.</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.
    19131913         </li>
    19141914      </ul>
    … …  
    19541954         <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
    19551955            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    1956             1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1956            1xx responses (see <a href="p2-semantics.html#status.1xx" title="ERROR: Anchor 'status.1xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.1xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    19571957         </li>
    19581958      </ul>
    … …  
    22392239      </p>
    22402240      <p id="rfc.section.8.7.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2241          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2241         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="ERROR: Anchor 'status.3xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.3xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    22422242      </p>
    22432243      <p id="rfc.section.8.7.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    … …  
    26602660         that most implementations will choose substantially higher limits.
    26612661      </p>
    2662       <p id="rfc.section.10.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 7.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2662      <p id="rfc.section.10.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="ERROR: Anchor 'status.414' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.414' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="ERROR: Anchor 'status.4xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.4xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    26632663      </p>
    26642664      <p id="rfc.section.10.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.
    … …  
    36813681                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li>
    36823682                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">4.1</a>, <a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a>, <a href="#rfc.xref.Part2.11">6.2.3</a>, <a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a>, <a href="#rfc.xref.Part2.15">8.7</a>, <a href="#rfc.xref.Part2.16">10.6</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul>
    3683                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
    3684                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3685                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
    3686                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a></li>
    3687                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">4.1</a></li>
    3688                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.2.3</a></li>
    3689                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a></li>
    3690                         <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li>
    3691                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">8.7</a></li>
    3692                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">10.6</a></li>
    3693                         <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.16">10.6</a></li>
    3694                         <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    3695                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a></li>
     3683                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li>
     3684                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2.1</a></li>
     3685                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1.1</a></li>
     3686                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1.2</a>, <a href="#rfc.xref.Part2.16">10.6</a></li>
     3687                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
     3688                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
     3689                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">4.1</a></li>
     3690                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">6.1.2.2</a>, <a href="#rfc.xref.Part2.10">6.1.4</a></li>
     3691                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">6.2.3</a></li>
     3692                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a></li>
     3693                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.2.3</a></li>
     3694                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">8.7</a></li>
     3695                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">10.6</a></li>
    36963696                     </ul>
    36973697                  </li>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1444 r1446  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 12, 2012";
     361       content: "Expires April 13, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-10-10">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-10-11">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: April 12, 2012</td>
     442               <td class="left">Expires: April 13, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">October 10, 2011</td>
     495               <td class="right">October 11, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on April 12, 2012.</p>
     525      <p>This Internet-Draft will expire on April 13, 2012.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    869869</pre><p id="rfc.section.3.1.p.7">Authors of specifications defining new header fields are advised to consider documenting: </p>
    870870      <ul>
    871          <li>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    872          </li>
    873          <li>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses
    874             to a particular request method.
    875          </li>
    876          <li>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    877          </li>
    878          <li>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</li>
    879          <li>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    880          </li>
    881          <li>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    882          </li>
    883          <li>Whether the header field should be preserved across redirects.</li>
     871         <li>
     872            <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     873            </p>
     874            <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default
     875               would be to ignore the header field, but this might not always be the right choice).
     876            </p>
     877         </li>
     878         <li>
     879            <p>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses
     880               to a particular request method.
     881            </p>
     882         </li>
     883         <li>
     884            <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     885            </p>
     886         </li>
     887         <li>
     888            <p>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</p>
     889         </li>
     890         <li>
     891            <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     892            </p>
     893         </li>
     894         <li>
     895            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     896            </p>
     897         </li>
     898         <li>
     899            <p>Whether the header field should be preserved across redirects.</p>
     900         </li>
    884901      </ul>
    885902      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1444 r1446  
    525525   documenting:
    526526  <list style="symbols">
    527     <t>Whether the field is a single value, or whether it can be a list
    528     (delimited by commas; see &header-fields;).</t>
    529     <t>Under what conditions the header field can be used; e.g., only in
     527    <x:lt>
     528      <t>Whether the field is a single value, or whether it can be a list
     529      (delimited by commas; see &header-fields;).</t>
     530      <t>If it does not use the list syntax, how to treat messages where the
     531      header field occurs multiple times (a sensible default would be to ignore
     532      the header field, but this might not always be the right choice).</t>
     533    </x:lt>
     534    <x:lt><t>Under what conditions the header field can be used; e.g., only in
    530535    responses or requests, in all messages, only on responses to a particular
    531     request method.</t>
    532     <t>Whether it is appropriate to list the field-name in the Connection header
    533     (i.e., if the header is to be hop-by-hop, see &header-connection;).</t>
    534     <t>Under what conditions intermediaries are allowed to modify the header
    535     field's value, insert or delete it.</t>
    536     <t>How the header might interact with caching (see <xref target="Part6"/>).</t>
    537     <t>Whether the header field is useful or allowable in trailers (see
    538     &chunked-encoding;).</t>
    539     <t>Whether the header field should be preserved across redirects.</t>
     536    request method.</t></x:lt>
     537    <x:lt><t>Whether it is appropriate to list the field-name in the Connection header
     538    (i.e., if the header is to be hop-by-hop, see &header-connection;).</t></x:lt>
     539    <x:lt><t>Under what conditions intermediaries are allowed to modify the header
     540    field's value, insert or delete it.</t></x:lt>
     541    <x:lt><t>How the header might interact with caching (see <xref target="Part6"/>).</t></x:lt>
     542    <x:lt><t>Whether the header field is useful or allowable in trailers (see
     543    &chunked-encoding;).</t></x:lt>
     544    <x:lt><t>Whether the header field should be preserved across redirects.</t></x:lt>
    540545  </list>
    541546</t>
Note: See TracChangeset for help on using the changeset viewer.