fetch with referrer from background page

1,430 views
Skip to first unread message

hrg...@gmail.com

unread,
Sep 6, 2021, 2:29:38 PM9/6/21
to Chromium Extensions
I'm trying to send an HTTP request with a referrer header, like this:

mode: 'cors',
credentials: 'include',
referrer: 'http://example.com',
referrerPolicy: 'unsafe-url'
})

I'm doing this from the background page in an extension with <all_urls> permission (MV2).

However, when I look into DevTool's network panel, I see that the request does not have a referrer header.

I can't find any documentation that explains this behavior.
According to MDN, the request must have the referrer I specified:

Does anybody know if the lack or referrer in this case is a documented limitation?




Cuyler Stuwe

unread,
Sep 6, 2021, 7:57:38 PM9/6/21
to hrg...@gmail.com, Chromium Extensions
You can't set the referrer header with the Fetch API.


Also, it's Referer, not Referrer -- It's a misspelling that stayed that way for backward compatibility.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d27a027f-f87e-4274-aa12-b273854a82c0n%40chromium.org.

Cuyler Stuwe

unread,
Sep 6, 2021, 8:00:48 PM9/6/21
to hrg...@gmail.com, Chromium Extensions
Or maybe I was wrong about referrer, and perhaps it was origin I was thinking of. 🤔

Anyway, either way, you need to misspell it in order to spell it correctly. Your code example doesn't have the correct misspelling,.

Cuyler Stuwe

unread,
Sep 6, 2021, 8:13:00 PM9/6/21
to hrg...@gmail.com, Chromium Extensions
Also, this inability to set the literal referrer (without elevated extension API assistance) is shared w/ Firefox, too.

Cuyler Stuwe

unread,
Sep 6, 2021, 8:39:30 PM9/6/21
to hrg...@gmail.com, Chromium Extensions
So. more specifically, you can change the referrer, but it has to be to something on the same origin you're on.

It uses relative conventions.

So if you're on "https://example.com/path" and you set the string to "cow", the referrer will become "https://example.com/path/cow".
If you instead set the string to "/cow", however, the referrer will become "https://example.com/cow".

This probably isn't the kind of behavior you're looking for from a background page (given that your base origin is "chrome-extension://[id]", and so the blocking webRequest API is probably still what you'll need.

Cuyler Stuwe

unread,
Sep 6, 2021, 8:43:04 PM9/6/21
to hrg...@gmail.com, Chromium Extensions
Oh, and the "correct" spelling (the way you have in your example) does actually work within fetch requests (within the limitations from my last reply), but you WILL need to change it to the correct "incorrect" spelling if you want to override the actual header via the webRequest API.

hrg...@gmail.com

unread,
Sep 7, 2021, 9:11:44 AM9/7/21
to Chromium Extensions, salem...@gmail.com, Chromium Extensions, hrg...@gmail.com
There's seems to be inconsistencies in the documentation.
The referrer parameter of the Request object doesn't say that the URL must be a "same-origin" URL.

Silly me for assuming the docs are correct.

Thanks for the help.

wOxxOm

unread,
Sep 7, 2021, 11:59:55 AM9/7/21
to Chromium Extensions, hrg...@gmail.com, salem...@gmail.com, Chromium Extensions

Cuyler Stuwe

unread,
Sep 7, 2021, 12:14:23 PM9/7/21
to wOxxOm, Chromium Extensions, hrg...@gmail.com
Looks like it was taken seriously, but then abandoned in the backlog.

It’ll probably end up being another victim of MV3.

hrg...@gmail.com

unread,
Sep 7, 2021, 1:03:49 PM9/7/21
to Chromium Extensions, salem...@gmail.com, Chromium Extensions, hrg...@gmail.com, wOxxOm
Yep, that feature request is the thing.
Unfortunately, it's likely that 10+ years go by until it's implemented.

Well... at least there's the blocking webRequest trick mentioned by salem... while we still have MV2, that it.
MV3 is going to make everything so much more difficult and tricky and full of cumbersome workarounds.... oh god, please help us.

hrg...@gmail.com

unread,
Sep 7, 2021, 5:11:46 PM9/7/21
to Chromium Extensions, hrg...@gmail.com, salem...@gmail.com, Chromium Extensions, wOxxOm
One last thing...

Does anybody know if adding the permissions "webRequest" and "webRequestBlocking" to an extension that already has "tabs" and "<all_urls>" will result in the extension being disabled for all users on the next package update?

When I run this, I get the exact same warnings as before:
chrome.management.getPermissionWarningsByManifest(`{"permissions": ["tabs", "<all_urls>", "webRequest", "webRequestBlocking"], "manifest_version":2, "name":"", "version":"1"}`, arr => console.log(arr))

I don't know how the CWS determines that an extension has new permissions.
Does it compare the new permissions array with the older one or does it compare the warnings array?

wOxxOm

unread,
Sep 8, 2021, 1:51:01 AM9/8/21
to Chromium Extensions, hrg...@gmail.com, salem...@gmail.com, Chromium Extensions, wOxxOm
These permissions don't have own warnings so they can be added safely. I did it once, at least. See also the source code: https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/extensions/permissions/chrome_permission_message_rules.cc

hrg...@gmail.com

unread,
Sep 8, 2021, 12:49:39 PM9/8/21
to Chromium Extensions, wOxxOm, hrg...@gmail.com, salem...@gmail.com, Chromium Extensions
Thanks for the info.

SoerenM

unread,
Sep 28, 2021, 5:31:36 PM9/28/21
to Chromium Extensions, hrg...@gmail.com, salem...@gmail.com, Chromium Extensions, wOxxOm
This is crazy, I have stumbled upon bug 992700 literally years ago when I ran into the problem of having to access a REST API that can only be used with the "correct" origin header - and after long trial/error/research the blocking webRequest header-change was the only workaround that did the trick.
I was recently wondering if this workaround was still needed, turns out years later absolutely nothing was done about it.. no fix.. no improvement... yeah its just uhm.. affecting basic forms of web communication?!
Of course this has now become one of the countless show stoppers/problems while trying to migrate to MV3 as it has for a lot of other people around here...

What about declarativeNetRequest? When I looked into it last year it didn't have all the header changing capabilities yet etc.
But I already have an eerie gut feeling that there is some horrible exception looming like a dark cloud.. that for some bizarre reason origin (and prob referer/referrer as well) headers can't be changed via that API? (at least not to what would make sense, lol)
Or has anybody here succeeded in doing so?

At this point it feels like some kind of survival reality show.. find the horrible hacky workaround of the week to make some basics work in MV3...
Reply all
Reply to author
Forward
0 new messages