Changeset 1446 for draft-ietf-httpbis/latest
- Timestamp:
- 11/10/11 07:20:37 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1445 r1446 959 959 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 960 960 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. 962 962 </p> 963 963 <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 … … 1108 1108 </p> 1109 1109 <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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 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. 1111 1111 </p> 1112 1112 <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 … … 1198 1198 <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> 1199 1199 <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 considerations1200 </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 1201 1201 for new methods. 1202 1202 </p> … … 1210 1210 / <a href="#uri" class="smpl">authority</a> 1211 1211 </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>). 1213 1213 </p> 1214 1214 <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. … … 1224 1224 <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> 1225 1225 </pre><h4 id="rfc.section.3.1.2.1"><a href="#rfc.section.3.1.2.1">3.1.2.1</a> <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 considerations1226 <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 1227 1227 for new status codes. 1228 1228 </p> … … 1243 1243 <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> ) 1244 1244 </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. 1246 1246 </p> 1247 1247 <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 … … 1251 1251 them. 1252 1252 </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 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 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. 1254 1254 </p> 1255 1255 <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" … … 1476 1476 <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. 1477 1477 </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>). 1479 1479 </p> 1480 1480 <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, … … 1788 1788 <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. 1789 1789 </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 to1790 <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 1791 1791 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. 1792 1792 </p> … … 1874 1874 </p> 1875 1875 <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 understanding1876 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 1877 1877 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. 1878 1878 </p> … … 1901 1901 </p> 1902 1902 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <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 willing1903 <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 1904 1904 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 1905 1905 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 1908 1908 <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1909 1909 <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="E xpect">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="E xpect">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. 1913 1913 </li> 1914 1914 </ul> … … 1954 1954 <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 1955 1955 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>). 1957 1957 </li> 1958 1958 </ul> … … 2239 2239 </p> 2240 2240 <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>). 2242 2242 </p> 2243 2243 <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 … … 2660 2660 that most implementations will choose substantially higher limits. 2661 2661 </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>). 2663 2663 </p> 2664 2664 <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. … … 3681 3681 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3682 3682 <li><em>Part2</em> <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> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li>3684 <li><em> Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li>3685 <li><em> Section 4</em> <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> <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> <a href="#rfc.xref.Part2.8">4.1</a></li>3688 <li><em> Section 7.1.1</em> <a href="#rfc.xref.Part2.11">6.2.3</a></li>3689 <li><em> Section 7.1</em> <a href="#rfc.xref.Part2.14">6.2.3</a></li>3690 <li><em> Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.4</a></li>3691 <li><em> Section 7.3</em> <a href="#rfc.xref.Part2.15">8.7</a></li>3692 <li><em> Section 7.4</em> <a href="#rfc.xref.Part2.17">10.6</a></li>3693 <li><em> Section 7.4.15</em> <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> <a href="#rfc.xref.Part2.6">3.2</a></li>3695 <li><em> Section 9.3</em> <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> <a href="#rfc.xref.Part2.1">2.4</a></li> 3684 <li><em>Appendix </em> <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> <a href="#rfc.xref.Part2.3">3.1.1.1</a></li> 3686 <li><em>Appendix </em> <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> <a href="#rfc.xref.Part2.6">3.2</a></li> 3688 <li><em>Appendix </em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3689 <li><em>Appendix </em> <a href="#rfc.xref.Part2.8">4.1</a></li> 3690 <li><em>Appendix </em> <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> <a href="#rfc.xref.Part2.11">6.2.3</a></li> 3692 <li><em>Appendix </em> <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> <a href="#rfc.xref.Part2.14">6.2.3</a></li> 3694 <li><em>Appendix </em> <a href="#rfc.xref.Part2.15">8.7</a></li> 3695 <li><em>Appendix </em> <a href="#rfc.xref.Part2.17">10.6</a></li> 3696 3696 </ul> 3697 3697 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r1444 r1446 359 359 } 360 360 @bottom-center { 361 content: "Expires April 1 2, 2012";361 content: "Expires April 13, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-1 0">411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-11"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <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 "HTTP/1.1" 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."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: April 1 2, 2012</td>442 <td class="left">Expires: April 13, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">October 1 0, 2011</td>495 <td class="right">October 11, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on April 1 2, 2012.</p>525 <p>This Internet-Draft will expire on April 13, 2012.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 869 869 </pre><p id="rfc.section.3.1.p.7">Authors of specifications defining new header fields are advised to consider documenting: </p> 870 870 <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> 884 901 </ul> 885 902 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1444 r1446 525 525 documenting: 526 526 <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 530 535 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 header533 (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 header535 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 (see538 &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> 540 545 </list> 541 546 </t>
Note: See TracChangeset
for help on using the changeset viewer.