Changeset 2079 for draft-ietf-httpbis
- Timestamp:
- 02/01/13 09:41:55 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p0-introduction.html
r2049 r2079 393 393 } 394 394 @bottom-center { 395 content: "Expires June 14,2013";395 content: "Expires June 2013"; 396 396 } 397 397 @bottom-right { … … 426 426 <meta name="dct.creator" content="Reschke, J. F."> 427 427 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest"> 428 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -11">428 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 429 429 <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> 430 430 <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> … … 446 446 </tr> 447 447 <tr> 448 <td class="left">Expires: June 14,2013</td>448 <td class="left">Expires: June 2013</td> 449 449 <td class="right">W3C</td> 450 450 </tr> … … 467 467 <tr> 468 468 <td class="left"></td> 469 <td class="right">December 11,2012</td>469 <td class="right">December 2012</td> 470 470 </tr> 471 471 </tbody> … … 490 490 in progress”. 491 491 </p> 492 <p>This Internet-Draft will expire on June 14,2013.</p>492 <p>This Internet-Draft will expire in June 2013.</p> 493 493 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 494 494 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p1-messaging.html
r2074 r2079 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ly 4,2013";451 content: "Expires June 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -31">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 31,2012</td>522 <td class="right">December 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: Ju ly 4,2013</td>525 <td class="left">Expires: June 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on July 4,2013.</p>553 <p>This Internet-Draft will expire in June 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p2-semantics.html
r2077 r2079 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ly 4,2013";451 content: "Expires June 2013"; 452 452 } 453 453 @bottom-right { … … 495 495 <meta name="dct.creator" content="Reschke, J. F."> 496 496 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 497 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -31">497 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 498 498 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 499 499 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 523 523 <tr> 524 524 <td class="left">Intended status: Standards Track</td> 525 <td class="right">December 31,2012</td>525 <td class="right">December 2012</td> 526 526 </tr> 527 527 <tr> 528 <td class="left">Expires: Ju ly 4,2013</td>528 <td class="left">Expires: June 2013</td> 529 529 <td class="right"></td> 530 530 </tr> … … 554 554 in progress”. 555 555 </p> 556 <p>This Internet-Draft will expire on July 4,2013.</p>556 <p>This Internet-Draft will expire in June 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 766 766 </li> 767 767 <li><a href="#rfc.section.9">9.</a> <a href="#security.considerations">Security Considerations</a><ul> 768 <li><a href="#rfc.section.9.1">9.1</a> <a href="#personal.information">Personal Information</a></li> 769 <li><a href="#rfc.section.9.2">9.2</a> <a href="#attack.pathname">Attacks Based On File and Path Names</a></li> 770 <li><a href="#rfc.section.9.3">9.3</a> <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 771 <li><a href="#rfc.section.9.4">9.4</a> <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 772 <li><a href="#rfc.section.9.5">9.5</a> <a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li> 773 <li><a href="#rfc.section.9.6">9.6</a> <a href="#rfc.section.9.6">Misuse of CONNECT</a></li> 774 <li><a href="#rfc.section.9.7">9.7</a> <a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li> 768 <li><a href="#rfc.section.9.1">9.1</a> <a href="#attack.pathname">Attacks Based On File and Path Names</a></li> 769 <li><a href="#rfc.section.9.2">9.2</a> <a href="#personal.information">Personal Information</a></li> 770 <li><a href="#rfc.section.9.3">9.3</a> <a href="#sensitive.information.in.uris">Sensitive Information in URIs</a></li> 771 <li><a href="#rfc.section.9.4">9.4</a> <a href="#sensitive.information.in.product">Product Information</a></li> 772 <li><a href="#rfc.section.9.5">9.5</a> <a href="#fragment.leakage">Fragment after Redirects</a></li> 773 <li><a href="#rfc.section.9.6">9.6</a> <a href="#fingerprinting">Browser Fingerprinting</a></li> 775 774 </ul> 776 775 </li> … … 1407 1406 <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1408 1407 </p> 1409 <p id="rfc.section.4.3.1.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 9.4</a> for security considerations when used for forms.1410 </p>1411 1408 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1412 1409 <div id="rfc.iref.h.1"></div> … … 1530 1527 <div id="rfc.iref.c.9"></div> 1531 1528 <h3 id="rfc.section.4.3.6"><a href="#rfc.section.4.3.6">4.3.6</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h3> 1532 <p id="rfc.section.4.3.6.p.1">The CONNECT method is only applicable as a request to a proxy. A CONNECT requests that the recipient establish a tunnel to 1533 the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind 1534 forwarding of packets, in both directions, until the connection is closed. 1535 </p> 1536 <p id="rfc.section.4.3.6.p.2">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1529 <p id="rfc.section.4.3.6.p.1">The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target 1530 and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the connection 1531 is closed. 1532 </p> 1533 <p id="rfc.section.4.3.6.p.2">CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1534 </p> 1535 <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1537 1536 For example, 1538 1537 </p> … … 1540 1539 Host: server.example.com:80 1541 1540 1542 </pre><p id="rfc.section.4.3.6.p.4">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another 1543 proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request indicates that the sender (and any inbound proxies) will switch to tunnel mode immediately after 1544 the blank line that concludes the successful response's header block; data received after that blank line is from the server 1545 identified by the request-target. 1546 </p> 1547 <p id="rfc.section.4.3.6.p.5">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1548 </p> 1549 <p id="rfc.section.4.3.6.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1550 governed by HTTP. 1551 </p> 1552 <p id="rfc.section.4.3.6.p.7">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p> 1541 </pre><p id="rfc.section.4.3.6.p.5">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another 1542 proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that 1543 concludes the successful response's header block; data received after that blank line is from the server identified by the 1544 request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the 1545 connection remains governed by HTTP. 1546 </p> 1547 <p id="rfc.section.4.3.6.p.6">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1548 </p> 1549 <p id="rfc.section.4.3.6.p.7">There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known 1550 or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" 1551 would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying 1552 spam email. Proxies that support CONNECT <em class="bcp14">SHOULD</em> restrict its use to a limited set of known ports or a configurable whitelist of safe request targets. 1553 </p> 1554 <p id="rfc.section.4.3.6.p.8">Proxy authentication might be used to establish the authority to create a tunnel. For example,</p> 1553 1555 <div id="rfc.figure.u.19"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1554 1556 Host: server.example.com:80 1555 1557 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1556 1558 1557 </pre><p id="rfc.section.4.3.6.p. 9">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause1559 </pre><p id="rfc.section.4.3.6.p.10">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause 1558 1560 some existing implementations to reject the request. 1559 1561 </p> 1560 <p id="rfc.section.4.3.6.p.1 0">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side1562 <p id="rfc.section.4.3.6.p.11">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side 1561 1563 will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left 1562 1564 undelivered, that data will be discarded. 1563 </p>1564 <p id="rfc.section.4.3.6.p.11">An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.1565 1565 </p> 1566 1566 <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3> … … 1921 1921 <p id="rfc.section.5.3.3.p.6">A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose 1922 1922 user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets 1923 makes it easier for a server to identify an individual by virtue of the user agent's request characteristics ( a.k.a., fingerprinting).1923 makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9.6</a>). 1924 1924 </p> 1925 1925 <p id="rfc.section.5.3.3.p.7">If an Accept-Charset header field is present in a request and none of the available representations for the response has a … … 1987 1987 </div> 1988 1988 <p id="rfc.section.5.3.5.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 1989 preferences of the user in every request . For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section 9.7</a>.1989 preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9.6</a>). 1990 1990 </p> 1991 1991 <p id="rfc.section.5.3.5.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice … … 2086 2086 is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource 2087 2087 that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user 2088 agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">SHOULD NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="# encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 9.4</a> for additional security considerations.2088 agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">SHOULD NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#sensitive.information.in.uris" title="Sensitive Information in URIs">Section 9.3</a> for additional security considerations. 2089 2089 </p> 2090 2090 <p id="rfc.section.5.5.2.p.8">Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the … … 3767 3767 semantics and its use for transferring information over the Internet. 3768 3768 </p> 3769 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="personal.information" href="#personal.information">Personal Information</a></h2> 3770 <p id="rfc.section.9.1.p.1">HTTP clients are often privy to large amounts of personal information, including both information provided by the user to 3771 interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information 3772 about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional 3773 leakage of this information. 3774 </p> 3775 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> 3776 <p id="rfc.section.9.2.p.1">Origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents sent in response to HTTP requests to be only those that were intended by the server administrators. 3777 If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft 3778 Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On 3779 such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended 3780 to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access 3781 control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. 3782 </p> 3783 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2> 3784 <p id="rfc.section.9.3.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any 3785 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 3786 Therefore, applications ought to supply as much control over this information as possible to the provider of that information. 3787 Four header fields are worth special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>. 3788 </p> 3789 <p id="rfc.section.9.3.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 3790 against software that is known to contain security holes. Implementers <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option. 3791 </p> 3792 <p id="rfc.section.9.3.p.3">Proxies that serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that might identify hosts behind the firewall. In particular, 3793 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any <a href="p1-messaging.html#header.via" class="smpl">Via</a> fields generated behind the firewall. 3794 </p> 3795 <p id="rfc.section.9.3.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can 3796 be abused if user details are not separated from the information contained in the Referer. Even when the personal information 3797 has been removed, the Referer header field might indicate a private document's URI whose publication would be inappropriate. 3798 </p> 3799 <p id="rfc.section.9.3.p.5">The information sent in the <a href="#header.from" class="smpl">From</a> field might conflict with the user's privacy interests or their site's security policy, and hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. 3800 </p> 3801 <p id="rfc.section.9.3.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending 3802 of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information. 3803 </p> 3804 <p id="rfc.section.9.3.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields can sometimes be used to determine if a specific client or server is more likely to be vulnerable to a known 3805 security hole. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 3806 no better mechanism. 3807 </p> 3808 <p id="rfc.section.9.3.p.8">Furthermore, the <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough entropy to be used, possibly in conjunction with other material, to uniquely identify the 3809 user. 3810 </p> 3811 <p id="rfc.section.9.3.p.9">Some request methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used 3812 to collect data from the client. 3813 </p> 3814 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> 3815 <p id="rfc.section.9.4.p.1">URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added 3769 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> 3770 <p id="rfc.section.9.1.p.1">Origin servers frequently make use of their local file system to manage the mapping from effective request URI to resource 3771 representations. Implementors need to be aware that most file systems are not designed to protect against malicious file or 3772 path names, and thus depend on the origin server to avoid mapping to file names, folders, or directories that have special 3773 significance to the system. 3774 </p> 3775 <p id="rfc.section.9.1.p.2">For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level 3776 above the current one, and use specially named paths or file names to send data to system devices. Similar naming conventions 3777 might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness 3778 over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization 3779 of case-insensitive names. 3780 </p> 3781 <p id="rfc.section.9.1.p.3">Attacks based on such special names tend to focus on either denial of service (e.g., telling the server to read from a COM 3782 port) or disclosure of configuration and source files that are not meant to be served. 3783 </p> 3784 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="personal.information" href="#personal.information">Personal Information</a></h2> 3785 <p id="rfc.section.9.2.p.1">Clients are often privy to large amounts of personal information, including both information provided by the user to interact 3786 with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the 3787 user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional leakage 3788 of personal information. 3789 </p> 3790 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="sensitive.information.in.uris" href="#sensitive.information.in.uris">Sensitive Information in URIs</a></h2> 3791 <p id="rfc.section.9.3.p.1">URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added 3816 3792 to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include 3817 3793 information within a URI that is sensitive, personally identifiable, or a risk to disclose. 3818 3794 </p> 3819 <p id="rfc.section.9.4.p.2">Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal 3820 information about the user's immediate browsing history and any personal information that might be found in the referring 3821 resource's URI. Further discussion of Referer considerations can be found in <a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 5.5.2</a>. 3822 </p> 3823 <p id="rfc.section.9.4.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing 3824 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 3825 Such services ought to use POST-based form submission instead. 3826 </p> 3827 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2> 3828 <p id="rfc.section.9.5.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of <a href="#header.location" class="smpl">Location</a> and <a href="#header.content-location" class="smpl">Content-Location</a> header fields in responses that are generated under control of said organizations to make sure that they do not attempt to 3829 invalidate resources over which they have no authority. 3830 </p> 3831 <p id="rfc.section.9.5.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a <a href="#header.location" class="smpl">Location</a> header field might leak confidential information to the target server — although the fragment identifier is not transmitted 3832 in the final request, it might be visible to the user agent through other means, such as scripting. 3833 </p> 3834 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> Misuse of CONNECT 3835 </h2> 3836 <p id="rfc.section.9.6.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. 3837 An HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports. 3838 </p> 3839 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2> 3840 <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers that are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding 3841 of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents that offer 3842 the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged 3843 to let the configuration process include a message which makes the user aware of the loss of privacy involved. 3844 </p> 3845 <p id="rfc.section.9.7.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields 3846 by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by 3847 looking for any <a href="#header.vary" class="smpl">Vary</a> header fields generated by the server, that such sending could improve the quality of service. 3848 </p> 3849 <p id="rfc.section.9.7.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be 3850 used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers 3851 to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions 3852 of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will 3853 also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to 3854 be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies 3855 could filter the accept header fields in relayed requests. General purpose user agents that provide a high degree of header 3856 field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 3795 <p id="rfc.section.9.3.p.2">Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in 3796 the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might 3797 be visible to third parties. Such services ought to use POST-based form submission instead. 3798 </p> 3799 <p id="rfc.section.9.3.p.3">Since the <a href="#header.referer" class="smpl">Referer</a> header field tells a target site about the context that resulted in a request, it has the potential to reveal information 3800 about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. 3801 Limitations on Referer are described in <a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 5.5.2</a> to address some of its security considerations. 3802 </p> 3803 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="sensitive.information.in.product" href="#sensitive.information.in.product">Product Information</a></h2> 3804 <p id="rfc.section.9.4.p.1">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier 3805 for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the 3806 apparent software versions being used. 3807 </p> 3808 <p id="rfc.section.9.4.p.2">Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header 3809 information that might identify hosts behind the firewall. The <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field allows intermediaries to replace sensitive machine names with pseudonyms. 3810 </p> 3811 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="fragment.leakage" href="#fragment.leakage">Fragment after Redirects</a></h2> 3812 <p id="rfc.section.9.5.p.1">Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they 3813 will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a 3814 redirect occurs and the original request's fragment identifier is inherited by the new reference in <a href="#header.location" class="smpl">Location</a> (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 7.1.2</a>), this might have the effect of leaking one site's fragment to another site. If the first site uses personal information 3815 in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block 3816 that inheritance. 3817 </p> 3818 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="fingerprinting" href="#fingerprinting">Browser Fingerprinting</a></h2> 3819 <p id="rfc.section.9.6.p.1">Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. 3820 These characteristics might include information related to its TCP behavior, feature capabilities, and scripting environment, 3821 though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting 3822 is considered a privacy concern because it enables tracking of a user agent's behavior over time without the corresponding 3823 controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e., 3824 Web browsers) have taken steps to reduce their fingerprints. 3825 </p> 3826 <p id="rfc.section.9.6.p.2">There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable 3827 fingerprinting. The <a href="#header.from" class="smpl">From</a> header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by 3828 the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so we can assume that fingerprinting 3829 concerns only apply to situations where cookies are disabled or restricted by browser configuration. 3830 </p> 3831 <p id="rfc.section.9.6.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, 3832 particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique 3833 information that is least expected by users is <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> (<a href="#request.conneg" title="Content Negotiation">Section 5.3</a>), including the <a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-charset" class="smpl">Accept-Charset</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, and <a href="#header.accept-language" class="smpl">Accept-Language</a> header fields. 3834 </p> 3835 <p id="rfc.section.9.6.p.4">In addition to the fingerprinting concern, detailed use of the <a href="#header.accept-language" class="smpl">Accept-Language</a> header field can reveal information the user might consider to be of a private nature, because the understanding of particular 3836 languages is often strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy 3837 would be for a user agent to omit the sending of Accept-Language except for sites that have been whitelisted, perhaps via 3838 interaction after detecting a <a href="#header.vary" class="smpl">Vary</a> header field that would indicate language negotiation might be useful. 3839 </p> 3840 <p id="rfc.section.9.6.p.5">In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation 3841 header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users 3842 about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter 3843 the proactive negotiation header fields in relayed requests. 3857 3844 </p> 3858 3845 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 3859 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.3846 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 3860 3847 </p> 3861 3848 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References … … 4155 4142 <p id="rfc.section.C.p.11">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section 4.3.6</a>) 4156 4143 </p> 4157 <p id="rfc.section.C.p.12">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE. 5" title="TRACE">Section 4.3.8</a>)4144 <p id="rfc.section.C.p.12">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3.8</a>) 4158 4145 </p> 4159 4146 <p id="rfc.section.C.p.13">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). … … 4179 4166 </p> 4180 4167 <p id="rfc.section.C.p.22">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications 4181 as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location. 5" title="Location">Section 7.1.2</a>)4168 as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.6" title="Location">Section 7.1.2</a>) 4182 4169 </p> 4183 4170 <p id="rfc.section.C.p.23">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 6.4.4</a>) … … 4199 4186 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 7.4.1</a>) 4200 4187 </p> 4201 <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.4 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.4.2</a>)4188 <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.4.2</a>) 4202 4189 </p> 4203 4190 <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) … … 4224 4211 (any visible US-ASCII character). 4225 4212 </p> 4226 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:4227 </p> 4228 <div id="rfc.figure.u.65"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4229 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4230 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4231 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1. 49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4232 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4233 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4234 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>4235 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4236 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4237 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4238 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.5 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4213 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>: 4214 </p> 4215 <div id="rfc.figure.u.65"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4216 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4217 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4218 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4219 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4220 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4221 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 4222 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4223 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4224 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4225 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.57"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4239 4226 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4240 4227 <div id="rfc.figure.u.66"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4575 4562 </li> 4576 4563 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 4577 <li>Location header field <a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5"> C</a></li>4564 <li>Location header field <a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">8.3.2</a>, <a href="#rfc.xref.header.location.5">9.5</a>, <a href="#rfc.xref.header.location.6">C</a></li> 4578 4565 </ul> 4579 4566 </li> … … 4588 4575 </li> 4589 4576 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4590 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43"> 10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.44">C</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a><ul>4577 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">C</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a><ul> 4591 4578 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 4592 4579 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 4593 4580 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.28">6.6.6</a></li> 4594 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1. 49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a></li>4595 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.5 2">D</a></li>4596 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4 6">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>4597 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.5 1">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>4581 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a></li> 4582 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.53">D</a></li> 4583 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a></li> 4584 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a>, <a href="#rfc.xref.Part1.57">D</a></li> 4598 4585 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li> 4599 4586 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.30">8.1.2</a></li> … … 4609 4596 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 4610 4597 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li> 4611 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.4 4">C</a></li>4598 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.45">C</a></li> 4612 4599 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.23">6.3.4</a></li> 4613 4600 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.35">8.3.1</a></li> 4614 4601 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.27">6.5.15</a></li> 4615 4602 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.17">4.3.8</a></li> 4616 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 3">10</a></li>4603 <li><em>Section 9</em> <a href="#rfc.xref.Part1.44">10</a></li> 4617 4604 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.32">8.3.1</a></li> 4618 4605 </ul> … … 4667 4654 </li> 4668 4655 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 4669 <li>Referer header field <a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9. 4</a>, <a href="#rfc.xref.header.referer.4">C</a></li>4656 <li>Referer header field <a href="#rfc.xref.header.referer.1">5.5</a>, <a href="#rfc.iref.r.2"><b>5.5.2</b></a>, <a href="#rfc.xref.header.referer.2">8.3.2</a>, <a href="#rfc.xref.header.referer.3">9.3</a>, <a href="#rfc.xref.header.referer.4">C</a></li> 4670 4657 <li>representation <a href="#rfc.iref.r.1">3</a></li> 4671 4658 <li><em>REST</em> <a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li> … … 4756 4743 <li>safe <a href="#rfc.iref.s.1"><b>4.2.1</b></a></li> 4757 4744 <li>selected representation <a href="#rfc.iref.s.7"><b>7.2</b></a></li> 4758 <li>Server header field <a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9. 3</a>, <a href="#rfc.xref.header.server.4">C</a></li>4745 <li>Server header field <a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">8.3.2</a>, <a href="#rfc.xref.header.server.3">9.4</a>, <a href="#rfc.xref.header.server.4">C</a></li> 4759 4746 <li>Status Codes Classes 4760 4747 <ul> … … 4770 4757 </li> 4771 4758 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 4772 <li>TRACE method <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc. xref.TRACE.4">9.3</a>, <a href="#rfc.extref.t.50">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>4759 <li>TRACE method <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">C</a>, <a href="#rfc.xref.TRACE.4">C</a></li> 4773 4760 </ul> 4774 4761 </li> 4775 4762 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 4776 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9. 3</a></li>4763 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.2">7.4.2</a>, <a href="#rfc.xref.header.user-agent.3">8.3.2</a>, <a href="#rfc.xref.header.user-agent.4">9.4</a></li> 4777 4764 </ul> 4778 4765 </li> -
draft-ietf-httpbis/latest/p4-conditional.html
r2074 r2079 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ly 4,2013";451 content: "Expires June 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -31">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 517 517 </tr> 518 518 <tr> 519 <td class="left">Expires: Ju ly 4,2013</td>520 <td class="right">December 31,2012</td>519 <td class="left">Expires: June 2013</td> 520 <td class="right">December 2012</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on July 4,2013.</p>547 <p>This Internet-Draft will expire in June 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p5-range.html
r2073 r2079 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ly 4,2013";451 content: "Expires June 2013"; 452 452 } 453 453 @bottom-right { … … 493 493 <meta name="dct.creator" content="Reschke, J. F."> 494 494 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 495 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -31">495 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 497 497 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."> … … 519 519 </tr> 520 520 <tr> 521 <td class="left">Expires: Ju ly 4,2013</td>521 <td class="left">Expires: June 2013</td> 522 522 <td class="right">J. Reschke, Editor</td> 523 523 </tr> … … 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">December 31,2012</td>530 <td class="right">December 2012</td> 531 531 </tr> 532 532 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on July 4,2013.</p>555 <p>This Internet-Draft will expire in June 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.html
r2074 r2079 452 452 } 453 453 @bottom-center { 454 content: "Expires Ju ly 4,2013";454 content: "Expires June 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -31">500 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: Ju ly 4,2013</td>526 <td class="left">Expires: June 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">December 31,2012</td>535 <td class="right">December 2012</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on July 4,2013.</p>561 <p>This Internet-Draft will expire in June 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r2074 r2079 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ly 4,2013";451 content: "Expires June 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-12 -31">491 <meta name="dct.issued" scheme="ISO8601" content="2012-12"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">December 31,2012</td>519 <td class="right">December 2012</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: Ju ly 4,2013</td>522 <td class="left">Expires: June 2013</td> 523 523 <td class="right"></td> 524 524 </tr> … … 546 546 in progress”. 547 547 </p> 548 <p>This Internet-Draft will expire on July 4,2013.</p>548 <p>This Internet-Draft will expire in June 2013.</p> 549 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 550 550 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.