Changeset 1420 for draft-ietf-httpbis
- Timestamp:
- 30/08/11 13:53:41 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1416 r1420 359 359 } 360 360 @bottom-center { 361 content: "Expires February 27, 2012";361 content: "Expires March 2, 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-p1-messaging-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-08- 26">411 <meta name="dct.issued" scheme="ISO8601" content="2011-08-30"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 441 441 </tr> 442 442 <tr> 443 <td class="left">Expires: February 27, 2012</td>443 <td class="left">Expires: March 2, 2012</td> 444 444 <td class="right">HP</td> 445 445 </tr> … … 494 494 <tr> 495 495 <td class="left"></td> 496 <td class="right">August 26, 2011</td>496 <td class="right">August 30, 2011</td> 497 497 </tr> 498 498 </tbody> … … 527 527 in progress”. 528 528 </p> 529 <p>This Internet-Draft will expire on February 27, 2012.</p>529 <p>This Internet-Draft will expire on March 2, 2012.</p> 530 530 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 531 531 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1225 1225 them. 1226 1226 </p> 1227 <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=" #header.field.registration" title="Header Field Registration">Section 10.1</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 9.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.1227 <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.2"><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 9.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. 1228 1228 </p> 1229 1229 <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" … … 1473 1473 <p id="rfc.section.4.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> 1474 1474 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1475 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1475 </pre><p id="rfc.section.4.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 1476 for new methods. 1477 </p> 1478 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1476 1479 <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request. In most cases, the user agent is provided 1477 1480 a URI reference from which it determines an absolute URI for identifying the target resource. When a request to the resource … … 1497 1500 <p id="rfc.section.4.1.2.p.9">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. 1498 1501 </p> 1499 <p id="rfc.section.4.1.2.p.10"><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. 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1502 <p id="rfc.section.4.1.2.p.10"><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.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1500 1503 </p> 1501 1504 <p id="rfc.section.4.1.2.p.11"><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, … … 1530 1533 </div> 1531 1534 <p id="rfc.section.4.1.2.p.20">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 1532 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. 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1535 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>). 1533 1536 </p> 1534 1537 <p id="rfc.section.4.1.2.p.21">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. … … 1610 1613 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.50"></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.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1611 1614 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1612 <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes 1613 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1615 <p id="rfc.section.5.1.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 1616 for new status codes. 1617 </p> 1618 <p id="rfc.section.5.1.1.p.2">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1614 1619 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1615 1620 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. 1616 1621 </p> 1617 <p id="rfc.section.5.1.1.p. 2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.1622 <p id="rfc.section.5.1.1.p.3">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. 1618 1623 There are 5 values for the first digit: 1619 1624 </p> … … 1934 1939 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1935 1940 </p> 1936 <p id="rfc.section.7.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. 5"><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 to1941 <p id="rfc.section.7.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.7"><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 1937 1942 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. 1938 1943 </p> … … 2020 2025 </p> 2021 2026 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2022 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. 6"><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 understanding2027 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.8"><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 2023 2028 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. 2024 2029 </p> … … 2047 2052 </p> 2048 2053 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2049 <p id="rfc.section.7.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. 7"><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 willing2054 <p id="rfc.section.7.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.9"><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 2050 2055 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2051 2056 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2054 2059 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 2055 2060 <ul> 2056 <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 8.2</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2057 </li> 2058 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><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.2061 <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 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2062 </li> 2063 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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. 2059 2064 </li> 2060 2065 </ul> … … 2100 2105 <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 2101 2106 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2102 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 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2107 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.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2103 2108 </li> 2104 2109 </ul> … … 2376 2381 </p> 2377 2382 <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2378 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 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2383 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.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2379 2384 </p> 2380 2385 <p id="rfc.section.9.8.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 … … 2804 2809 that most implementations will choose substantially higher limits. 2805 2810 </p> 2806 <p id="rfc.section.11.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 2"><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.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2811 <p id="rfc.section.11.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.14"><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.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2807 2812 </p> 2808 2813 <p id="rfc.section.11.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. … … 3650 3655 <p id="rfc.section.C.18.p.1">Closed issues: </p> 3651 3656 <ul> 3657 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>>: "Explain header registration" 3658 </li> 3652 3659 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/219">http://tools.ietf.org/wg/httpbis/trac/ticket/219</a>>: "Revise Acknowledgements Sections" 3653 3660 </li> … … 3873 3880 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3874 3881 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li> 3875 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#rfc.xref.Part2.12">11.6</a>, <a href="#rfc.xref.Part2.13">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul> 3876 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li> 3877 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.2">4.1.2</a></li> 3878 <li><em>Section 7</em> <a href="#rfc.xref.Part2.4">5.1.1</a></li> 3879 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.7">7.2.3</a></li> 3880 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.10">7.2.3</a></li> 3882 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">3.2</a>, <a href="#rfc.xref.Part2.3">4.1.1</a>, <a href="#rfc.xref.Part2.4">4.1.2</a>, <a href="#rfc.xref.Part2.5">4.1.2</a>, <a href="#rfc.xref.Part2.6">5.1.1</a>, <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">7.2.3</a>, <a href="#rfc.xref.Part2.13">9.8</a>, <a href="#rfc.xref.Part2.14">11.6</a>, <a href="#rfc.xref.Part2.15">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul> 3883 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">4.1.1</a></li> 3884 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.2">3.2</a></li> 3885 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">5.1.1</a></li> 3886 <li><em>Section 6.1.2</em> <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a></li> 3887 <li><em>Section 6.9</em> <a href="#rfc.xref.Part2.4">4.1.2</a></li> 3888 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.9">7.2.3</a></li> 3889 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.12">7.2.3</a></li> 3881 3890 <li><em>Section 7.2.4</em> <a href="#rfc.xref.Part2.1">2.4</a></li> 3882 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.1 1">9.8</a></li>3883 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.1 3">11.6</a></li>3884 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2. 3">4.1.2</a>, <a href="#rfc.xref.Part2.12">11.6</a></li>3885 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2. 8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a></li>3891 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.13">9.8</a></li> 3892 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.15">11.6</a></li> 3893 <li><em>Section 7.4.15</em> <a href="#rfc.xref.Part2.5">4.1.2</a>, <a href="#rfc.xref.Part2.14">11.6</a></li> 3894 <li><em>Section 8.2</em> <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a></li> 3886 3895 </ul> 3887 3896 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1414 r1420 31 31 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 <!ENTITY method "<xref target='Part2' x:rel='#method' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 <!ENTITY status-code-reasonphr "<xref target='Part2' x:rel='#status.code.and.reason.phrase' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 35 <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 36 <!ENTITY status-100 "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 38 40 <!ENTITY status-4xx "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 41 <!ENTITY status-414 "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 42 <!ENTITY cons-new-header-fields "<xref target='Part2' x:rel='#considerations.for.creating.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 40 43 ]> 41 44 <?rfc toc="yes" ?> … … 1241 1244 <t> 1242 1245 New HTTP header fields &SHOULD; be registered with IANA according 1243 to the procedures in <xref target="header.field.registration"/>.1246 to the procedures in &cons-new-header-fields;. 1244 1247 Unrecognized header fields &MUST; be forwarded by a proxy unless the 1245 1248 field-name is listed in the Connection header field … … 1698 1701 <x:ref>Method</x:ref> = <x:ref>token</x:ref> 1699 1702 </artwork></figure> 1703 <t> 1704 See &method; for further information, such as the list of methods defined 1705 by this specification, the IANA registry, and considerations for new methods. 1706 </t> 1700 1707 </section> 1701 1708 … … 1993 2000 <x:anchor-alias value="Status-Code"/> 1994 2001 <t> 1995 The Status-Code element is a 3-digit integer result code of the 1996 attempt to understand and satisfy the request. These codes are fully 1997 defined in &status-codes;. The Reason Phrase exists for the sole 1998 purpose of providing a textual description associated with the numeric 1999 status code, out of deference to earlier Internet application protocols 2000 that were more frequently used with interactive text clients. 2001 A client &SHOULD; ignore the content of the Reason Phrase. 2002 The Status-Code element is a 3-digit integer result code of the attempt to 2003 understand and satisfy the request. See &status-code-reasonphr; for 2004 further information, such as the list of status codes defined by this 2005 specification, the IANA registry, and considerations for new status codes. 2006 </t> 2007 <t> 2008 The Reason Phrase exists for the sole purpose of providing a textual 2009 description associated with the numeric status code, out of deference to 2010 earlier Internet application protocols that were more frequently used with 2011 interactive text clients. A client &SHOULD; ignore the content of the Reason 2012 Phrase. 2002 2013 </t> 2003 2014 <t> … … 6158 6169 <list style="symbols"> 6159 6170 <t> 6171 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>: 6172 "Explain header registration" 6173 </t> 6174 <t> 6160 6175 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/219"/>: 6161 6176 "Revise Acknowledgements Sections" -
draft-ietf-httpbis/latest/p2-semantics.html
r1417 r1420 359 359 } 360 360 @bottom-center { 361 content: "Expires February 29, 2012";361 content: "Expires March 2, 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-p2-semantics-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-08- 28">410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-30"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <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."> … … 439 439 </tr> 440 440 <tr> 441 <td class="left">Expires: February 29, 2012</td>441 <td class="left">Expires: March 2, 2012</td> 442 442 <td class="right">HP</td> 443 443 </tr> … … 492 492 <tr> 493 493 <td class="left"></td> 494 <td class="right">August 28, 2011</td>494 <td class="right">August 30, 2011</td> 495 495 </tr> 496 496 </tbody> … … 522 522 in progress”. 523 523 </p> 524 <p>This Internet-Draft will expire on February 29, 2012.</p>524 <p>This Internet-Draft will expire on March 2, 2012.</p> 525 525 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 526 526 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p3-payload.html
r1416 r1420 359 359 } 360 360 @bottom-center { 361 content: "Expires February 27, 2012";361 content: "Expires March 2, 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-p3-payload-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-08- 26">410 <meta name="dct.issued" scheme="ISO8601" content="2011-08-30"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <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 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: February 27, 2012</td>436 <td class="left">Expires: March 2, 2012</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 491 491 <tr> 492 492 <td class="left"></td> 493 <td class="right">August 26, 2011</td>493 <td class="right">August 30, 2011</td> 494 494 </tr> 495 495 </tbody> … … 519 519 in progress”. 520 520 </p> 521 <p>This Internet-Draft will expire on February 27, 2012.</p>521 <p>This Internet-Draft will expire on March 2, 2012.</p> 522 522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523 523 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r1415 r1420 359 359 } 360 360 @bottom-center { 361 content: "Expires February 27, 2012";361 content: "Expires March 2, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-08- 26">406 <meta name="dct.issued" scheme="ISO8601" content="2011-08-30"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: February 27, 2012</td>437 <td class="left">Expires: March 2, 2012</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">August 26, 2011</td>490 <td class="right">August 30, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on February 27, 2012.</p>518 <p>This Internet-Draft will expire on March 2, 2012.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.