Add "referrer" to fetch request used in navigation #22890

gterzian · 2019-02-14T10:47:10Z

It seems that the spec is moving towards integration of navigation with Fetch, as exemplified by the aptly named process a navigate fetch and process a navigate response.

For example:

Step 12 of following-hyperlinks now refers not to a "resource", but to a fetch "request".
Navigate now also uses the concept of a request.
Window.open now also refers to a "request" in step 14.

Our implementation of follow-hyperlink, window.open and navigate all use window.load_url, as entry point, which sends a message to the script-thread handled in handle_navigate, which results in "parallel" steps being processes in the constellation. This "load url" algorithm is, as currently implemented, not integrated with our implementation of fetch, which lives somewhere around https://github.com/servo/servo/tree/65370f17c98225f7e71c72ea2e0cb2d0a81487f3/components/net/fetch.

There is already some plumbing to integrate the constellation with fetch, in the form of https://github.com/servo/servo/blob/master/components/constellation/network_listener.rs, which might be re-used to deal with "load_url" as well...

jdm · 2019-02-27T17:18:01Z

I'm not sure I understand what's being proposed here. The constellation is in charge of starting fetch requests for document navigations based on the script thread sending an InitiateNavigateRequest message, so it's not clear what we should be doing differently.

gterzian · 2019-02-28T06:47:53Z

I'm not completely sure myself, and it appeared to me that although there is perhaps a fetch request somewhere deep inside the navigation of a document, we could expose it more clearly in the script code.

For example, I don't think we have a way to do If subject's link types includes the noreferrer keyword, then set request's referrer to "no-referrer". Step 13 of https://html.spec.whatwg.org/#following-hyperlinks-2

Same with 14.3 of https://html.spec.whatwg.org/#window-open-steps

Those two examples I think would be relevant to comply with Step 7 of https://fetch.spec.whatwg.org/#concept-main-fetch

So the answer would be "expose the fetch request(or at least more of its configuration) for the navigation to script"? That's actually much simpler than what I sketched above...

jdm · 2019-02-28T14:26:36Z

Right, we should expose any required configuration as part of the InitiateNavigateRequest message, and make sure that configuration is passed along any intermediate messages.

gterzian · 2019-03-01T03:33:34Z

Removed the "interesting-project", since this turns out to be a much smaller change than I thought, doesn't mean it's not interesting though!

miller-time · 2019-03-21T03:28:56Z

@highfive assign me

highfive · 2019-03-21T03:28:57Z

Hey @miller-time! Thanks for your interest in working on this issue. It's now assigned to you!

miller-time · 2019-03-23T19:12:03Z

@gterzian (or maybe @jdm) any pointers to help me get started on this? I'm reading the methods that were mentioned above, but it's not entirely clear to me what needs to be changed.

It looks like the numbered steps (in comments) for window.open seem to be pretty outdated, so I could start there.

gterzian · 2019-03-25T03:41:25Z

@miller-time Thanks for working on this one!

Re the numbering, we've actually just merged #23011 which already improved the situation, and I suggest you rebase off the last master as a starting point(and note that the links to the code above in this issue will link to a older version of the codebase).

The idea is that we want to add https://fetch.spec.whatwg.org/#concept-request-referrer to the various places in the code where we navigate using window.load_url.

Currently load_url doesn't take a referrer argument, and neither does it pass it along to the "fetch" code actually doing the loading of the page that is being navigated to.

I think the first step would be to add an argument representing referrer to window.load_url and do Step 14.3 of https://html.spec.whatwg.org/#window-open-steps as well as Step 13 of https://html.spec.whatwg.org/#following-hyperlinks-2

Then you could take it further by taking a look at the various places where referrer is used, and see if we are currently implementing those already and if so explore whether we can pass this new referrer info along to that piece of code and improve compliance with the spec.

You might want to focus on a few low hanging fruits first, and perhaps open issues for things that could be best done separately.

To see the various places where referrer is used in the spec, you can click on the name in bold in the spec, which will give you a list of links to other places in the spec.

Note that this is the "fetch" spec, which is separate from the "html" spec, and fetch is mostly implemented in https://github.com/servo/servo/tree/master/components/net
and to understand how something would travel from window.load_url to fetch, you'de have to follow the message send to the constellation and see how the handling of that message results in starting a fetch.

miller-time · 2019-03-25T06:28:07Z

@gterzian thanks for the additional tips!

