Changeset 2072 for draft-ietf-httpbis


Ignore:
Timestamp:
31/12/12 10:51:33 (10 years ago)
Author:
fielding@…
Message:

update the description of Referer to current practice and actual security concerns

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2071 r2072  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 3, 2013";
     451       content: "Expires July 4, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 30, 2012</td>
     522               <td class="right">December 31, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: July 3, 2013</td>
     525               <td class="left">Expires: July 4, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
    … …  
    551551         in progress”.
    552552      </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>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <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  
    23782378<section title="Effective Request URI" anchor="effective.request.uri">
    23792379  <iref primary="true" item="effective request URI"/>
     2380  <x:anchor-alias value="effective request URI"/>
    23802381<t>
    23812382   A server that receives an HTTP request message &MUST; reconstruct

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2071 r2072  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 3, 2013";
     451       content: "Expires July 4, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
     497      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <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.">
    … …  
    523523            <tr>
    524524               <td class="left">Intended status: Standards Track</td>
    525                <td class="right">December 30, 2012</td>
     525               <td class="right">December 31, 2012</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: July 3, 2013</td>
     528               <td class="left">Expires: July 4, 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
    … …  
    554554         in progress”.
    555555      </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>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    835835         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>.
    836836      </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>).
    838838      </p>
    839839      <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
    … …  
    18221822  <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> ]
    18231823</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&nbsp;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&nbsp;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.
    18271828      </p>
    18281829      <div class="note" id="rfc.section.5.3.2.p.5">
    … …  
    20692070      <div id="rfc.iref.r.2"></div>
    20702071      <h3 id="rfc.section.5.5.2"><a href="#rfc.section.5.5.2">5.5.2</a>&nbsp;<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.
    20812073      </p>
    20822074      <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>
    20842081      <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&nbsp;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&nbsp;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.
    20862095      </p>
    20872096      <div id="rfc.iref.u.1"></div>
    … …  
    29082917      </p>
    29092918      <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,
    29112920         then the original URI's fragment identifier is appended to the Location value.
    29122921      </p>
    … …  
    38003809      </p>
    38013810      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<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&nbsp;5.5.2</a>.
    38073818      </p>
    38083819      <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
    38093820         servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
    3810          Such services can use POST-based form submission instead.
     3821         Such services ought to use POST-based form submission instead.
    38113822      </p>
    38123823      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    … …  
    41534164      <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&nbsp;7.1.1.2</a>)
    41544165      </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&nbsp;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&nbsp;5.5.2</a>)
    41564167      </p>
    41574168      <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).
    … …  
    46534664            </li>
    46544665            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    4655                   <li>Referer header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    46564667                  <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1">3</a></li>
    46574668                  <li><em>REST</em>&nbsp;&nbsp;<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>
    … …  
    47014712                  </li>
    47024713                  <li><em>RFC2978</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.1.2</a></li>
    4705                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.1.2</a></li>
     4714                  <li><em>RFC3986</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.1.2</a></li>
     4716                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.3">7.1.2</a></li>
    47064717                     </ul>
    47074718                  </li>
    … …  
    47564767            </li>
    47574768            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    4758                   <li>TRACE method&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    47594770               </ul>
    47604771            </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2071 r2072  
    268268<t>
    269269   When a client constructs an HTTP/1.1 request message, it sends the
    270    "target URI" in one of various forms, as defined in
     270   <x:ref>target URI</x:ref> in one of various forms, as defined in
    271271   (&request-target;). When a request is received, the server reconstructs
    272    an "effective request URI" for the target resource
     272   an <x:ref>effective request URI</x:ref> for the target resource
    273273   (&effective-request-uri;).
    274274</t>
    … …  
    20242024   The asterisk "*" character is used to group media types into ranges,
    20252025   with "*/*" indicating all media types and "type/*" indicating all
    2026    subtypes of that type. The media-range &MAY; include media type
     2026   subtypes of that type. The media-range can include media type
    20272027   parameters that are applicable to that range.
    20282028</t>
    20292029<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-range
    2034    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.
    20352035</t>
    20362036<x:note>
    … …  
    23742374  <x:anchor-alias value="Referer"/>
    23752375<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.
    23932381</t>
    23942382<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
    … …  
    23962384</artwork></figure>
    23972385<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>
    23982394   Example:
    23992395</t>
    … …  
    24022398</artwork></figure>
    24032399<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.
    24072428</t>
    24082429</section>
    … …  
    47604781<section title="Encoding Sensitive Information in URIs" anchor="encoding.sensitive.information.in.uris">
    47614782<t>
    4762    Because the source of a link might be private information or might
    4763    reveal an otherwise private information source, it is strongly
    4764    recommended that the user be able to select whether or not the
    4765    <x:ref>Referer</x:ref> field is sent. For example, a browser client could
    4766    have a toggle switch for browsing openly/anonymously, which would
    4767    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 a
    4772    (non-secure) HTTP request if the referring page was transferred with a secure
    4773    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"/>.
    47744795</t>
    47754796<t>
    … …  
    47774798   sensitive data because that data will be placed in the request-target. Many
    47784799   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 can
    4780    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.
    47814802</t>
    47824803</section>
    … …  
    48814902    <x:defines>Upgrade</x:defines>
    48824903    <x:defines>Via</x:defines>
     4904    <x:defines>effective request URI</x:defines>
     4905    <x:defines>target URI</x:defines>
    48834906  </x:source>
    48844907</reference>
Note: See TracChangeset for help on using the changeset viewer.