Downloading a PDF with intercept corrupts the file

Current behavior

Downloading with intercept on a URI corrupts the file contents.

This is #9359 on the download side. The fix made for #9359 isn’t the “right” fix. Yes, it avoids corrupting multi-part file uploads, but it corrupts all binary downloads.

The problem is STILL here: https://github.com/cypress-io/cypress/blob/develop/packages/net-stubbing/lib/server/intercept-request.ts#L116

You cannot convert a buffer to a string with toString() unless you know the data is a string, and not binary data.

This also probably messes with download of files which are not utf8 encoded, for example something encoded in utf16le, since you will be converting them into utf8 before you save them.

I didn’t dig deep enough to understand why the toString() is required at all. If other layers are expecting a string, then let THEM do the conversion when they are sure they know they have a string.

For the times you are doing toString() you may want to check the ContentType header for the encoding and put that in toString() if Node will support it, but LOADS of uncommon encodings are not supported in Node, though these are unlikely to be tested with Cypress.

Desired behavior

Downloading with intercept should not corrupt the file.

Test code to reproduce

https://github.com/nickpalmer/cypress-intercept-buffer-bug

Versions

6.3.0

[johnnyperkins]

This is also an issue when trying to upload a file. Uploading to s3 with header Content-MD5 fails since the request body is binary data and the toString() changes it’s hash.

[pedrovgs]

Hi! I’d need to intercept a request and return a pdf file I have saved as a fixture but looks like this issue is breaking the fixture integration and corrupting the data. Do you know if there is any workaround we can use or something we can do to fix this issue?