Changeset 1590 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 12/03/12 09:15:20 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1580 r1590 460 460 } 461 461 @bottom-center { 462 content: "Expires September 1 1, 2012";462 content: "Expires September 13, 2012"; 463 463 } 464 464 @bottom-right { … … 504 504 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 505 505 <meta name="dct.creator" content="Fielding, R."> 506 <meta name="dct.creator" content="Gettys, J.">507 <meta name="dct.creator" content="Mogul, J.">508 <meta name="dct.creator" content="Frystyk, H.">509 <meta name="dct.creator" content="Masinter, L.">510 <meta name="dct.creator" content="Leach, P.">511 <meta name="dct.creator" content="Berners-Lee, T.">512 506 <meta name="dct.creator" content="Lafon, Y."> 513 507 <meta name="dct.creator" content="Reschke, J. F."> 514 508 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 515 <meta name="dct.issued" scheme="ISO8601" content="2012-03-1 0">509 <meta name="dct.issued" scheme="ISO8601" content="2012-03-12"> 516 510 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 517 511 <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."> … … 532 526 <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) 533 527 </td> 534 <td class="right"> J. Gettys</td>528 <td class="right">Y. Lafon, Editor</td> 535 529 </tr> 536 530 <tr> 537 531 <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2817">2817</a> (if approved) 538 532 </td> 539 <td class="right"> Alcatel-Lucent</td>533 <td class="right">W3C</td> 540 534 </tr> 541 535 <tr> 542 536 <td class="left">Intended status: Standards Track</td> 543 <td class="right">J. Mogul</td>544 </tr>545 <tr>546 <td class="left">Expires: September 11, 2012</td>547 <td class="right">HP</td>548 </tr>549 <tr>550 <td class="left"></td>551 <td class="right">H. Frystyk</td>552 </tr>553 <tr>554 <td class="left"></td>555 <td class="right">Microsoft</td>556 </tr>557 <tr>558 <td class="left"></td>559 <td class="right">L. Masinter</td>560 </tr>561 <tr>562 <td class="left"></td>563 <td class="right">Adobe</td>564 </tr>565 <tr>566 <td class="left"></td>567 <td class="right">P. Leach</td>568 </tr>569 <tr>570 <td class="left"></td>571 <td class="right">Microsoft</td>572 </tr>573 <tr>574 <td class="left"></td>575 <td class="right">T. Berners-Lee</td>576 </tr>577 <tr>578 <td class="left"></td>579 <td class="right">W3C/MIT</td>580 </tr>581 <tr>582 <td class="left"></td>583 <td class="right">Y. Lafon, Editor</td>584 </tr>585 <tr>586 <td class="left"></td>587 <td class="right">W3C</td>588 </tr>589 <tr>590 <td class="left"></td>591 537 <td class="right">J. Reschke, Editor</td> 592 538 </tr> 593 539 <tr> 594 <td class="left"> </td>540 <td class="left">Expires: September 13, 2012</td> 595 541 <td class="right">greenbytes</td> 596 542 </tr> 597 543 <tr> 598 544 <td class="left"></td> 599 <td class="right">March 1 0, 2012</td>545 <td class="right">March 12, 2012</td> 600 546 </tr> 601 547 </tbody> … … 627 573 in progress”. 628 574 </p> 629 <p>This Internet-Draft will expire on September 1 1, 2012.</p>575 <p>This Internet-Draft will expire on September 13, 2012.</p> 630 576 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 631 577 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 865 811 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 866 812 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 867 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5. 6</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.813 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 868 814 </p> 869 815 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> … … 1000 946 </li> 1001 947 <li> 1002 <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>).948 <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 6.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>). 1003 949 </p> 1004 950 </li> … … 1102 1048 <tr> 1103 1049 <td class="left">TE</td> 1104 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4. 4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1050 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1105 1051 </tr> 1106 1052 <tr> … … 1113 1059 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1114 1060 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1115 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5. 6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1061 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1116 1062 </p> 1117 1063 <div id="rfc.table.u.3"> … … 1441 1387 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1442 1388 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 1443 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5. 6</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following1389 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 1444 1390 rules are used (with the first applicable one being selected): 1445 1391 </p> … … 1662 1608 </p> 1663 1609 <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 1664 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.3</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1610 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1665 1611 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1666 1612 infinite loop. 1667 1613 </p> 1668 <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.30"><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.1614 <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 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.30"><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. 1669 1615 </p> 1670 1616 <div id="rfc.iref.c.1"></div> … … 1740 1686 <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 1741 1687 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 1742 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.32"><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.1688 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.4.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 detailed discussion of the use and handling of this status code. 1743 1689 </p> 1744 1690 <div id="rfc.iref.23"></div> 1745 1691 <div id="rfc.iref.s.3"></div> 1746 1692 <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> 1747 <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.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><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 defined1693 <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 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><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 1748 1694 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1749 1695 </p> … … 2076 2022 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 2077 2023 points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 2078 in some servers using fixed-length buffers for reading or manipulating the effective request URI.2024 in some servers using fixed-length buffers for reading or manipulating the request-target. 2079 2025 </p> 2080 2026 <div id="rfc.iref.49"></div> … … 2093 2039 <div id="rfc.iref.s.31"></div> 2094 2040 <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> 2095 <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.2</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2041 <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 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2096 2042 </p> 2097 2043 <div id="rfc.figure.u.8"></div> … … 2318 2264 </p> 2319 2265 <ul class="empty"> 2320 <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.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2266 <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.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2321 2267 </li> 2322 2268 </ul> … … 2393 2339 <div id="rfc.iref.h.8"></div> 2394 2340 <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 2395 <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI2396 was obtained(the "referrer", although the header field is misspelled.).2341 <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained 2342 (the "referrer", although the header field is misspelled.). 2397 2343 </p> 2398 2344 <p id="rfc.section.10.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, … … 2400 2346 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2401 2347 </p> 2402 <p id="rfc.section.10.7.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),2403 the Refererfield <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with2348 <p id="rfc.section.10.7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer 2349 field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 2404 2350 non-HTTP URIs (e.g., FTP). 2405 2351 </p> … … 2436 2382 </pre><p id="rfc.section.10.9.p.4">Example:</p> 2437 2383 <div id="rfc.figure.u.35"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2438 </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.3</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2384 </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 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2439 2385 </p> 2440 2386 <div class="note" id="rfc.section.10.9.p.7"> … … 2922 2868 </p> 2923 2869 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2924 <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.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2870 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</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>. 2925 2871 </p> 2926 2872 <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References … … 2931 2877 <tr> 2932 2878 <td class="reference"><b id="Part1">[Part1]</b></td> 2933 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto: jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), March 2012.2879 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), March 2012. 2934 2880 </td> 2935 2881 </tr> 2936 2882 <tr> 2937 2883 <td class="reference"><b id="Part3">[Part3]</b></td> 2938 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto: jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-latest (work in progress), March 2012.2884 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-latest (work in progress), March 2012. 2939 2885 </td> 2940 2886 </tr> 2941 2887 <tr> 2942 2888 <td class="reference"><b id="Part4">[Part4]</b></td> 2943 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto: jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), March 2012.2889 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), March 2012. 2944 2890 </td> 2945 2891 </tr> 2946 2892 <tr> 2947 2893 <td class="reference"><b id="Part5">[Part5]</b></td> 2948 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto: jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), March 2012.2894 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), March 2012. 2949 2895 </td> 2950 2896 </tr> 2951 2897 <tr> 2952 2898 <td class="reference"><b id="Part6">[Part6]</b></td> 2953 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto: jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), March 2012.2899 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), March 2012. 2954 2900 </td> 2955 2901 </tr> 2956 2902 <tr> 2957 2903 <td class="reference"><b id="Part7">[Part7]</b></td> 2958 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto: jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), March 2012.2904 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), March 2012. 2959 2905 </td> 2960 2906 </tr> … … 3034 2980 (editor) 3035 2981 <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:fielding@gbiv.com"><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address> 3036 <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">Alcatel-Lucent Bell Labs</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span> <span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:jg@freedesktop.org"><span class="email">jg@freedesktop.org</span></a></span><span class="vcardline">URI: <a href="http://gettys.wordpress.com/" class="url">http://gettys.wordpress.com/</a></span></address>3037 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:JeffMogul@acm.org"><span class="email">JeffMogul@acm.org</span></a></span></address>3038 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:henrikn@microsoft.com"><span class="email">henrikn@microsoft.com</span></a></span></address>3039 <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:LMM@acm.org"><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address>3040 <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">Email: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address>3041 <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address>3042 2982 <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span> 3043 2983 (editor) … … 3087 3027 </p> 3088 3028 <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 3089 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.43"><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>)3029 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><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>) 3090 3030 </p> 3091 3031 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3705 3645 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li> 3706 3646 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3707 <li><em>Section 4. 4</em> <a href="#rfc.xref.Part1.24">3.2</a></li>3647 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3708 3648 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.28">6.2</a>, <a href="#rfc.xref.Part1.31">6.9</a></li> 3709 3649 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3710 <li><em>Section 5. 6</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>3711 <li><em>Section 6. 2.3</em> <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">10.3</a></li>3712 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li>3713 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li>3714 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.40">10.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>3715 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.30">6.8</a></li>3716 <li><em>Section 11</em> <a href="#rfc.xref.Part1.42">13</a></li>3650 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 3651 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3652 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.40">10.9</a>, <a href="#rfc.xref.Part1.43">A</a></li> 3653 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">10.3</a></li> 3654 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li> 3655 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.30">6.8</a></li> 3656 <li><em>Section 9</em> <a href="#rfc.xref.Part1.42">13</a></li> 3717 3657 </ul> 3718 3658 </li>
Note: See TracChangeset
for help on using the changeset viewer.