[whatwg] Feedback on Meta referrer

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:
> Hi,
>
> My feedback regards the current version of the wiki page [1].
>
> 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
> all?

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
the spec?

> That's what is specified for @rel=noreferrer [2] 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:
> <head>
>    <link rel="stylesheet" href="a.css">
>    <meta name="referrer" content="never">
> </head>
> 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
> element?

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
<base> element?

> "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
always+origin-only?

Thanks for the feedback,
Adam