fetch with referrer from background page

[hrg...@gmail.com]

I'm trying to send an HTTP request with a referrer header, like this:

fetch('http://example.com', {

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:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

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

[Cuyler Stuwe]

You can't set the referrer header with the Fetch API.

However, within an MV2 Chrome extension, you can set it with the blocking variant of the webRequest API (as long as you provide the "extraHeaders" flag).

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]

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]

Also, this inability to set the literal referrer (without elevated extension API assistance) is shared w/ Firefox, too.

[Cuyler Stuwe]

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]

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]

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]

Sounds like https://crbug.com/992700

[Cuyler Stuwe]

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]

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]

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]

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]

Thanks for the info.

[SoerenM]

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...