Changeset 2072 for draft-ietf-httpbis
- Timestamp:
- 31/12/12 10:51:33 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2071 r2072 449 449 } 450 450 @bottom-center { 451 content: "Expires July 3, 2013";451 content: "Expires July 4, 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-3 0">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-31"> 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 3 0, 2012</td>522 <td class="right">December 31, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: July 3, 2013</td>525 <td class="left">Expires: July 4, 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 3, 2013.</p>553 <p>This Internet-Draft will expire on July 4, 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/p1-messaging.xml
r2071 r2072 2378 2378 <section title="Effective Request URI" anchor="effective.request.uri"> 2379 2379 <iref primary="true" item="effective request URI"/> 2380 <x:anchor-alias value="effective request URI"/> 2380 2381 <t> 2381 2382 A server that receives an HTTP request message &MUST; reconstruct -
draft-ietf-httpbis/latest/p2-semantics.html
r2071 r2072 449 449 } 450 450 @bottom-center { 451 content: "Expires July 3, 2013";451 content: "Expires July 4, 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-3 0">497 <meta name="dct.issued" scheme="ISO8601" content="2012-12-31"> 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 3 0, 2012</td>525 <td class="right">December 31, 2012</td> 526 526 </tr> 527 527 <tr> 528 <td class="left">Expires: July 3, 2013</td>528 <td class="left">Expires: July 4, 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 3, 2013.</p>556 <p>This Internet-Draft will expire on July 4, 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> … … 835 835 in <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 836 836 </p> 837 <p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the "target URI" in one of various forms, as defined in (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). When a request is received, the server reconstructs an "effective request URI"for 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.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).837 <p id="rfc.section.2.p.2">When a client constructs an HTTP/1.1 request message, it sends the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> in one of various forms, as defined in (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). When a request is received, the server reconstructs an <a href="p1-messaging.html#effective.request.uri" class="smpl">effective request URI</a> for 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.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 838 838 </p> 839 839 <p id="rfc.section.2.p.3">One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the … … 1822 1822 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#imported.abnf" class="smpl">token</a> [ "=" <a href="#imported.abnf" class="smpl">word</a> ] 1823 1823 </pre><p id="rfc.section.5.3.2.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 1824 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 1825 </p> 1826 <p id="rfc.section.5.3.2.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative weight, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. 1824 all subtypes of that type. The media-range can include media type parameters that are applicable to that range. 1825 </p> 1826 <p id="rfc.section.5.3.2.p.4">Each media-range might be followed by zero or more applicable media type parameters (e.g., <a href="#charset" class="smpl">charset</a>), an optional "q" parameter for indicating a relative weight (<a href="#quality.values" title="Quality Values">Section 5.3.1</a>), and then zero or more extension parameters. The "q" parameter is necessary if any accept-ext are present, since it acts 1827 as a separator between the two parameter sets. 1827 1828 </p> 1828 1829 <div class="note" id="rfc.section.5.3.2.p.5"> … … 2069 2070 <div id="rfc.iref.r.2"></div> 2070 2071 <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a> <a id="header.referer" href="#header.referer">Referer</a></h3> 2071 <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained 2072 (the "referrer", although the header field is misspelled.). 2073 </p> 2074 <p id="rfc.section.5.5.2.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, 2075 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 2076 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2077 </p> 2078 <p id="rfc.section.5.5.2.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 2079 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 2080 non-HTTP URIs (e.g., FTP). 2072 <p id="rfc.section.5.5.2.p.1">The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the <a href="p1-messaging.html#target-resource" class="smpl">target URI</a> was obtained (i.e., the "referrer", though the field name is misspelled). A user agent <em class="bcp14">MUST</em> exclude any fragment or userinfo components <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> when generating the Referer field value. 2081 2073 </p> 2082 2074 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a> 2083 </pre><p id="rfc.section.5.5.2.p.5">Example:</p> 2075 </pre><p id="rfc.section.5.5.2.p.3">Referer allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc. It 2076 also allows obsolete or mistyped links to be found for maintenance. Some servers use Referer as a means of denying links from 2077 other sites (so-called "deep linking") or restricting cross-site request forgery (CSRF), but not all requests contain a Referer 2078 header field. 2079 </p> 2080 <p id="rfc.section.5.5.2.p.4">Example:</p> 2084 2081 <div id="rfc.figure.u.37"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2085 </pre><p id="rfc.section.5.5.2.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 9.4</a> for security considerations. 2082 </pre><p id="rfc.section.5.5.2.p.6">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry 2083 within the user's bookmarks/favorites), the user agent <em class="bcp14">MUST</em> either exclude Referer or send it with a value of "about:blank". 2084 </p> 2085 <p id="rfc.section.5.5.2.p.7">The Referer field has the potential to reveal information about the request context or browsing history of the user, which 2086 is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource 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 a (non-secure) 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. 2089 </p> 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 2091 unfortunate side-effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. 2092 Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes 2093 to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. 2094 Intermediaries <em class="bcp14">SHOULD NOT</em> modify or delete the Referer field when the field value shares the same scheme and host as the request target. 2086 2095 </p> 2087 2096 <div id="rfc.iref.u.1"></div> … … 2908 2917 </p> 2909 2918 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#imported.abnf" class="smpl">URI-reference</a> 2910 </pre><p id="rfc.section.7.1.2.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986. 1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, contains a fragment identifier, and the Location value does not,2919 </pre><p id="rfc.section.7.1.2.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, contains a fragment identifier, and the Location value does not, 2911 2920 then the original URI's fragment identifier is appended to the Location value. 2912 2921 </p> … … 3800 3809 </p> 3801 3810 <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> 3802 <p id="rfc.section.9.4.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly 3803 recommended that the user be able to select whether or not the <a href="#header.referer" class="smpl">Referer</a> field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively 3804 enable/disable the sending of Referer and From information. 3805 </p> 3806 <p id="rfc.section.9.4.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a <a href="#header.referer" class="smpl">Referer</a> header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 3811 <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 3812 to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include 3813 information within a URI that is sensitive, personally identifiable, or a risk to disclose. 3814 </p> 3815 <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 3816 information about the user's immediate browsing history and any personal information that might be found in the referring 3817 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>. 3807 3818 </p> 3808 3819 <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 3809 3820 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 3810 Such services canuse POST-based form submission instead.3821 Such services ought to use POST-based form submission instead. 3811 3822 </p> 3812 3823 <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> … … 4153 4164 <p id="rfc.section.C.p.16">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section 7.1.1.2</a>) 4154 4165 </p> 4155 <p id="rfc.section.C.p.17">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer. 3" title="Referer">Section 5.5.2</a>)4166 <p id="rfc.section.C.p.17">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.4" title="Referer">Section 5.5.2</a>) 4156 4167 </p> 4157 4168 <p id="rfc.section.C.p.18">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one). … … 4653 4664 </li> 4654 4665 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 4655 <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"> C</a></li>4666 <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 4667 <li>representation <a href="#rfc.iref.r.1">3</a></li> 4657 4668 <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> … … 4701 4712 </li> 4702 4713 <li><em>RFC2978</em> <a href="#rfc.xref.RFC2978.1">3.1.1.2</a>, <a href="#RFC2978"><b>11.2</b></a></li> 4703 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1"> 7.1.2</a>, <a href="#rfc.xref.RFC3986.2">7.1.2</a>, <a href="#RFC3986"><b>11.1</b></a><ul>4704 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986. 1">7.1.2</a></li>4705 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986. 2">7.1.2</a></li>4714 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">5.5.2</a>, <a href="#rfc.xref.RFC3986.2">7.1.2</a>, <a href="#rfc.xref.RFC3986.3">7.1.2</a>, <a href="#RFC3986"><b>11.1</b></a><ul> 4715 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.2">7.1.2</a></li> 4716 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.3">7.1.2</a></li> 4706 4717 </ul> 4707 4718 </li> … … 4756 4767 </li> 4757 4768 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 4758 <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. 48">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li>4769 <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 4770 </ul> 4760 4771 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2071 r2072 268 268 <t> 269 269 When a client constructs an HTTP/1.1 request message, it sends the 270 "target URI"in one of various forms, as defined in270 <x:ref>target URI</x:ref> in one of various forms, as defined in 271 271 (&request-target;). When a request is received, the server reconstructs 272 an "effective request URI"for the target resource272 an <x:ref>effective request URI</x:ref> for the target resource 273 273 (&effective-request-uri;). 274 274 </t> … … 2024 2024 The asterisk "*" character is used to group media types into ranges, 2025 2025 with "*/*" indicating all media types and "type/*" indicating all 2026 subtypes of that type. The media-range &MAY;include media type2026 subtypes of that type. The media-range can include media type 2027 2027 parameters that are applicable to that range. 2028 2028 </t> 2029 2029 <t> 2030 Each media-range &MAY; be followed by one or more accept-params,2031 beginning with the "q" parameter for indicating a relative weight,2032 as defined in &qvalue;.2033 The first "q" parameter (if any) separates the media-range2034 parameter(s) from the accept-params.2030 Each media-range might be followed by zero or more applicable media type 2031 parameters (e.g., <x:ref>charset</x:ref>), an optional "q" parameter for 2032 indicating a relative weight (&qvalue;), and then zero or more extension 2033 parameters. The "q" parameter is necessary if any accept-ext are present, 2034 since it acts as a separator between the two parameter sets. 2035 2035 </t> 2036 2036 <x:note> … … 2374 2374 <x:anchor-alias value="Referer"/> 2375 2375 <t> 2376 The "Referer" [sic] header field allows the client to specify the 2377 URI of the resource from which the target URI was obtained (the 2378 "referrer", although the header field is misspelled.). 2379 </t> 2380 <t> 2381 The Referer header field allows servers to generate lists of back-links to 2382 resources for interest, logging, optimized caching, etc. It also allows 2383 obsolete or mistyped links to be traced for maintenance. Some servers use 2384 Referer as a means of controlling where they allow links from (so-called 2385 "deep linking"), but legitimate requests do not always 2386 contain a Referer header field. 2387 </t> 2388 <t> 2389 If the target URI was obtained from a source that does not have its own 2390 URI (e.g., input from the user keyboard), the Referer field &MUST; either be 2391 sent with the value "about:blank", or not be sent at all. Note that this 2392 requirement does not apply to sources with non-HTTP URIs (e.g., FTP). 2376 The "Referer" [sic] header field allows the user agent to specify a URI 2377 reference for the resource from which the <x:ref>target URI</x:ref> was 2378 obtained (i.e., the "referrer", though the field name is misspelled). 2379 A user agent &MUST; exclude any fragment or userinfo components 2380 <xref target="RFC3986"/> when generating the Referer field value. 2393 2381 </t> 2394 2382 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/> … … 2396 2384 </artwork></figure> 2397 2385 <t> 2386 Referer allows servers to generate back-links to other resources for 2387 simple analytics, logging, optimized caching, etc. It also allows 2388 obsolete or mistyped links to be found for maintenance. Some servers use 2389 Referer as a means of denying links from other sites (so-called 2390 "deep linking") or restricting cross-site request forgery (CSRF), 2391 but not all requests contain a Referer header field. 2392 </t> 2393 <t> 2398 2394 Example: 2399 2395 </t> … … 2402 2398 </artwork></figure> 2403 2399 <t> 2404 If the field value is a relative URI, it &SHOULD; be interpreted 2405 relative to the effective request URI. The URI &MUST-NOT; include a fragment. See 2406 <xref target="encoding.sensitive.information.in.uris"/> for security considerations. 2400 If the target URI was obtained from a source that does not have its own 2401 URI (e.g., input from the user keyboard, or an entry within the user's 2402 bookmarks/favorites), the user agent &MUST; either exclude Referer or 2403 send it with a value of "about:blank". 2404 </t> 2405 <t> 2406 The Referer field has the potential to reveal information about the request 2407 context or browsing history of the user, which is a privacy concern if the 2408 referring resource's identifier reveals personal information (such as an 2409 account name) or a resource that is supposed to be confidential (such as 2410 behind a firewall or internal to a secured service). Most general-purpose 2411 user agents do not send the Referer header field when the referring 2412 resource is a local "file" or "data" URI. A user agent &SHOULD-NOT; send a 2413 <x:ref>Referer</x:ref> header field in a (non-secure) HTTP request if the 2414 referring page was received with a secure protocol. 2415 See <xref target="encoding.sensitive.information.in.uris"/> for additional 2416 security considerations. 2417 </t> 2418 <t> 2419 Some intermediaries have been known to indiscriminately remove Referer 2420 header fields from outgoing requests. This has the unfortunate side-effect 2421 of interfering with protection against CSRF attacks, which can be far 2422 more harmful to their users. Intermediaries and user agent extensions that 2423 wish to limit information disclosure in Referer ought to restrict their 2424 changes to specific edits, such as replacing internal domain names with 2425 pseudonyms or truncating the query and/or path components. 2426 Intermediaries &SHOULD-NOT; modify or delete the Referer field when the 2427 field value shares the same scheme and host as the request target. 2407 2428 </t> 2408 2429 </section> … … 4760 4781 <section title="Encoding Sensitive Information in URIs" anchor="encoding.sensitive.information.in.uris"> 4761 4782 <t> 4762 Because the source of a link might be private information or might4763 re veal an otherwise private information source, it is strongly4764 recommended that the user be able to select whether or not the4765 <x:ref>Referer</x:ref> field is sent. For example, a browser client could4766 have a toggle switch for browsing openly/anonymously, which would4767 respectively enable/disable the sending of Referer and From 4768 information. 4769 </t> 4770 <t> 4771 Clients &SHOULD-NOT; include a <x:ref>Referer</x:ref> header field in a4772 (non-secure) HTTP request if the referring page was transferred with a secure4773 protocol.4783 URIs are intended to be shared, not secured, even when they identify secure 4784 resources. URIs are often shown on displays, added to templates when a page 4785 is printed, and stored in a variety of unprotected bookmark lists. 4786 It is therefore unwise to include information within a URI that 4787 is sensitive, personally identifiable, or a risk to disclose. 4788 </t> 4789 <t> 4790 Since the Referer header field tells a target site about the context that 4791 resulted in a request, it has the potential to reveal information about the 4792 user's immediate browsing history and any personal information that might 4793 be found in the referring resource's URI. Further discussion of Referer 4794 considerations can be found in <xref target="header.referer"/>. 4774 4795 </t> 4775 4796 <t> … … 4777 4798 sensitive data because that data will be placed in the request-target. Many 4778 4799 existing servers, proxies, and user agents log or display the request-target 4779 in places where it might be visible to third parties. Such services can4780 use POST-based form submission instead.4800 in places where it might be visible to third parties. Such services ought 4801 to use POST-based form submission instead. 4781 4802 </t> 4782 4803 </section> … … 4881 4902 <x:defines>Upgrade</x:defines> 4882 4903 <x:defines>Via</x:defines> 4904 <x:defines>effective request URI</x:defines> 4905 <x:defines>target URI</x:defines> 4883 4906 </x:source> 4884 4907 </reference>
Note: See TracChangeset
for help on using the changeset viewer.