When attempting to resolve our site, Cypress throws an error. This was not an issue on older versions of Cypress. Our NGINX config is fairly vanilla and hasnt changed since we deployed it several months ago
error
CypressError: cy.visit() failed trying to load:
https://our-website.test.com/search-page
We attempted to make an http request to this URL but the request failed without a response.
We received this error at the network level:
> Error: Parse Error
Common situations why this would fail:
- you don't have internet access
- you forgot to run / boot your web server
- your web server isn't accessible
- you have weird network configuration settings on your computer
The stack trace for this error is:
Error: Parse Error
at TLSSocket.socketOnData (_http_client.js:451:22)
at TLSSocket.emit (events.js:194:13)
at addChunk (_stream_readable.js:296:12)
at readableAddChunk (_stream_readable.js:277:11)
at TLSSocket.Readable.push (_stream_readable.js:232:10)
at TLSWrap.onStreamRead (internal/stream_base_commons.js:165:17)
Because this error occurred during a 'before each' hook we are skipping the remaining tests in the current suite: 'Search Page tests'`
Our site loads on newer versions of Cypress (3.5.0) and up.
example code:
/// <reference types="Cypress" />
describe('Search Page Tests', () => {
beforeEach(() => {
cy.visit('/search')
})
cy.get(`[data-qa='tabs-wrapper']`).get(`[data-qa='tab']`).contains('red').as('redButton')
cy.get(`[data-qa='tabs-wrapper']`).get('[data-qa="tab"]').contains('blue').as('blueButton')
})
it('visit the search page and search for buttons', () => {
cy.getById('searchGoToHomeButton')
.should('have.attr', 'href', '/home')
});
Steps to reproduce.
npx cypress open
Click spec from GUI and let test start. Error is thrown immediately upon attempting to resolve the page.
v3.5.0
Cypress desktop, v3.5.0, MAcOS 10.13.6, Electron(Chrome v78)
Which baseurl do you have set? Maybe there is a problem when cypress tries to redirect from http to https or something. Can you provide a simple example using a small express server + nginx + some cypress code?
As @gabbersepp mentioned, we'll need a way to reproduce this in order to move forward with finding the problem - otherwise we will need to close the issue since there's no way for us to more forward debugging.
@gabbersepp and @jennifer-shehane I will compile the needed code to debug effectively.
We are also getting exactly same issue. With cypress version 3.4.1 every application works fine, however when we try to upgrade to latest versions (3.6.0+) then cypress is not able access the site (throwing the same error shared bytes @tmonteith ).
Apparently, something changed between 3.4.1 to latest versions of cypress that is causing issue. Note that we are also using ngnix and same configurations that work fine with c.ypress 3.4.1, do not work with cypress 3.6.0. @jennifer-shehane
@arifmasood are you able to provide a small example? We are using nginx as reverse proxy and I updated to cypress 3.6.1 right now to test this setup. Runs without any problems.
Our nginx proxies the traffic from a https site to a local http IIS site, if this is relevant.
@gabbersepp I cannot share details of scripts or website over here, however I have already sent an email with some details to cypress support team.
@arifmasood thanks!
I'm seeing the same error (without nginx proxy), just a NextJS app running on http://localhost:3000
Interestingly it works fine on the latest version providing I run in Chrome and not the Electron browser
any updates here?
@tmonteith I believe this is an "Parse Error" related to the Set-Cookie headers being sent from your server. Can you share the headers that your server sends here? It will help to shed some light on this issue.
All others in this thread - if you are still experiencing an issue in the latest Cypress, and you do not get a "Parse Error", please check for another issue that matches the error you are getting.
If you are getting the "Parse Error", please share your Set-Cookie headers to help debug.
I found a workaround. If I run it using NODE_OPTIONS=--max-http-header-size=1000000 before cypress run it works.
@flotwig Using 3.8.0 we get the same "Parse Error" in some environments, but not others.
Here's the Set-Cookie header for the one that does not work
set-cookie: AWSALB=0GzYs2kzoyI4H5bZBHOUQHEtlZzm2DdrV2TXptF0/BHF3tpdtTFhqTTfCv7aBCb+Vid4UN1W2JN1chRqekIi605s2KqWERTn6OxJerAZQti79gd0DAqCBuft2Qez; Expires=Sun, 22 Dec 2019 21:03:30 GMT; Path=/
while this one does work with no problems
Set-Cookie: AWSALB=MLuupbHkQ8eUksOj0T/StnqF9Xh7Rr8NUro7WGQTD9eaW5NQiuIDh5uso1LjYZ/XgDkqgB2CvgCjm/pcZ9aMhJzyRbA8qwRQ43NNNJzTN/ch0NnsYZoWAvTHcjM6; Expires=Sun, 22 Dec 2019 21:04:15 GMT; Path=/
Could it be the lowercase format?
Edit. I just saw that with the latest update we're now getting a "Parse Error: Invalid header value char" and not just the "Parse Error" we had from 3.5.0 and up.
CypressError: cy.request() failed trying to load:
https://our-website.com/login
We attempted to make an http request to this URL but the request failed without a response.
We received this error at the network level:
> Error: Parse Error: Invalid header value char
-----------------------------------------------------------
The request we sent was:
Method: POST
URL: https://our-website.com/login
-----------------------------------------------------------
Common situations why this would fail:
- you don't have internet access
- you forgot to run / boot your web server
- your web server isn't accessible
- you have weird network configuration settings on your computer
The stack trace for this error is:
RequestError: Error: Parse Error: Invalid header value char
at new RequestError (/Users/792276/Library/Caches/Cypress/3.8.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/request-promise-core/lib/errors.js:14:15)
at Request.plumbing.callback (/Users/792276/Library/Caches/Cypress/3.8.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/request-promise-core/lib/plumbing.js:87:29)
at Request.RP$callback [as _callback] (/Users/792276/Library/Caches/Cypress/3.8.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/request-promise-core/lib/plumbing.js:46:31)
at self.callback (/Users/792276/Library/Caches/Cypress/3.8.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/request/request.js:185:22)
at Request.emit (events.js:203:13)
at Request.onRequestError (/Users/792276/Library/Caches/Cypress/3.8.0/Cypress.app/Contents/Resources/app/packages/server/node_modules/request/request.js:877:8)
at ClientRequest.emit (events.js:203:13)
at TLSSocket.socketOnData (_http_client.js:456:9)
at TLSSocket.emit (events.js:203:13)
at addChunk (_stream_readable.js:295:12)
at readableAddChunk (_stream_readable.js:276:11)
at TLSSocket.Readable.push (_stream_readable.js:210:10)
at TLSWrap.onStreamRead (internal/stream_base_commons.js:166:17)
Because this error occurred during a 'before each' hook we are skipping the remaining tests in the current suite: 'Login test'
@mr-winter I spent some time trying out sending those set-cookie headers during a cy.request - uppercase, lowercase, doesn't seem to matter; it all works for me.
Do you think you could share your application's repository, or if that is unavailable, a reproducible example that I can run on my machine to see the issue? You can use cypress-test-tiny as a base or start your own project, whatever is easiest.
@flotwig Here are our Set Cookie values:
set-cookie: ASP.NET_SessionId=h24hhyymnziynqjybxkym0l1; path=/; HttpOnly
set-cookie: mdt-home-next-gen=control; expires=Tue, 17 Dec 2019 16:17:46 GMT; path=/
set-cookie: global-holdout-group=control; expires=Tue, 17 Dec 2019 16:17:46 GMT; path=/
set-cookie: nlbi_812069=1NUyH18sESB9j1PnSEROQgAAAAAqcBhwdyviRf6LkAO0VaV4; path=/; Domain=.our_site.com
set-cookie: incap_ses_552_812069=NZh6a+oUuEO1Hdt1oRqpByb8+F0AAAAAbaovV9u4hHf3XrenCC2Bug==; path=/; Domain=.our_site.com
@tmonteith Please provide a reproducible example - a repo with server code + test run that demonstrates the issue. Using these set-cookie headers does not cause an issue for me.
@flotwig I put up an example that throws the "Parse Error: Invalid header value char" error on just a simple cy.visit().
I believe the "Parse Error: Header overflow" from #6050 is due to the maximum header size being supported by Electron being only 8kb.
We are waiting for Electron to release a fix that will allow us to bump that limit, but until it gets released, it blocks this issue: https://github.com/electron/electron/issues/20831
Still looking in to why that error may happen with headers < 8kb, like in @mr-winter's repro.
@mr-winter I actually don't get a "Parse Error" from the repo you supplied, it seems to work fine in any recent version of Cypress. Do you still get the issue?
If so, can you try running your tests with debug logs enabled, and share those logs here? It will show some more information which we can use to get to the root of the issue.
DEBUG=cypress:* cypress ...npx cross-env DEBUG=cypress:* cypress ...Make sure to scrub any private data from the logs before sharing here.
We are facing the same issue, any updates on this? as we are stuck with the ongoing test.
CypressError: cy.visit() failed trying to load:
https://www.xxxxxxx.com/xxx/store.html?*=123456789
We attempted to make an http request to this URL but the request failed without a response.
We received this error at the network level:
Error: Parse Error: Invalid header value char
Common situations why this would fail:
The stack trace for this error is:
Error: Parse Error: Invalid header value char
at TLSSocket.socketOnData (_http_client.js:449:22)
at TLSSocket.emit (events.js:203:13)
at addChunk (_stream_readable.js:295:12)
at readableAddChunk (_stream_readable.js:276:11)
at TLSSocket.Readable.push (_stream_readable.js:210:10)
at TLSWrap.onStreamRead (internal/stream_base_commons.js:166:17)
@flotwig yes, same issue still with latest v3.8.1
2020-01-06T03_02_20_148Z-debug.log
I see no issue with live site but facing the issue in test environment. Hence jumping back to 3.4.1 until this issue is not resolved.
cy.visit is not working with latest cypress version(v 3.8.1). Works fine with 3.4.1
After doing some investigation into the "Parse Error: Invalid header value char", it comes down to a change in Node.js that was made in Node.js 11.5.0: nodejs/node#24730
The llhttp HTTP parser replaced the old http_parser HTTP parser. The newer one is more maintainable; however, it also seems to be much stricter about what can be in an HTTP header. Since Cypress uses Node's HTTP library to proxy requests to your site, invalid characters in the header will now give this error.
In Cypress 3.5.0, the bundled Node.js version was upgraded to > 11.5.0 (#5849), introducing this bug.
Here is a bug in the Node.js repo talking about this issue with llhttp and some proposed fixes: nodejs/node#30573
I believe that, in the meantime, we may be able to pass the --http-parser=legacy option to opt out of using the new llhttp parser. I will work on creating a test that reproduces the "Invalid header value char" issue as well as a fix.
In the meantime, a workaround would be to ensure that the headers sent by your server do not contain any special characters that are illegal in an HTTP header.
I am also getting the same error in cypress 3.8.0 that is blocking my regression test run.
This the header that I am sending
headers: {'content-type': 'application/json'}
--http-parser=legacy
^ where should I use this option?
@flotwig how do we use this node_option?
I updated to Cypress 3.8.3 in the hope this is fixed but I'm still getting the same issue - though I do not know how to make use of this --http-parser=legacy option.
This is what I was trying to do even in basic form:
My package.json has the following command built-in: "cy:open": "cypress open",
And in cmd (just in a basic form to see if NODE_OPTIONS works):
C:\Dev\Projects\x>set NODE_OPTIONS=--http-parser=legacy
C:\Dev\Projects\x>npm run cy:open
C:\Program Files\nodejs\node.exe: --http-parser=legacy is not allowed in NODE_OPTIONS
I found a workaround. If I run it using
NODE_OPTIONS=--max-http-header-size=1000000beforecypress runit works.
This doesn't seem to work for me. Does anyone have some other solutions?
@flotwig any ideas to the above?
NODE_OPTIONS=--max-http-header-size=1000000 cypress run works with [email protected].
@toniton how are you running it?
C:\proj>set NODE_OPTIONS=--max-http-header-size=1000000
C:\proj>npm cy:open
C:\Program Files\nodejs\\node.exe: --max-http-header-size=1000000 is not allowed in NODE_OPTIONS
This is all I get.. and can't seem to put it in the package.json command either. Any help much appreciated, I've updated to [email protected] but it's still the same for me.
@add1ct3dd
Try executing command NODE_OPTIONS=--max-http-header-size=1000000 npm cy:open together.
@toniton how are you running it?
C:\proj>set NODE_OPTIONS=--max-http-header-size=1000000 C:\proj>npm cy:open C:\Program Files\nodejs\\node.exe: --max-http-header-size=1000000 is not allowed in NODE_OPTIONSThis is all I get.. and can't seem to put it in the package.json command either. Any help much appreciated, I've updated to [email protected] but it's still the same for me.
@toniton
Try executing command
NODE_OPTIONS=--max-http-header-size=1000000 npm cy:opentogether.
Weird, I get the same output (formatted the command to work in windows):
C:\proj>set NODE_OPTIONS=--max-http-header-size=1000000 && npm cy:open
C:\Program Files\nodejs\\node.exe: --max-http-header-size=1000000 is not allowed in NODE_OPTIONS
C:\Program Files\nodejs\\node.exe: --max-http-header-size=1000000 is not allowed in NODE_OPTIONS
What node version are you on? I'm currently on 8.12.0.
@add1ct3dd I'm currently using v10.16.3, but I think any version from v10.16.3 - v13 should work just fine.
@flotwig It will be great if you can let me know about the status of this issue.

Taking a look at the above posts, I can see I am having the same issue as other people. Is there a work around for this issue?
Taking a look at the above posts, I can see I am having the same issue as other people. Is there a work around for this issue?
@natkrish We are waiting for https://github.com/electron/electron/pull/21694 to be released in Electron 9 so we can use it. Once we can use --http-parser=legacy, we can fix this finally.
In the meantime, the only workaround is to update your web server to send headers that do not contain non-printable ASCII characters.
@flotwig Great thanks. I thought one problem solved https://github.com/cypress-io/cypress/issues/5446 and then I can start working on the latest cypress version. Now this happened when running test on prod - as you may recollect the one which you helped resolving. Will this issue also impact chrome browser too ?
@flotwig If you dont mind confirming that the above issue with electron will also impact when running tests on chrome?
@natkrish Yep, it will be affected, this is an issue in the Cypress server, so it will affect any browser.
@flotwig great thanks for letting me know about it.
Upgrading to Electron 9 (where this bug is presumably fixed) is blocked by our inability to upgrade to Electron 8 detailed in this PR: https://github.com/cypress-io/cypress/pull/6555
@flotwig is it correct to believe that v4.2.0 will have the fix for this?
@tmonteith 4.2.0 does not have a fix for this, however, now that we're running >= Electron 8.1.0 it's possible to fix this issue. I'm working on a fix in #5988 that should make it into the next release.
The code for this is done in cypress-io/cypress#5988, but has yet to be released.
We'll update this issue and reference the changelog when it's released.
Released in 4.3.0.
This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v4.3.0, please open a new issue.
Most helpful comment
After doing some investigation into the "Parse Error: Invalid header value char", it comes down to a change in Node.js that was made in Node.js 11.5.0: nodejs/node#24730
The
llhttpHTTP parser replaced the oldhttp_parserHTTP parser. The newer one is more maintainable; however, it also seems to be much stricter about what can be in an HTTP header. Since Cypress uses Node's HTTP library to proxy requests to your site, invalid characters in the header will now give this error.In Cypress 3.5.0, the bundled Node.js version was upgraded to > 11.5.0 (#5849), introducing this bug.
Here is a bug in the Node.js repo talking about this issue with
llhttpand some proposed fixes: nodejs/node#30573I believe that, in the meantime, we may be able to pass the
--http-parser=legacyoption to opt out of using the newllhttpparser. I will work on creating a test that reproduces the "Invalid header value char" issue as well as a fix.In the meantime, a workaround would be to ensure that the headers sent by your server do not contain any special characters that are illegal in an HTTP header.