I opened a draft PR, I hope that's okay... thought it might be helpful to see where I'm going.

Then you could take it further by taking a look at the various places where referrer is used, and see if we are currently implementing those already and if so explore whether we can pass this new referrer info along to that piece of code and improve compliance with the spec.

Note that this is the "fetch" spec, which is separate from the "html" spec, and fetch is mostly implemented in https://github.com/servo/servo/tree/master/components/net
and to understand how something would travel from window.load_url to fetch, you'de have to follow the message send to the constellation and see how the handling of that message results in starting a fetch.

I looked at InitiateNavigateRequest, per advice of @jdm, and saw that in constellation we handle that message, which passes a req_init (RequestInit).

In Request.from_init we do the following:

req.referrer = if let Some(url) = init.referrer_url {
    Referrer::ReferrerUrl(url)
} else {
    Referrer::NoReferrer
};

So I think that will need to be changed as part of my efforts.

I skimmed the definition of window.load_url and came across a MainThreadScriptMsg::Navigate message that is sent, which passes a LoadData struct. I might be able to add referrer to that. I tried to follow that message's usage, but I got to a scheduler and wasn't sure what happens next.

I was hoping that the MainThreadScriptMsg::Navigate message results in a ScriptMsg::InitiateNavigateRequest message being sent eventually. If so, then this all ties together there.

There are a lot of other uses of RequestInit, and I feel like I'm still missing... a lot.

To see the various places where referrer is used in the spec, you can click on the name in bold in the spec, which will give you a list of links to other places in the spec.

That's good to know! I'll definitely do that next.

gterzian · 2019-03-25T08:14:18Z

Ok, sounds like you're going in the right direction.

The MainThreadScriptMsg::Navigate msg sent by load_url is received here:

servo/components/script/script_thread.rs

Line 1743 in 7a67443

self.handle_navigate(parent_pipeline_id, None, load_data, replace)

and handled as part of

servo/components/script/script_thread.rs

Line 3198 in 7a67443

