[whatwg] Feedback on Meta referrer
w3c at adambarth.com
Sat Dec 31 10:11:53 PST 2011
On Sat, Dec 31, 2011 at 9:44 AM, David Bruant <bruant.d at gmail.com> wrote:
> My feedback regards the current version of the wiki page .
> I'm curious about why a Referer header is always sent. Specifically for
> "never", an empty string is sent. Why not just not send the header at
Oh, the intent is for the header not to be sent for "never". Does
this happen in the WebKit implementation, or is this only a problem in
> That's what is specified for @rel=noreferrer  for instance:
> "If a user agent follows a link defined by an a or area element that has
> the noreferrer keyword, the user agent must not include a Referer (sic)
> HTTP header (or equivalent for other protocols) in the request."
> It is not said that the empty string is sent, but that the user agent
> must not include a Referer header at all.
> Moreover, I don't really know what a server would do more with an empty
> Referer header as opposed to no header at all, so I don't see a use for
> an empty referer.
> Another concern is what should happen if a request is sent before
> finding a meta referrer. For instance:
> <link rel="stylesheet" href="a.css">
> <meta name="referrer" content="never">
> In what conditions should the request for the css file be done? Ignore
> the meta tag? Wait until the end of <head> in case there would be a meta
The policy for a given network fetch is determined when the fetch is
made. In this case, the request for a.css will include the Referer
header. If you move the <meta> tag above the <link> tag, then the
request will not include the Referer header.
> "TODO: This algorithm causes the most recently added meta element to
> control the referrer-policy. Should we support changing the policy by
> setting the content attribute? "
> => I think that allowing to change the policy by setting the content
> attribute would be a good idea, but a question can arise regarding what
> happens if there are several such <meta> elements in the document.
Yeah. Is there some precedent we should look to here? Perhaps the
> "How does this interact with rel=noreferrer? Presumably rel=noreferrer
> should override whatever global setting the user agent gets from the
> meta element. "
> => I agree that the specific should override the global.
> Also, it seems to me that 2 different concerns are implicitely
> addressed: "when should the referer header be sent?" and "what should be
> sent in the referer header?" It could make sense to split up the
> proposal in 2 keywords.
> One controling when the header is sent:
> * never
> * same origin (send the referer header if the target URL and document
> URLs have the same origin)
> * defaut (secure referer & not secure fetched)
> * always
> * (...)
> another controling what is sent:
> * empty string (if there is really a use case for this)
I'm not there is a use case for the empty string.
> * origin-only
> * fragmentless URL
> * (...)
> Current policies can be expressed as the combinaisons of the above:
> * "never" => default + empty string
> * "default" => default + fragmentless URL
> * "origin" => default + origin-only
> * "always" => always + fragmentless URL
The intended mapping is more like the following:
* "never" => never + N/A
* "default" => default + fragmentless URL
* "origin" => always + origin-only
* "always" => always + fragmentless URL
Are there use cases for the other combinations? For example, why
would someone want to use default+origin-only rather than
Thanks for the feedback,
More information about the whatwg