Changeset 1471
- Timestamp:
- 05/11/11 09:52:25 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1469 r1471 359 359 } 360 360 @bottom-center { 361 content: "Expires May 4, 2012";361 content: "Expires May 8, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-11-0 1">410 <meta name="dct.issued" scheme="ISO8601" content="2011-11-05"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: May 4, 2012</td>442 <td class="left">Expires: May 8, 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">November 1, 2011</td>495 <td class="right">November 5, 2011</td> 496 496 </tr> 497 497 </tbody> … … 526 526 in progress”. 527 527 </p> 528 <p>This Internet-Draft will expire on May 4, 2012.</p>528 <p>This Internet-Draft will expire on May 8, 2012.</p> 529 529 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 530 530 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 893 893 (<a href="#status.line" title="Response Status-Line">Section 3.1.2</a>), followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 894 894 </p> 895 <p id="rfc.section.2.1.p.7">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 895 <p id="rfc.section.2.1.p.7">Note that 1xx responses (<a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) are not final; therefore, a server can send zero or more 1xx responses, followed by exactly one final response (with any 896 other status code). 897 </p> 898 <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 896 899 <div id="rfc.figure.u.10"></div> 897 900 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 968 971 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 969 972 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 970 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.973 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.2"><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. 971 974 </p> 972 975 <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 … … 1117 1120 </p> 1118 1121 <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, 1119 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.1122 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.3"><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. 1120 1123 </p> 1121 1124 <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 … … 1207 1210 <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> 1208 1211 <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> 1209 </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 considerations1212 </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.4"><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 1210 1213 for new methods. 1211 1214 </p> … … 1219 1222 / <a href="#uri" class="smpl">authority</a> 1220 1223 </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 1221 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>).1224 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.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1222 1225 </p> 1223 1226 <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. … … 1233 1236 <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> 1234 1237 </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> 1235 <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 considerations1238 <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.6"><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 1236 1239 for new status codes. 1237 1240 </p> … … 1252 1255 <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> ) 1253 1256 </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, 1254 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.1257 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.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1255 1258 </p> 1256 1259 <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 … … 1260 1263 them. 1261 1264 </p> 1262 <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.1265 <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.8"><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. 1263 1266 </p> 1264 1267 <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" … … 1485 1488 <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. 1486 1489 </p> 1487 <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>).1490 <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.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1488 1491 </p> 1489 1492 <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, … … 1797 1800 <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. 1798 1801 </p> 1799 <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 to1802 <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.10"><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 1800 1803 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. 1801 1804 </p> … … 1896 1899 <h3 id="rfc.section.6.1.5"><a href="#rfc.section.6.1.5">6.1.5</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 1897 1900 <p id="rfc.section.6.1.5.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1898 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.1 0"><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 understanding1901 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.11"><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 1899 1902 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. 1900 1903 </p> … … 1909 1912 </p> 1910 1913 <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> 1911 <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.1 1"><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 willing1914 <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.12"><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 1912 1915 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 1913 1916 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 1916 1919 <p id="rfc.section.6.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1917 1920 <ul> 1918 <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.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.1919 </li> 1920 <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.1 3"><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.1921 <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.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1922 </li> 1923 <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.14"><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. 1921 1924 </li> 1922 1925 </ul> … … 1962 1965 <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 1963 1966 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1964 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.1 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1967 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.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1965 1968 </li> 1966 1969 </ul> … … 2222 2225 </p> 2223 2226 <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 2224 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.1 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2227 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.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2225 2228 </p> 2226 2229 <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 … … 2643 2646 that most implementations will choose substantially higher limits. 2644 2647 </p> 2645 <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.1 6"><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>).2648 <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.17"><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.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2646 2649 </p> 2647 2650 <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. … … 3473 3476 </ul> 3474 3477 <h2 id="rfc.section.C.19"><a href="#rfc.section.C.19">C.19</a> <a id="changes.since.17" href="#changes.since.17">Since draft-ietf-httpbis-p1-messaging-17</a></h2> 3475 <p id="rfc.section.C.19.p.1">No changes yet.</p> 3478 <p id="rfc.section.C.19.p.1">Closed issues: </p> 3479 <ul> 3480 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/300">http://tools.ietf.org/wg/httpbis/trac/ticket/300</a>>: "Define non-final responses" 3481 </li> 3482 </ul> 3476 3483 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 3477 3484 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> … … 3674 3681 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3675 3682 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.1.1</a>, <a href="#Pad1995"><b>12.2</b></a></li> 3676 <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.5</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>3677 <li><em>Section 2</em> <a href="#rfc.xref.Part2. 3">3.1.1.1</a></li>3678 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2. 7">3.2</a></li>3679 <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>3680 <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.5</a></li>3681 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2. 8">4.1</a></li>3682 <li><em>Section 7.1 .1</em> <a href="#rfc.xref.Part2.11">6.2.3</a></li>3683 <li><em>Section 7.1 </em> <a href="#rfc.xref.Part2.14">6.2.3</a></li>3684 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2. 1">2.4</a></li>3685 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.1 5">8.7</a></li>3686 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.1 7">10.6</a></li>3687 <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>3688 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2. 6">3.2</a></li>3689 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.1 2">6.2.3</a>, <a href="#rfc.xref.Part2.13">6.2.3</a></li>3683 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.2">2.4</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">4.1</a>, <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</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">6.2.3</a>, <a href="#rfc.xref.Part2.16">8.7</a>, <a href="#rfc.xref.Part2.17">10.6</a>, <a href="#rfc.xref.Part2.18">10.6</a>, <a href="#Part2"><b>12.1</b></a><ul> 3684 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1.1</a></li> 3685 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3686 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2.1</a></li> 3687 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.10">6.1.2.2</a>, <a href="#rfc.xref.Part2.11">6.1.5</a></li> 3688 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.9">4.1</a></li> 3689 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.15">6.2.3</a></li> 3690 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.12">6.2.3</a></li> 3691 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.2">2.4</a></li> 3692 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.16">8.7</a></li> 3693 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.18">10.6</a></li> 3694 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2.5">3.1.1.2</a>, <a href="#rfc.xref.Part2.17">10.6</a></li> 3695 <li><em>Section 9.2</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3696 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.13">6.2.3</a>, <a href="#rfc.xref.Part2.14">6.2.3</a></li> 3690 3697 </ul> 3691 3698 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1469 r1471 571 571 a message body containing the payload body (if any, 572 572 <xref target="message.body"/>). 573 </t> 574 <t> 575 Note that 1xx responses (&status-1xx;) are not final; therefore, a server 576 can send zero or more 1xx responses, followed by exactly one final response 577 (with any other status code). 573 578 </t> 574 579 <t> … … 5855 5860 <section title="Since draft-ietf-httpbis-p1-messaging-17" anchor="changes.since.17"> 5856 5861 <t> 5857 No changes yet. 5862 Closed issues: 5863 <list style="symbols"> 5864 <t> 5865 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/300"/>: 5866 "Define non-final responses" 5867 </t> 5868 </list> 5858 5869 </t> 5859 5870 </section>
Note: See TracChangeset
for help on using the changeset viewer.