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

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.

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:

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?

Thanks for reporting the issue!

It sounds like we should track this as a Bug directly, so I will file one.
Do you have a test page we could use to reproduce the issue?

Edit: Filed as, if you have additional information which could help the team reproduce the bug, you can comment here or on the bug directly.

1 Like


I left the detailed steps for reproducing the issue in the bug ticket. I have also attached my PHP script that I used for testing, as well as the file containing 0xD byte with which the problem is reproduced.

Thanks for the quick response and creating the bug, I appreciate it.

1 Like

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

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

Request body after changes via Resend:

Content-Disposition: form-data; name="data"\n
s0me data\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.

I duplicated this find in the bugs comments as well.

Edit: Here’s a cross-reference to a discussion of managing the Content-Length header when using the resend feature Reset Content-Length Header when editing and resending Requests