1781258 - Using Service Worker fetch API to add Authorization header but it does not show in Devtools request

Status: RESOLVED DUPLICATE of bug 1432311

(DevTools :: Netmonitor, defect, P3)

Description

[ewolfman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Used ServiceWorker to provide a fetch that uses Authorization header.

Actual results:

The Authorization header gets passed to server (good), but it does not show up in the Devtools->Network request's headers as can be seen here:

GET /files/78b09742-4748-47b0-8502-936fe2ca1c4a HTTP/1.1
Host: <masked>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: audio/webm,audio/ogg,audio/wav,audio/;q=0.9,application/ogg;q=0.7,video/;q=0.6,/;q=0.5
Accept-Language: en-US,en-GB;q=0.8,en;q=0.6,fr-FR;q=0.4,ja;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: http://localhost:8080/
Sec-Fetch-Dest: audio
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Range: bytes=0-
Connection: keep-alive

Expected results:

The Authorization header should be visible in the Devtools->Network request's headers

Comment 1

[ewolfman]

Forgot to mention that in Chrome it does work and I do see the Authorization header.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Netmonitor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue with firefox 105.0a1 (2022-08-22) on Windows 10 and Ubuntu 22.04 unfortunately I wasn't able to reproduce the issue on my end. Could you please answer the following questions in order to further investigate this issue.

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed if so can you list them?

Comment 5

[ewolfman]

Hi,
Thanks for looking into this.

1. Yes
2. Yes (105b4)
3. The new profile I created for this test has no addons. I also restarted with Addons-Disabled and it does not work.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Negritas Sergiu: were you able to reproduce the issue on your machine? Did the answers in comment #5 help?

Comment 7

[Negritas Sergiu, Desktop QA]

Hello Honza! I have tried to reproduce the issue again on my end with Ubuntu 22.04, with the version named in comment 5 (105.0b4) and with firefox 106.0a1(2022-09-06), unfortunately I'm still not able to reproduce the issue. I have used a demo from Github https://bncb2v.csb.app/. I don't know if this is the correct demo to use but the service workers worked.

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thank you Sergiu.

@ewolfman: we've troubles to repro this issue, any tips what else we could try to see the problem on our machines? It would be great to have a test case we could use...

Comment 9

[ewolfman]

Hi again,
Sorry for the late reply.
I can update that on FF 107 the fetch event for html audio doesn't seem to be firing (i can see it firing for all other requests).
When I revert back to FF 106.5 it is firing.
I know its a different issue than the one I reported here. Just thought to make the connection. I created a new bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1803205

Comment 10

[ewolfman]

Correction: It is working on Firefox 106.0.5. Does not work for 107.0.1

Comment 11

[ewolfman]

One more addition. In Firefox 106.0.5 where the fetch event is firing and I use it to send the authorization header, I still cannot see it in the devtools->network tab as a part of the request.

Comment 12

[Julian Descottes [:jdescottes]]

This might be related to an issue we recently discussed, with requests initiated from the service worker itself filtered out by https://searchfox.org/mozilla-central/rev/670e2e0999f04dc7734c8c12b2c3d420a1e31f12/devtools/shared/network-observer/NetworkUtils.sys.mjs#363-366.

ewolfman: could you try to open the Browser Toolbox select the Network panel in the Browser Toolbox, and then trigger your fetch authentication request? Do you see anything logged there?

Comment 13

[ewolfman]

Yes, I do see the 'authorization' header in the Browser Toolbox (FF 106.0.5 64-bit).

BTW this isn't the only difference that i can see. In fact, the requests seem to be quite different. For example I can see an OPTIONS cors request in the browser toolbox. And when comparing the GET requests they look quite different, and the differences are quite puzzling: HTTP versions, Sec-Fetch-Mode: cors/no-cors, Sec-Fetch-Dest etc. So quite a few differences (see below). Checked server side and it seems like the actual incoming headers are those reflected in the Browser Toolbox and not the devtools. Is this expected? makes the devtools network log look unreliable.

F12 Devtools:

GET /files/6d6a5a6a-969a-463a-ba3f-fa311d82aeed HTTP/1.1
Host: <masked>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: audio/webm,audio/ogg,audio/wav,audio/;q=0.9,application/ogg;q=0.7,video/;q=0.6,/;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://<masked>/
Sec-Fetch-Dest: audio
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-site
Range: bytes=0-
Connection: keep-alive
Cookie: <masked>

Browser Toolbox:

GET /files/6d6a5a6a-969a-463a-ba3f-fa311d82aeed HTTP/2
Host: <masked>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://<masked>/service-worker.min.js
Authorization: Bearer <masked>
Origin: https://<masked>
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
TE: trailers

Comment 14

[Julian Descottes [:jdescottes]]

Thanks for checking!
Could you share your service-worker code? Or even just a simplified version, to try to understand how this can happen?

makes the devtools network log look unreliable

That's fair, but hopefully that's mostly affecting service worker requests. Regular requests coming from the page should still be displayed accurately.

Comment 15

[ewolfman]

Thanks for looking into this.

Note: if there is a different way better way to add 'authorization' header to html audio other than using a Service Worker (without having to fetch all the audio first) - I would gladly switch to it.

Simplified version of the service-worker (as you can see, all it does it simply fetch with authorization).

let authorization = 'ABC';
let targetPrefix = '/files/';

function log(msg) {
    console.debug('SW: ' + msg);
}


self.addEventListener('install', function (event) {
    self.skipWaiting();
});

self.addEventListener('activate', event => {
    log('in activate');

    // immediately start to control fetches
    event.waitUntil(clients.claim());
});

self.addEventListener("fetch", (event) => {
    // ignore non MM requests
    if (!authorization
        || event.request.method !== "GET"
        || event.request.url.indexOf(targetPrefix) === -1) {
        return;
    }

    var url = event.request.url;

    log('fetch event returning: ' + url + ' authorization: ' + authorization);

    event.respondWith(
        fetch(event.request.url, {
            method: "GET",
            cache: 'no-cache',
            headers: {
                "Authorization": "Bearer " + authorization,
            },
            redirect: "follow"
        })
    );
});

Comment 16

[Julian Descottes [:jdescottes]]

I think this is fully a duplicate of Bug 1432311, at least for the DevTools issue.