Changeset 1539 for draft-ietf-httpbis/latest
- Timestamp:
- 19/02/12 10:32:58 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1538 r1539 460 460 } 461 461 @bottom-center { 462 content: "Expires August 2 1, 2012";462 content: "Expires August 22, 2012"; 463 463 } 464 464 @bottom-right { … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-1 8">512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-19"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: August 2 1, 2012</td>544 <td class="left">Expires: August 22, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">February 1 8, 2012</td>597 <td class="right">February 19, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on August 2 1, 2012.</p>630 <p>This Internet-Draft will expire on August 22, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p2-semantics.html
r1538 r1539 460 460 } 461 461 @bottom-center { 462 content: "Expires August 2 1, 2012";462 content: "Expires August 22, 2012"; 463 463 } 464 464 @bottom-right { … … 513 513 <meta name="dct.creator" content="Reschke, J. F."> 514 514 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 515 <meta name="dct.issued" scheme="ISO8601" content="2012-02-1 8">515 <meta name="dct.issued" scheme="ISO8601" content="2012-02-19"> 516 516 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 517 517 <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."> … … 544 544 </tr> 545 545 <tr> 546 <td class="left">Expires: August 2 1, 2012</td>546 <td class="left">Expires: August 22, 2012</td> 547 547 <td class="right">HP</td> 548 548 </tr> … … 597 597 <tr> 598 598 <td class="left"></td> 599 <td class="right">February 1 8, 2012</td>599 <td class="right">February 19, 2012</td> 600 600 </tr> 601 601 </tbody> … … 627 627 in progress”. 628 628 </p> 629 <p>This Internet-Draft will expire on August 2 1, 2012.</p>629 <p>This Internet-Draft will expire on August 22, 2012.</p> 630 630 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 631 631 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1003 1003 </li> 1004 1004 <li> 1005 <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 9.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>).1005 <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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1006 1006 </p> 1007 1007 </li> … … 1065 1065 <tr> 1066 1066 <td class="left">Host</td> 1067 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1067 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1068 1068 </tr> 1069 1069 <tr> … … 1667 1667 </p> 1668 1668 <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1669 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1669 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1670 1670 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1671 1671 infinite loop. 1672 1672 </p> 1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1673 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1674 1674 </p> 1675 1675 <div id="rfc.iref.c.1"></div> … … 1746 1746 <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1747 1747 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1748 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1748 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1749 1749 </p> 1750 1750 <div id="rfc.iref.23"></div> 1751 1751 <div id="rfc.iref.s.3"></div> 1752 1752 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1753 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1753 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1754 1754 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1755 1755 </p> … … 2099 2099 <div id="rfc.iref.s.31"></div> 2100 2100 <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2101 <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2101 <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2102 2102 </p> 2103 2103 <div id="rfc.figure.u.8"></div> … … 2324 2324 </p> 2325 2325 <ul class="empty"> 2326 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2326 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2327 2327 </li> 2328 2328 </ul> … … 2442 2442 </pre><p id="rfc.section.10.9.p.4">Example:</p> 2443 2443 <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2444 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2444 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2445 2445 </p> 2446 2446 <div class="note" id="rfc.section.10.9.p.7"> … … 2928 2928 </p> 2929 2929 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2930 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 1 2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2930 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2931 2931 </p> 2932 2932 <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References … … 3093 3093 </p> 3094 3094 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3095 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.9</a>)3095 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.9</a>) 3096 3096 </p> 3097 3097 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3180 3180 3181 3181 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in [Part1], Section 2.7> 3182 <a href="#product.tokens" class="smpl">product</a> = <product, defined in [Part1], Section 5.2> 3182 <a href="#product.tokens" class="smpl">product</a> = token [ "/" product-version ] 3183 <a href="#product.tokens" class="smpl">product-version</a> = token 3183 3184 3184 3185 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 3.2.4> … … 3707 3708 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3708 3709 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3709 <li><em>Section 7.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li>3710 <li><em>Section 9.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li>3711 <li><em>Section 9.2</em> <a href="#rfc.xref.Part1.23">3.2</a></li>3712 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li>3713 <li><em>Section 9.4</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li>3714 <li><em>Section 10.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li>3715 <li><em>Section 1 2</em> <a href="#rfc.xref.Part1.41">13</a></li>3710 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li> 3711 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3712 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3713 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li> 3714 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li> 3715 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li> 3716 <li><em>Section 11</em> <a href="#rfc.xref.Part1.41">13</a></li> 3716 3717 </ul> 3717 3718 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1538 r1539 4073 4073 4074 4074 <x:ref>partial-URI</x:ref> = <partial-URI, defined in [Part1], Section 2.7> 4075 <x:ref>product</x:ref> = <product, defined in [Part1], Section 5.2> 4075 <x:ref>product</x:ref> = token [ "/" product-version ] 4076 <x:ref>product-version</x:ref> = token 4076 4077 4077 4078 <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 3.2.4>
Note: See TracChangeset
for help on using the changeset viewer.