Intent to Implement and Ship: RequestInit.referrer

43 views
Skip to first unread message

Yutaka Hirano

unread,
Sep 10, 2015, 8:28:34 AM9/10/15
to blink-dev

Contact emails

yhi...@chromium.org


Spec

https://fetch.spec.whatwg.org/

https://w3c.github.io/webappsec/specs/referrer-policy/


No TAG review, it is a small feature contained in the fetch spec.


Summary

Request.referrer already exists as a property, but currently it is set automatically to the client's outgoing referrer by the user agent. This feature enables users to set Request.referrer as a constructor argument.


If a request is captured by a service worker and a user call fetch() with the request, currently service worker's referrer (i.e. service worker's script url) is set to the outgoing request. With this feature request's original referrer will be used.


This intent to Ship does NOT include referrer policy setting via RequestInit.


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Demo link

None.


Compatibility Risk

In documents / dedicated workers / shared workers there are no compatibility issues. In service workers a captured request's referrer changes.



OWP launch tracking bug

https://crbug.com/514092


Entry on the feature dashboard

Fetch API

Jochen Eisinger

unread,
Sep 10, 2015, 8:31:37 AM9/10/15
to Yutaka Hirano, blink-dev, ann...@annevk.nl

Anne van Kesteren

unread,
Sep 10, 2015, 9:33:30 AM9/10/15
to Jochen Eisinger, Yutaka Hirano, blink-dev
On Thu, Sep 10, 2015 at 2:31 PM, Jochen Eisinger <joc...@chromium.org> wrote:
> +Anne van Kesteren
>
> LGTM

I can't, but same here. Some noteworthy bits about the design:

* You can set referrer to any same-origin URL. You can already
"polyfill" this with the help of pushState().
* Referrer can only be cross-origin if it already was cross-origin and
the request is not otherwise modified. This only applies to resources
fetched from ("cors") stylesheets.
* about:client is used as a special URL to set referrer to whatever is
appropriate for the environment settings object. (You could use this
to override stylesheet referrers, if you were so inclined. It's also
used as return value.)

I suspect we'll implement this in Firefox at some point too, though I
don't know any specific timelines. As Yutaka pointed out it's a
necessary feature for service workers so they don't break how
referrers work today.


--
https://annevankesteren.nl/

Chris Harrelson

unread,
Sep 10, 2015, 12:22:31 PM9/10/15
to Anne van Kesteren, Jochen Eisinger, Yutaka Hirano, blink-dev
LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Dimitri Glazkov

unread,
Sep 10, 2015, 12:23:23 PM9/10/15
to Chris Harrelson, Anne van Kesteren, Jochen Eisinger, Yutaka Hirano, blink-dev
LGTM3

:DG<

Matt Falkenhagen

unread,
Sep 11, 2015, 6:02:21 AM9/11/15
to Yutaka Hirano, blink-dev, ericbi...@chromium.org
^^^ Can you make a new chromestatus entry for this change? It makes it easier to track changes per milestone.

We have to do this until chromestatus gains per-milestone "changelist" support for features: https://github.com/GoogleChrome/chromium-dashboard/issues/218 (cc ericbidelman@: FYI)

Yutaka Hirano

unread,
Sep 11, 2015, 7:32:54 AM9/11/15
to Matt Falkenhagen, blink-dev, ericbi...@chromium.org
Reply all
Reply to author
Forward
0 new messages