Authorization Token Not Sent for Large File Uploads in Firefox
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
People
(Reporter: krvn.den, Unassigned)
Details
(Whiteboard: [necko-triaged][necko-priority-next])
Attachments
(2 files, 2 obsolete files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Steps to reproduce:
- Create a simple HTML form with an input type="file".
- Select a large file (e.g., 10 megabytes).
- Submit the form in Firefox.
- Monitor the network traffic to observe if the authorization header is sent.
Actual results:
The authorization header is not sent when the file size is large (e.g., 10 megabytes).
Expected results:
Firefox should send the authorization header along with the file upload request, similar to how Chrome handles it.
Attachments:
- Example HTML page for file upload.
- Server code for handling the file upload and logging headers.
- Headers read by the server from Chrome.
- Headers read by the server from Firefox.
Updated•11 months ago
|
Comment 1•11 months ago
|
||
Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 131.0a1(2024-08-07) on Ubuntu 22.04 .
Could you please answer the following questions in order to further investigate this issue?
- 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
- 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/
- Do you have any addons installed? If yes could you please list them?
- Could you please send a screen recording with the issue?
(In reply to Negritas Sergiu, Desktop QA from comment #1)
Hello! Thank you for submitting this issue I have tried to reproduce the issue on my end but unfortunately I wasn't able to with firefox 131.0a1(2024-08-07) on Ubuntu 22.04 .
Could you please answer the following questions in order to further investigate this issue?
- 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
- 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/
- Do you have any addons installed? If yes could you please list them?
- Could you please send a screen recording with the issue?
Hello!
I am using a new profile in the night browser. I am not using any extensions. You can download the screen recording from this link:
https://file.io/cJ1r0NP6DaHS
Also attached is an example of server code (I added certificates for HTTPS).
Comment 4•11 months ago
|
||
I put the recording on the mozilla shared drive:
https://drive.google.com/drive/folders/1kMdCJjU5dFfkR4jLqmuEPC-YXwcKIGhi?usp=drive_link
Thank you for assisting us with the investigation.
Could you additionally help us track down what change introduced this bug by using mozregression - short intro here
Thanks!
(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)
I put the recording on the mozilla shared drive:
https://drive.google.com/drive/folders/1kMdCJjU5dFfkR4jLqmuEPC-YXwcKIGhi?usp=drive_linkThank you for assisting us with the investigation.
Could you additionally help us track down what change introduced this bug by using mozregression - short intro hereThanks!
I conducted regression testing. The issue is reproducible in all versions of the browser (even from 2017). It seems it has always been there.
Comment 6•11 months ago
|
||
Very odd that this depends on file size
Comment 7•10 months ago
|
||
Hi Sean,
If you have time, could you take a look at this?
Thanks.
Comment 8•10 months ago
|
||
Updated•10 months ago
|
Comment 9•10 months ago
|
||
Updated•10 months ago
|
Updated•10 months ago
|
Updated•4 months ago
|
Updated•4 months ago
|
Comment 10•28 days ago
|
||
I think this is a server-side issue.
From the log below, we can see that Firefox receives a 401 at the HTTP/2 layer. Then, the server resets the stream, which Firefox treats as an error. So we don’t store the authentication information.
2025-06-13 13:56:29.038248 UTC - [Parent 29930: Socket Thread]: V/nsHttp Http2Decompressor::DoLiteralInternal value 401
2025-06-13 13:56:29.038252 UTC - [Parent 29930: Socket Thread]: V/nsHttp HTTP Decompressor not gatewaying :status into http/1
2025-06-13 13:56:29.038263 UTC - [Parent 29930: Socket Thread]: V/nsHttp HTTP decompressor literal with index 0 :status 401
...
2025-06-13 13:56:29.038372 UTC - [Parent 29930: Socket Thread]: I/nsHttp Http2Session::CleanupStream 140654400 1321f1400 0x7 804B0014
2025-06-13 13:56:29.038375 UTC - [Parent 29930: Socket Thread]: I/nsHttp Http2Session::CloseStream 140654400 1321f1400 0x7 804B0014
2025-06-13 13:56:29.038377 UTC - [Parent 29930: Socket Thread]: I/nsHttp MaybeDecrementConcurrent 140654400 id=0x7 concurrent=1 active=1
2025-06-13 13:56:29.038380 UTC - [Parent 29930: Socket Thread]: I/nsHttp Stream had active partial read frame on close
2025-06-13 13:56:29.038382 UTC - [Parent 29930: Socket Thread]: I/nsHttp Http2Session::ChangeDownstreamState() 140654400 from 2 to 6
2025-06-13 13:56:29.038385 UTC - [Parent 29930: Socket Thread]: V/nsHttp nsHttpTransaction::Close [this=14209bf00 reason=804b0014]
The difference in file size that triggers the bug may be due to timing differences.
Description
•