1778271 - File form payload corruption (byte 0xD) when resending a request in the network tab

Status: NEW

(DevTools :: Netmonitor, defect)

Description

[Julian Descottes [:jdescottes]]

Attachment: image_1.png

From https://discourse.mozilla.org/t/file-form-payload-corruption-byte-0xd-when-resending-a-request-in-the-network-tab/99377

Let’s say we have an HTML form on a page that accepts files and other user input. The form has a POST method and multipart/form-data enctype.
Suppose we want to play with a form submit request, we fill the form and submit it, then we use the Resend on the request, change the data from some text field (change only one character to not affect Content-Length), then click Send.

(See attachment image_1.png)

And what we get as a result, the form payload was changed, the affected text field was received by the server with the expected changes, BUT, the uploaded file was also affected (!), uploaded png image became corrupted, which was definitely not expected.
See HEX diff between submitted png file with and without form data alteration using Resend feature:

(See attachment image_2.png)

It was noticed that only bytes 0xD (CR) are changed, they are replaced by 0xA (LF).
If the payload has not been changed, the Resend works fine, all data is transmitted as is. But it is worth changing one character, the data is distorted.
Needless to say, this behavior of the developer tool was very unexpected for me. The logical behavior would be for the form data to remain in its original form until it is changed directly, especially if binary data was used.
Do you think this can be fixed?

Comment 1

[Julian Descottes [:jdescottes]]

Attachment: image_2.png

Comment 2

[Sergey Grigorjev]

Attachment: file_form.zip

Simple script that can be used to replicate the problem with uploaded files

Comment 3

[Sergey Grigorjev]

Any multipart/form-data form with input:file can be used to reproduce the issue, but I'm attaching PHP script I used for testing (see file_form.zip)
The main requirement under which the problem will be reproduced is that the uploaded file MUST contains 0xD byte.
I used a PNG file blue.png (included in attached archive) which satisfies this requirement.
The steps to reproduce are as follows:

• Run file_form.php on PHP based web server
• Open file_form.php as a web page
• Browse the appropriate file to upload, e.g. blue.png
• Open Web Developer Tools and go to Network tab
• Submit the form
• Find POST request to file_form.php in Network tab and click Resend on it
• Change only the "data" field (initially it contains "some data", it can be changed to "s0me data" for example)
• Click Send
• Go to the file_dumps folder and check the two versions of the uploaded file (one that was uploaded originally and one that was uploaded as a resend)
• use some HEX diff tool to compare content of uploaded files

Current result: the contents of the uploaded files are different
Expected result: the contents of the uploaded files must be identical

I left in the folder file_dumps two files obtained from my own tests as an example of the problem
dump_2022-07-05-20-09-53_blue.png - file that was uploaded originally
dump_2022-07-05-20-15-49_blue.png - file that was uploaded as a resend

If any additional information is required, I am ready to provide it.
Thanks.

Comment 4

[Sergey Grigorjev]

Just realized, that 0xD -> 0xA replacement affects not only file content, but whole request body:
Request body without changes via Resend:

-----------------------------1683079292854678734556078117\r\n
Content-Disposition: form-data; name="data"\r\n
\r\n
some data\r\n
-----------------------------1683079292854678734556078117--\r\n

Request body after changes via Resend:

-----------------------------1683079292854678734556078117\n
Content-Disposition: form-data; name="data"\n
\n
s0me data\n
-----------------------------1683079292854678734556078117--\n

And also, please note, that the Content-Length header sent has the same value of 178 for both attempts, despite the fact that for the second attempt the actual content length is 173. Which in turn leads to additional problems when processing the request on the server side, since the actual length of the request body does not match the one declared in the Content-Length header.

Comment 5

[Sergey Grigorjev]

The issue with actualizing Content-Length value during resend has been implemented two years ago in https://bugzilla.mozilla.org/show_bug.cgi?id=1623004
And now it seems to be broken, perhaps with the release of a new version of CustomRequestPanel
But, that's a side issue, the priority issue here is that the form payload must not change anyway without explicit user changes.

Comment 6

[Julian Descottes [:jdescottes]]

Most likely a duplicate of Bug 1779359. Blocking for now, should test again once the dependency is fixed.

Comment 7

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