Changeset 1590 for draft-ietf-httpbis/latest
- Timestamp:
- 12/03/12 09:15:20 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1589 r1590 756 756 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 757 757 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 758 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource and relationships between resources. Messages are passed in a format similar to that used 759 by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 758 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 760 759 </p> 761 760 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented … … 873 872 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 874 873 </p> 875 <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's876 URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use874 <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target URI 875 (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>). For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use 877 876 a proxy via some other connection port or protocol instead of using the defaults. 878 877 </p> … … 1053 1052 </pre><p id="rfc.section.2.7.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows 1054 1053 any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, 1055 or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the request's target URI1056 (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>), if known by the recipient, or the effective requestURI (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>).1054 or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request 1055 URI (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>). 1057 1056 </p> 1058 1057 <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> … … 1879 1878 from this reconstruction process is referred to as the "effective request URI". 1880 1879 </p> 1881 <p id="rfc.section.5.5.p.2">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the 1880 <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p> 1881 <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the 1882 1882 effective request URI is constructed as follows. 1883 1883 </p> 1884 <p id="rfc.section.5.5.p. 3">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,1884 <p id="rfc.section.5.5.p.4">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, 1885 1885 the scheme is "http". 1886 1886 </p> 1887 <p id="rfc.section.5.5.p. 4">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target.1887 <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target. 1888 1888 Otherwise, if a Host header field is supplied with a non-empty field-value, then the authority component is the same as the 1889 1889 Host field-value. Otherwise, the authority component is the concatenation of the default hostname configured for the server, 1890 1890 a colon (":"), and the connection's incoming TCP port number in decimal form. 1891 1891 </p> 1892 <p id="rfc.section.5.5.p. 5">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component1892 <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component 1893 1893 is empty. Otherwise, the combined path and query component is the same as the request-target. 1894 1894 </p> 1895 <p id="rfc.section.5.5.p. 6">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating1895 <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating 1896 1896 the scheme, "://", authority, and combined path and query component. 1897 1897 </p> … … 1906 1906 </pre> <div id="rfc.figure.u.58"></div> 1907 1907 <p>has an effective request URI of</p> <pre class="text">https://www.example.org 1908 </pre> <p id="rfc.section.5.5.p.1 1">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI.1909 </p> 1910 <p id="rfc.section.5.5.p.1 2">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess1908 </pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI. 1909 </p> 1910 <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess 1911 1911 the effective request URI's authority component. 1912 1912 </p> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1589 r1590 162 162 message payloads for flexible interaction with network-based hypertext 163 163 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 164 standard <xref target="RFC3986"/> to indicate the target resource and165 relationships between resources.164 standard <xref target="RFC3986"/> to indicate the target resource 165 (<xref target="target-resource"/>) and relationships between resources. 166 166 Messages are passed in a format similar to that used by Internet mail 167 167 <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions … … 397 397 <t> 398 398 The specific connection protocols to be used for an interaction 399 are determined by client configuration and the target resource's URI. 399 are determined by client configuration and the target URI 400 (<xref target="target-resource"/>). 400 401 For example, the "http" URI scheme 401 402 (<xref target="http.uri"/>) indicates a default connection of TCP … … 780 781 path and optional query components, or some combination of the above. 781 782 Unless otherwise indicated, URI references are parsed 782 relative to the request's target URI (<xref target="target-resource"/>), 783 if known by the recipient, or the effective request URI 783 relative to the effective request URI 784 784 (<xref target="effective.request.uri"/>). 785 785 </t> … … 2425 2425 The URI derived from this reconstruction process is referred to as the 2426 2426 "effective request URI". 2427 </t> 2428 <t> 2429 For a user agent, the effective request URI is the target URI. 2427 2430 </t> 2428 2431 <t> -
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> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1586 r1590 1995 1995 itself), or when the server is under attack by a client attempting to 1996 1996 exploit security holes present in some servers using fixed-length 1997 buffers for reading or manipulating the effective request URI.1997 buffers for reading or manipulating the request-target. 1998 1998 </t> 1999 1999 </section> … … 2627 2627 <t> 2628 2628 The "Referer" [sic] header field allows the client to specify the 2629 URI of the resource from which the effective request URI was obtained (the2629 URI of the resource from which the target URI was obtained (the 2630 2630 "referrer", although the header field is misspelled.). 2631 2631 </t> … … 2639 2639 </t> 2640 2640 <t> 2641 If the effective request URI was obtained from a source that does not have its own2641 If the target URI was obtained from a source that does not have its own 2642 2642 URI (e.g., input from the user keyboard), the Referer field &MUST; either be 2643 2643 sent with the value "about:blank", or not be sent at all. Note that this
Note: See TracChangeset
for help on using the changeset viewer.