1459999 - File upload: Content-Length does not match actual data size

Status: UNCONFIRMED

(Core :: Networking: File, defect, P3)

Description

[Peter Wu]

Attachment: Upload form (HTML)

Steps to reproduce:
1. Start a webserver (e.g. python3 -m http.server), serving the attached form.
2. Start a packet capture using Wireshark.
3. Visit http://localhost:8000
4. Create a file and select it: echo some data > testfile.txt
5. Truncate the file (by 5 bytes): echo some > testfile.txt
6. Press Upload button.
7. Reload page and confirm resubmission

Expected results:
The HTTP request body matches the Content-Length parameters in step 6 and 7.

Actual result:
In request 6, the Content-Length request header (230) is smaller than the actual HTTP request body size (225 bytes, 5 bytes less than expected).
In request 7, the Content-Length request header (157) is smaller than the actual HTTP request body size (225 bytes, 68 bytes less than expected).

Additional information:
This happened with both HTTP/1.1 and HTTP/2 servers.
The truncation step is not required to reproduce the issue in step 7.
It was reproduced with a new Firefox profile using 59.0.2.
This issue is causing a "Bad Request" when uploading a selected and then resized file to bugs.wireshark.org (HTTP/2, server is Cloudflare (nginx)).

Due to the mismatch between Content-Length and the HTTP request body size, Wireshark might not show the HTTP structure. As a workaround, disable the "Allow subdissectors to reassemble TCP streams" preference in the TCP protocol settings.

Comment 1

[stefan]

Can confirm that this happens. Any progress here?
Tested in Firefox version 60.2.0esr.

Comment 3

[Jan Kasprzak]

@robwu: How can an older bug be a duplicate of a newer bug? Shouldn't it be the other way round?

Comment 4

[Rob Wu [:robwu]]

@Jan Yes, newer bugs are usually marked as duplicate of older known bugs. I mistakenly thought that this report was older, because I saw it before your report. Apologies for the mixup. I will keep the current bug dependencies, since this bug is also linked to another relevant bug, and updating dependencies results in bugmail to everyone who subscribes to a bug.

I'm also adding the "regression" keyword given your comment at the other bug:

We have verified that the problem is also in Firefox 57 and in 60 nightly build. Only pre-57 versions were OK.

PS. I replied late because I wasn't subscribed to this bug and only saw your comment by coincidence. If you want a reply, don't hesitate using the "Need more information from" checkbox below the comment box to ensure that the comment is delivered to the intended recipient.

Comment 5

[Peter Wu]

I can no longer reproduce this in Firefox 67 (Arch Linux).
In step 6, the content-length matches the new file.
In step 7, the content-length also matches the new, shorter file.

The last known broken version I tried was Firefox 61.0.2.

Comment 6

[Jan Kasprzak]

You are right. I cannot reproduce this with Firefox 67.0 on Fedora 30.