Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chrome Cypress browser adds "charset=utf-8" to the content-type in the response header #3650

Closed
funatronics opened this issue Mar 5, 2019 · 7 comments · Fixed by #4698
Closed
Assignees

Comments

@funatronics
Copy link

funatronics commented Mar 5, 2019

Current behavior:

Some of my website's HTTP requests are failing only in the Cypress browser (e.g. signing up for a new account). After debugging, it was discovered this was due to the response header returning a different content-type in the Cypress browser.

Chrome browser:

content-type: application/json

Cypress browser (not running headlessly):

Content-type: application/json; charset=utf-8

Cypress is adding "charset=utf-8" to the content-type.

Desired behavior:

Return the same content-type as the Chrome browser.

Versions

3.1.5
Chrome 72

@funatronics funatronics changed the title Cypress browser is adding "charset=utf-8" to the content-type in the response header Cypress browser adds "charset=utf-8" to the content-type in the response header Mar 5, 2019
@funatronics funatronics changed the title Cypress browser adds "charset=utf-8" to the content-type in the response header Chrome Cypress browser adds "charset=utf-8" to the content-type in the response header Mar 7, 2019
@yusinto
Copy link

yusinto commented Apr 2, 2019

I also encountered the same problem. Previously my app checks the Content-Type of the http response by doing a string comparison which fails. I refactored it so it checks the existence of the desired type instead:

// wrong
response.headers.get('Content-Type') === 'application/json'

// right
response.headers.get('Content-Type').includes('application/json')

I don't think you can always safely assume that browsers will only send 'application/json' in the Content-Type header. Hope that helps.

@funatronics
Copy link
Author

@yusinto yeah, that was my solution to this problem as well.

@cypress-bot cypress-bot bot added the stage: needs investigating Someone from Cypress needs to look at this label Apr 18, 2019
@ludwikd
Copy link

ludwikd commented May 31, 2019

In my case strange is that,
when running test on locally deployed (localhost) web page, the header is unchanged: application/json
But when testing the same web app remotely deployed (s3 + CloudFront), the header is extended with charset=utf-8

@flotwig flotwig self-assigned this Jul 12, 2019
@cypress-bot cypress-bot bot added stage: work in progress stage: needs review The PR code is done & tested, needs review and removed stage: needs investigating Someone from Cypress needs to look at this stage: work in progress labels Jul 12, 2019
@flotwig
Copy link
Contributor

flotwig commented Jul 12, 2019

This is a symptom of ExpressJS (which Cypress uses for the internal proxy server) forcing charset=utf-8 on all responses, which will be fixed by #4698.

@cypress-bot cypress-bot bot added stage: work in progress stage: needs review The PR code is done & tested, needs review and removed stage: needs review The PR code is done & tested, needs review stage: work in progress labels Jul 12, 2019
@cypress-bot cypress-bot bot added stage: pending release and removed stage: needs review The PR code is done & tested, needs review labels Jul 15, 2019
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jul 15, 2019

The code for this is done in cypress-io/cypress#4698, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jul 29, 2019

Released in 3.4.1.

@funatronics
Copy link
Author

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants