You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Cypress tries to filter down Accept-Encoding headers to just gzip. This works when the header is present, but when it is blank according to the standards for the header:
If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent.
Thus, we need to update the logic to specify identity when there is no Accept Encoding header.
The problem would manifest itself in the following scenario:
No Accept-Encoding header is sent on a request
The server sends back the response encoded in an unsupported encoding (e.g. brotli/deflate)
Something in Cypress relies on the decompressed body (this could include cy.intercept or CSS, font, and image assets in Test Replay)
The text was updated successfully, but these errors were encountered:
ryanthemanuel
changed the title
Ensure that brotli is filtered out in Accept Encoding by the Cypress proxy
Ensure that deflate/brotli is filtered out in Accept Encoding by the Cypress proxy
Oct 10, 2023
Wouldn't a more scalable solution be to just support brotli? This encryption is extremely common on the modern web, and Cypress insisting on Gzip actually leads to compression issues when e.g. talking to CloudFront endpoints.
Currently, Cypress tries to filter down Accept-Encoding headers to just gzip. This works when the header is present, but when it is blank according to the standards for the header:
Thus, we need to update the logic to specify
identity
when there is no Accept Encoding header.The problem would manifest itself in the following scenario:
cy.intercept
or CSS, font, and image assets in Test Replay)The text was updated successfully, but these errors were encountered: