[Bug]: Inconclusive Parsing of Content-Disposition Header

[gdavidkov]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

30.0.0

What operating system are you using?

Windows

Operating System Version

Microsoft Windows [Version 10.0.19045.4291]

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

The "content-disposition" header shouldn't be modified and work as in Chromium. Please, take a look at the screenshots I've attached. The problem is in the function HttpResponseHeadersToV8 - https://github.com/electron/electron/blob/main/shell/browser/api/electron_api_web_request.cc#L93C22-L93C45

Actual Behavior

Testcase Gist URL

https://gist.github.com/gdavidkov/08a8edae420a5b30e9f855f0ebb75a63

Additional Information

Ref: #25961
PR: #31669

[gdavidkov]

When I try to add the missing information to the header, I encounter the following problem:

[gdavidkov]

If the header is in not the correct format, the filename is empty. I think we should return the original header like in the Chromium.

[alfein]

This bug is happening due to a change that was made in this pull request. Unfortunately, if the onHeadersReceived is used and client code needs to modify headers, the original value of the constent-disposition header is lost. Moreover the new value incorrectly includes a space before the word attachment and it drops the value of filename*, which is what should be used to avoid issues with filename encoding on the client side.

The PR should be undone. Reference to similar comment