This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26058 - "noreferrer" support in Fetch.
Summary: "noreferrer" support in Fetch.
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: Fetch (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+fetchspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-11 14:07 UTC by Mike West
Modified: 2014-06-13 09:44 UTC (History)
1 user (show)

See Also:


Attachments

Description Mike West 2014-06-11 14:07:51 UTC
I'd suggest adding a "noreferrer" flag (or something similar) to Request objects in Fetch so that we can properly model the behavior of `<a rel="noreferrer" href="https://example.com/"></a>`. It should suppress the referrer header, and probably needs to be propagated to the Response object in order to properly suppress the `opener` DOM property.

WDYT?
Comment 1 Anne 2014-06-11 14:18:38 UTC
I was thinking this would be setting referrer to null, but I guess that would conflicts with the idea of getting it of the client instead.

Maybe referrer should be "none", "client", or a URL?

Since the navigate algorithm sets referrer it should be able to keep track of that state for the browsing context it is about to create. Not sure why we need to keep track of that state in the "network" layer.
Comment 2 Mike West 2014-06-11 14:22:27 UTC
I think I'd suggest that `noreferrer` override the default referrer policy of an environment. That is, `noreferrer` means an empty referrer header, even in the context of a page that set `<meta name="referrer" value="always">`.

Whether or not we need to push this data into Fetch depends to some extent on whether or not ServiceWorkers should be able to force this behavior for links that didn't opt-in in the markup.
Comment 3 Anne 2014-06-11 14:35:47 UTC
(In reply to Mike West from comment #2)
> I think I'd suggest that `noreferrer` override the default referrer policy
> of an environment. That is, `noreferrer` means an empty referrer header,
> even in the context of a page that set `<meta name="referrer"
> value="always">`.

If referrer is set to "none" we can just skip that policy check. Seems fine.


> Whether or not we need to push this data into Fetch depends to some extent
> on whether or not ServiceWorkers should be able to force this behavior for
> links that didn't opt-in in the markup.

Currently the Request API does not provide referrer control (SW can still use default() to get the behavior). Giving control over that and opener (maybe separately) seems interesting. Maybe v2 features (e.g. once we have something shipping)?
Comment 4 Mike West 2014-06-11 15:01:29 UTC
(In reply to Anne from comment #3)
> (In reply to Mike West from comment #2)
> > I think I'd suggest that `noreferrer` override the default referrer policy
> > of an environment. That is, `noreferrer` means an empty referrer header,
> > even in the context of a page that set `<meta name="referrer"
> > value="always">`.
> 
> If referrer is set to "none" we can just skip that policy check. Seems fine.

Maybe I'm misunderstanding what the referrer property is supposed to be. I understood it to be either a global environment or null. Are you suggesting something else, or that we interpret "null" to mean "noreferrer"?

> Currently the Request API does not provide referrer control (SW can still
> use default() to get the behavior). Giving control over that and opener
> (maybe separately) seems interesting. Maybe v2 features (e.g. once we have
> something shipping)?

I guess I'm curious about the interaction between the page's specified referrer policy (you'll have a doc to review in a day or three, until then just pretend that the <meta referrer> wiki page is more complete and integrated with Fetch) and the work that a SW does on its behalf.

Agree that punting the specific 'noreferrer' behavior until later is perfectly reasonable.
Comment 5 Anne 2014-06-11 15:12:11 UTC
I gave a new idea of what referrer could be in comment 1.

That is, specifications set request's referrer to "none", "client", or a URL. It defaults to "client" if it is not set.

Then in Fetch's concept-fetch:

* If request's referrer is "client", I extract a URL from request's client and set request's referrer to that value.
* If request's referrer is not "none", pass it to "referrer policy spec" for adjustment.

Then, going forward, in service workers a Request object could have a referrer property that reflects the adjusted URL (or simply returns the empty string). And we can support a omitReferrer boolean member in RequestInit to achieve request's referrer being "none" for fetch().
Comment 6 Mike West 2014-06-12 07:38:24 UTC
(In reply to Anne from comment #5)
> I gave a new idea of what referrer could be in comment 1.
> 
> That is, specifications set request's referrer to "none", "client", or a
> URL. It defaults to "client" if it is not set.
> 
> Then in Fetch's concept-fetch:
> 
> * If request's referrer is "client", I extract a URL from request's client
> and set request's referrer to that value.
> * If request's referrer is not "none", pass it to "referrer policy spec" for
> adjustment.
> 
> Then, going forward, in service workers a Request object could have a
> referrer property that reflects the adjusted URL (or simply returns the
> empty string). And we can support a omitReferrer boolean member in
> RequestInit to achieve request's referrer being "none" for fetch().

Got it.

I think this makes sense, and I'll update the referrer spec accordingly. Should I send a pull request for Fetch, or would you like to take care of that side yourself?
Comment 7 Anne 2014-06-12 09:39:14 UTC
https://github.com/whatwg/fetch/commit/8ab38bf62ace6c221c544add7cc188c799d6acc7

I still need to make it actually set the Referer header on the network. That's for later.
Comment 8 Mike West 2014-06-12 09:46:40 UTC
So, what's the right split between referrerpolicy and Fetch?

I wrote http://w3c.github.io/webappsec/specs/referrer-policy/#set-request-referrer to actually set the header (and do the right stripping of values and etc). It seems like that logic should be in referrerpolicy, but it's not clear to me what you'd like to be invoking and where.
Comment 9 Anne 2014-06-12 09:57:39 UTC
http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0154.html has my proposal. I don't want to set the header before this goes to the network or cache. That makes things harder with respect to CORS header checks / CORS cache header checks and whether service workers can influence it or not.