fn handle_navigate(

There is actually another roundtrip happening before the InitiateNavigation message is sent, in the form of the ScriptMsg::LoadUrl, which will result in first the navigation being "scheduled", awaiting approval from the embedder.

servo/components/constellation/constellation.rs

Line 2205 in 7a67443

fn schedule_navigation(

It is approved via a message from the embedder received at

servo/components/constellation/constellation.rs

Line 1064 in 7a67443

FromCompositorMsg::AllowNavigationResponse(pipeline_id, allowed) => {

which will result in load_url being called, and when a new pipeline is created this will end up in the InitiateNavigateRequest being sent.

So there is actually quite a bit of back and forth between the initial window.load_url and the ultimate sending of a InitiateNavigateRequest message from being sent.

The question is whether the referrer should be sent along at each step, or whether it should be stored somewhere along the way. I think LoadData is, as you suggested, probably a good place to store it, and then use it to create the RequestInit...

miller-time · 2019-03-26T02:39:24Z

Thanks @gterzian

I updated my PR - got it to build, cleaned it up. Tests pass and I haven't touched them yet... Is that good or bad?

I've been browsing the fetch spec...

In the Request class, there is some mention of different values for referrer:

Returns the referrer of request. Its value can be a same-origin URL if explicitly set in init, the empty string to indicate no referrer, and "about:client" when defaulting to the global’s default. This is used during fetching to determine the value of the Referer header of the request being made.

I can only find one occurrence of "about:client":

servo/components/script/dom/request.rs

Line 554 in 25aa650

fn Referrer(&self) -> USVString {

Side note: should the branch NoReferrer => String::from("no-referrer") be changed to return String::from("")?

The main_fetch is a little sparse, and has a TODO for handling the client's referrer policy:

servo/components/net/fetch/methods.rs

Line 142 in 7a67443

pub fn main_fetch(

Per the spec it looks like I could do some work there.

In http_network_or_cache_fetch:

servo/components/net/http_loader.rs

Line 774 in 25aa650

fn http_network_or_cache_fetch(

It looks like referrer is being handled correctly, though the numbering in comments seems slightly out-of-date per the spec. Should I try to update that?

In cors_preflight_fetch:

servo/components/net/http_loader.rs

Line 1359 in 25aa650

fn cors_preflight_fetch(

It looks like we're correctly copying the referrer from the request. 🎉

I'm not sure where to look for the implementation of the WebSocket opening handshake...

I found several TODO comments when I added an Option<Referrer> to LoadData:

servo/components/constellation/constellation.rs

Line 1951 in 25aa650

// TODO - loaddata here should have referrer info (not None, None)

servo/components/constellation/constellation.rs

Line 2033 in 25aa650

// TODO: Referrer?

servo/components/constellation/constellation.rs

Line 2095 in 25aa650

// TODO: Referrer?

I could use some guidance in case those should have logic for determining referrer... (on my branch, I have it set to None in all of those places).

One last question...

Should existing references to RequestInit.referrer_url (which is Option<ServoUrl>) be migrated to RequestInit.referrer as Referrer::ReferrerUrl(ServoUrl) and RequestInit.referrer_url removed?

gterzian · 2019-03-26T03:59:28Z

Thanks for all the research!

Note that servo/components/script/dom/request.rs is the DOM interface to a fetch request, so it's basically the DOM api to some of the things that are done "internally" as part of navigation that follows window.load_url. Thanks for pointing out that one, I actually wasn't aware of it yet.

Side note: should the branch NoReferrer => String::from("no-referrer") be changed to return String::from("")?

The spec seems to indeed point in that direction. Good catch!

I think the enum that is quite important for your work is this one:

servo/components/net_traits/request.rs

Line 65 in 25aa650

pub enum Referrer {

It is used in the fetch code, as well as in the DOM request.

Currently it looks like the referrer is set based on the referrer_url at

servo/components/net_traits/request.rs

Line 315 in 25aa650

req.referrer = if let Some(url) = init.referrer_url {

Should existing references to RequestInit.referrer_url (which is Option) be migrated to RequestInit.referrer as Referrer::ReferrerUrl(ServoUrl) and RequestInit.referrer_url removed?

Yes you might want to try that and see what other parts of the code are using it and it if it can be changes relatively easily. It would seem to make sense to just do everything with the referrer.

though the numbering in comments seems slightly out-of-date per the spec. Should I try to update that?

Yes that's a good idea. You could try to separate it from the referrer work either by commit or by PR. I think that just adding a separate commit to the PR should be fine.

For the websocket I think you will have to look at

servo/components/script/dom/websocket.rs

Line 145 in 25aa650

pub fn Constructor(

Note that the spec seems to say that the referrer should be no-referrer by default.

Re the TODO's in the constellation that you've found:

servo/components/constellation/constellation.rs

Line 2081 in 25aa650

fn handle_script_new_auxiliary(

This relates to Step 14.3 of https://html.spec.whatwg.org/multipage/window-object.html#window-open-steps
The two others relate to navigating and/or creating a iframe that is initially "about:blank", those operations originate at

servo/components/script/dom/htmliframeelement.rs

Line 176 in 25aa650

match nav_type {

instead of window.load_url for "normal" navigation. It's worth looking into plugging the refferer into two workflows as well, and it might be something best done in a follow-up.

I updated my PR - got it to build, cleaned it up. Tests pass and I haven't touched them yet... Is that good or bad?

I think we should expect some tests to unexpectedly go from FAIL to PASS(unless the metadata was also updated), and we can look into that. Have you opened the PR on here already?

miller-time · 2019-03-26T04:42:18Z

Yep, sorry I thought you had seen it auto linked by GH

#23090

miller-time · 2019-03-30T23:38:35Z

Updates

Should existing references to RequestInit.referrer_url (which is Option) be migrated to RequestInit.referrer as Referrer::ReferrerUrl(ServoUrl) and RequestInit.referrer_url removed?

Yes you might want to try that and see what other parts of the code are using it and it if it can be changes relatively easily. It would seem to make sense to just do everything with the referrer.

done!

Side note: should the branch NoReferrer => String::from("no-referrer") be changed to return String::from("")?

The spec seems to indeed point in that direction. Good catch!

fixed!

though the numbering in comments seems slightly out-of-date per the spec. Should I try to update that?

Yes that's a good idea. You could try to separate it from the referrer work either by commit or by PR. I think that just adding a separate commit to the PR should be fine.

fixed!

Note that the spec seems to say that the referrer should be no-referrer by default.

done (I think)

The last thing I wanted to do before requesting a review of the PR is:

The main_fetch is a little sparse, and has a TODO for handling the client's referrer policy:

servo/components/net/fetch/methods.rs

Line 142 in 7a67443

pub fn main_fetch(

Per the spec it looks like I could do some work there.

I still haven't updated any tests... or seen any test failures...

miller-time · 2019-03-31T00:00:23Z

By the way, figuring out exactly how the steps have changed in the spec for http_network_or_cache_fetch was a fun exercise. I tracked down d919f55 which told me roughly when a lot of that numbering had been written (~2 years ago), which I used to line up commit timestamps with whatwg/fetch@cbca2c2 (my main clue that things were significantly out of date was that the referrer has been handled in step 9 for a long time, but the comment was // Step 10). I cloned that repo and opened fetch.bs in my browser so I could see which steps the comments were referencing (with numbers instead of just <li> tags).

miller-time · 2019-03-31T00:10:44Z

Hmm in looking at main_fetch again:

servo/components/net/fetch/methods.rs

Line 185 in e98db92

request.referrer_policy = request

...I'm not sure if it makes sense to change anything in this PR.

gterzian · 2019-04-02T07:05:14Z

Thanks for the work!

Just looking at fetch/method, I saw this FIXME at

servo/components/net/fetch/methods.rs

Line 194 in fe07d2c

// FIXME(#14507): We should never get this value here; it should

which points to this issue #14507

it's interesting because it would appear that in the case of Referrer::Client we might actually need to do some additional processing inside script and set it either to noreferrer or a url before sending it on to net(fetch)...

I'm still looking at the overall PR and haven't had a chance to review everything, and I can't suggest exactly what to do re the above. I'll keep looking into over the next couple of days, and perhaps you can too when you have a chance?

Re the tests, it might actually be that there are no tests yet for this specifically, we'll have to look into it a bit more as well...

miller-time · 2019-04-03T01:59:22Z

which points to this issue #14507

nice! that issue links to the exact same part of the spec that I mentioned in a previous comment. I hadn't paid close enough attention to that comment and noticed that there was a separate issue to handle that.

I'll start to poke around in the tests, but I'm actually not familiar with them at all... Any pointers for where to look?

miller-time · 2019-04-03T17:28:58Z

I tried running ./mach test-wpt --release and then ./mach update-wpt and it produced a lot of changes, including a lot of new failures. So I might need to investigate those further. For some reason I thought CI runs those tests, but it looks like it only runs ./mach test-unit

gterzian · 2019-04-04T08:38:05Z

Re the tests, I think we can find relevant ones in https://github.com/servo/servo/tree/ab5a57fadf649ede43ae3f478be6df9bfa69893a/tests/wpt/web-platform-tests/referrer-policy

Re running the tests, when you run the whole suite locally you usually get a lot of timeout errors, so it's best to target a specific folder, or a single test.

I'll run the suite on your PR via a dedicated command, to give us an indication if anything changed or not. Note that even then there can be quite a few unrelated failures occurring intermittently.


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)

miller-time · 2019-04-05T05:37:57Z

@gterzian thanks! I'm starting to drill into these wpt tests. I think I found one unexpected passing test already. I found a failing test, but when I checked out master and ran:

./mach build --release
./mach test-wpt --release tests/wpt/web-platform-tests/referrer-policy/no-referrer-when-downgrade/attr-referrer/cross-origin/http-http/iframe-tag/keep-origin-redirect/insecure-protocol.http.html

...it failed there too. Just to make sure I'm on the right track... I assume I should at least run update-wpt on the one that is now passing; should I also update the one that's failing on master?

gterzian · 2019-04-05T09:09:06Z

So locally if you run a single test, you'll see the result, but not whether it's unexpected or not. However when you run say ./mach test-wpt --release tests/wpt/web-platform-tests/referrer-policy/, it will tell you what is expected or unexpected.

So for example the one that you found that is failing on master is probably expected to fail(you'll know if you run the entire folder).

From the CI run it looks like some tests went from PASS to FAIL, in the refferer-policy folder, while I can also see a few going from FAIL to PASS. Looks like most failure related to the referrer being undefined. It's a good idea to look into the failure first, might be just a small unexpected change somewhere...

See https://build.servo.org/builders/linux-rel-css/builds/11899/steps/shell__4/logs/filtered-wpt-errorsummary.log

It might also tie in with what's going on in main fetch, since now None as referrer in LoadData will result in a Referrer::Client in fetch, and that's not hitting the determine_request_referrer, while the spec reads "If request’s referrer is not "no-referrer", set request’s referrer to the result of invoking determine request’s referrer.", which would seem to imply that it should be done in the Referrer::Client as well(altough the fixme says this should never hit so maybe we should not be setting referrer to None and unwrapping that into a Referrer::Client as a default).

servo/components/net/fetch/methods.rs

Line 193 in fe07d2c

Referrer::Client => {

jdm · 2019-04-05T11:47:05Z

Running a single test does tell you whether it's unexpected or not. It just may not be clear if it's passing or not from the output, but that's separate from expected/unexpected.

miller-time · 2019-04-08T05:49:58Z

I tried changing the default from Referrer::Client to Referrer::NoReferrer.

$ ./mach test-wpt --release tests/wpt/web-platform-tests/referrer-policy/
...
234 tests had unexpected subtest results

Note: I switched to master again and ran ./mach build --release and ran those referrer-policy tests, and they all ran as expected. So I guess I need to keep trying to figure these out.

Sorry I haven't made much progress on this, I'll keep digging. Should I ping anyone on the pull request? To get any additional feedback, etc. Or do I need to finish up these wpt tests before the review? Just curious (this is only my second one).

gterzian · 2019-04-08T07:59:37Z

Yep so it's the failures that are part of 234 tests had unexpected subtest results that would need looking into(and indeed running the tests on master should not have unexpected test results, bar perhaps a few intermittents).

It is indeed better to try to first find out what is causing the unexpected test failures, before asking for a review.

I can suggest picking a test that currently unexpectedly fails with expected (string) ... but got (undefined) undefined(for example /referrer-policy/no-referrer-when-downgrade/meta-referrer/same-origin/http-https/iframe-tag/swap-origin-redirect/upgrade-protocol.http.html, and many others that seem to fail in the same way), and then adding print statements for the state of the referrer in the rust code around the changes you made and perhaps a few console.log in the JS(to get a sense of how what goes in the rust part relates to how the JS test is running), and trying to understand what is going on. If you run a single test you can see both the rust print and the js console output(I think it's not shown when you run more than one test).

Even though a lot of tests are failing unexpectedly, I suspect they all fail for the same reason and it could be a fairly easy fix that will become obvious once you've printed out the various state of the referrer at various points up to the failure of the test...

It might also be a slightly more complicated fix involving plugging your work in with the iframe navigations(a lot of tests seem to involve an iframe) and ensuring the new referrer field in LoadData is not always None as a default.

jdm · 2019-04-08T18:25:59Z

It may be easier to write your own manual tests first, using a script like this to print out the received referrer. This should be easier to determine if the problem lies in providing an accurate referrer, or if the problem lies in the code that acts on the requested referrer policy.

miller-time · 2019-04-13T00:41:59Z

So it turns out that having a bunch of small commits ended up being very helpful. By running the tests after each commit I discovered that ebb2ddf introduced all of the failures. I mishandled a lot of uses of LoadData that had a referrer_url set. I added a None referrer in several places and caused referrer_url to no longer be used. After fixing this, all of the referrer wpt tests passed!


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)

miller-time · 2019-04-15T01:54:56Z

I've been looking into those last 3 failing tests.

When I changed this line the referrer changed from Some(Referrer::ReferrerUrl(doc.url())) to None.

In the test

/html/browsers/history/the-history-interface/009.html

it appears that Window::load_url was called from SetHref (location.rs), which passes None for referrer.

servo/components/script/dom/location.rs

Line 171 in 7726453

self.window.load_url(url, false, false, None, None);

I think I have 2 options to fix this test:

In Window::load_url, pass Some(Referrer::ReferrerUrl(doc.url())) if referrer is None
Pass a referrer from the caller (location.rs)

I've poked a bit in the spec for location:

If request is non-null, then set document's referrer to the serialization of request's referrer, if request's referrer is a URL record, and the empty string otherwise.
Note: Per Fetch a request's referrer will be either a URL record or "no-referrer" at this point.

It's not clear to me how we would add a referrer in SetHref (location.rs), so for now I'm going with option (a) above.

All tests should pass now.


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=<try>

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=gterzian

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=gterzian

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)


        Auto merge of #23090 - miller-time:nav-fetch-referrer, r=gterzian

Add referrer to navigation fetch request  Implement step 13 of [following hyperlinks](https://html.spec.whatwg.org/#following-hyperlinks-2) and step 14.3 of [window open](https://html.spec.whatwg.org/#window-open-steps), as well as other referrer- and fetch-related updates. ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #22890 (GitHub issue number if applicable)  - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23090)

gterzian added B-interesting-project A-network A-content/script A-constellation labels Feb 14, 2019

gterzian changed the title ~~Integrate navigation, following hyperlink, more closely with Fetch(spec changes)~~ Integrate navigation with Fetch(spec changes) Feb 14, 2019

gterzian changed the title ~~Integrate navigation with Fetch(spec changes)~~ Integrate Navigation with Fetch(spec changes) Feb 14, 2019

gterzian removed the B-interesting-project label Mar 1, 2019

gterzian changed the title ~~Integrate Navigation with Fetch(spec changes)~~ Add "referrer" to fetch request used in navigation Mar 1, 2019

gterzian added the E-less easy label Mar 1, 2019

gterzian mentioned this issue Mar 15, 2019

Add tokenizer for features in window.open #23011

Merged

4 of 5 tasks complete

highfive added the C-assigned label Mar 21, 2019

gterzian added the B-interesting-project label Mar 25, 2019

miller-time mentioned this issue Mar 25, 2019

Add referrer to navigation fetch request #23090

Merged

3 of 5 tasks complete

bors-servo closed this in #23090 Apr 26, 2019

servo / servo

Add "referrer" to fetch request used in navigation #22890

Add "referrer" to fetch request used in navigation #22890

gterzian commented Feb 14, 2019 •

edited

jdm commented Feb 27, 2019

gterzian commented Feb 28, 2019 •

edited

jdm commented Feb 28, 2019

gterzian commented Mar 1, 2019

miller-time commented Mar 21, 2019

highfive commented Mar 21, 2019

miller-time commented Mar 23, 2019

gterzian commented Mar 25, 2019 •

edited

miller-time commented Mar 25, 2019

gterzian commented Mar 25, 2019 •

edited

miller-time commented Mar 26, 2019 •

edited

gterzian commented Mar 26, 2019 •

edited

miller-time commented Mar 26, 2019

miller-time commented Mar 30, 2019

miller-time commented Mar 31, 2019

miller-time commented Mar 31, 2019

gterzian commented Apr 2, 2019

miller-time commented Apr 3, 2019

miller-time commented Apr 3, 2019

gterzian commented Apr 4, 2019

miller-time commented Apr 5, 2019

gterzian commented Apr 5, 2019 •

edited

jdm commented Apr 5, 2019 •

edited

miller-time commented Apr 8, 2019 •

edited

gterzian commented Apr 8, 2019 •

edited

jdm commented Apr 8, 2019

miller-time commented Apr 13, 2019

miller-time commented Apr 15, 2019

servo / servo

Join GitHub today

Add "referrer" to fetch request used in navigation #22890

Add "referrer" to fetch request used in navigation #22890

Comments

gterzian commented Feb 14, 2019 • edited

jdm commented Feb 27, 2019

gterzian commented Feb 28, 2019 • edited

jdm commented Feb 28, 2019

gterzian commented Mar 1, 2019

miller-time commented Mar 21, 2019

highfive commented Mar 21, 2019

miller-time commented Mar 23, 2019

gterzian commented Mar 25, 2019 • edited

miller-time commented Mar 25, 2019

gterzian commented Mar 25, 2019 • edited

miller-time commented Mar 26, 2019 • edited

gterzian commented Mar 26, 2019 • edited

miller-time commented Mar 26, 2019

miller-time commented Mar 30, 2019

miller-time commented Mar 31, 2019

miller-time commented Mar 31, 2019

gterzian commented Apr 2, 2019

miller-time commented Apr 3, 2019

miller-time commented Apr 3, 2019

gterzian commented Apr 4, 2019

miller-time commented Apr 5, 2019

gterzian commented Apr 5, 2019 • edited

jdm commented Apr 5, 2019 • edited

miller-time commented Apr 8, 2019 • edited

gterzian commented Apr 8, 2019 • edited

jdm commented Apr 8, 2019

miller-time commented Apr 13, 2019

miller-time commented Apr 15, 2019

gterzian commented Feb 14, 2019 •

edited

gterzian commented Feb 28, 2019 •

edited

gterzian commented Mar 25, 2019 •

edited

gterzian commented Mar 25, 2019 •

edited

miller-time commented Mar 26, 2019 •

edited

gterzian commented Mar 26, 2019 •

edited

gterzian commented Apr 5, 2019 •

edited

jdm commented Apr 5, 2019 •

edited

miller-time commented Apr 8, 2019 •

edited

gterzian commented Apr 8, 2019 •

edited