431 status code on stubbed XHR requests with large response in 3.5.0

[jennifer-shehane]

Current behavior:

I have a request that is responding with a 431 status in 3.5.0 of Cypress, which was responding with a 200 in 3.4.1.

431 Request Header Fields Too Large

We are legitimately sending a large amount of characters in our response, I've included it below. If I reduce the size of this response content, it then passes as 200 status code.

Desired behavior:

Responding with a 200

Steps to reproduce: (app code and test code)

it('displays algolia dropdown on search', () => {
  cy.server()
  cy.route({
    method: 'POST',
    url: /algolia/,
    response: {
      'results': [
        {
          'hits': [
            {
              'hierarchy': { 'lvl2': null, 'lvl3': null, 'lvl0': 'Known Issues', 'lvl1': null, 'lvl6': null, 'lvl4': null, 'lvl5': null },
              'url': 'https://docs-staging.cypress.io/guides/appendices/known-issues.html#content-inner', 'content': 'Missing Commands Some commands have not been implemented in Cypress. Some commands will be implemented in the future and some do not make sense to implement in Cypress.  Right click Issue #53  Workaround  Oftentimes you can use  .invoke()  or  cy.wrap()  to trigger the event or execute the action in the DOM.  Example of right clicking on an element using jQuery  cy . get ( &#x27;#nav&#x27; ) . first ( ) . invoke ( &#x27;trigger&#x27; ,   &#x27;contextmenu&#x27; )   Example of right clicking on an element without jQuery  // need to create the event to later dispatch  var  e  =   new   Event ( &#x27;contextmenu&#x27; ,   { bubbles :   true ,  cancelable :   true } )  // set coordinates of click e . clientX  =   451 e . clientY  =   68 cy   . get ( &#x27;#nav&#x27; ) . first ( ) . then ( function ( $el )   {     $el [ 0 ] . dispatchEvent ( e )    } )   Hover Issue #10  Sometimes an element has specific logic on hover. Maybe the element doesn’t even display to be clickable until you hover over a specific element.  Workaround  Oftentimes you can use  .invoke()  or  cy.wrap()  to show the element before you perform the action.  Example of showing an element in order to perform action  cy . get ( &#x27;.content&#x27; ) . invoke ( &#x27;show&#x27; ) . click ( )   You can also force the action to be performed on the element regardless of whether the element is visible or not.  Example of clicking on a hidden element  cy . get ( &#x27;.content&#x27; ) . click ( { force :   true } )   Example of checking a hidden element  cy . get ( &#x27;.checkbox&#x27; ) . check ( { force :   true } )   Difficult use cases Cypress does not support the following use cases.  Iframes Issue #136  You cannot target elements or interact with anything in an iframe - regardless of it being a same domain or cross domain iframe.  This is actively being worked on in Cypress and you’ll first see support for same domain iframes, followed by cross domain (they are much harder to do).  Workaround  Sit tight, comment on the issue so we know you care about this support, and be patient.  OAuth This is related to the iframe issue above, but basically  oauth  usually will not work. This is one of the hardest things for Cypress to be able to handle as there are so many different implementations and mechanisms.  Likely we will be able to support server side oauth redirects, but for client side popups you’ll use sinon  and  stub  the oauth response directly in your code. This is actually possible to do right now but we don’t have any good docs or tutorials on it.  Workaround  Come into Gitter  and talk to us about what you’re trying to do. We’ll tell you if you’re able to mock this and how to do it.  window.fetch routing and stubbing Issue #95  Support for  fetch  has not been added but it’s possible to handle in the same way as we handle  XHRs . This biggest challenge here is that you can use  fetch  in  Service Workers  outside of the global context. We’ll likely have to move routing to the server and handle it in the proxy layer but it should be possible.  While we currently provide things like the stack trace and initiator line for XHR’s we will not be able to provide that for  fetch .  Workaround  Sit tight, comment on the issue so we know you care about this support, and be patient', 'anchor': 'content-inner', 'objectID': '15872310', '_snippetResult': { 'content': { 'value': 'to implement in Cypress.  Right <span class="algolia-docsearch-suggestion--highlight">click Issue #53</span>  Workaround  Oftentimes', 'matchLevel': 'full' } }, '_highlightResult': { 'hierarchy': { 'lvl0': { 'value': 'Known Issues', 'matchLevel': 'none', 'matchedWords': [] } }, 'content': { 'value': 'Missing Commands Some commands have not been implemented in Cypress. Some commands will be implemented in the future and some do not make sense to implement in Cypress.  Right <span class="algolia-docsearch-suggestion--highlight">click Issue #53</span>  Workaround  Oftentimes you can use  .invoke()  or  cy.wrap()  to trigger the event or execute the action in the DOM.  Example of right clicking on an element using jQuery  cy . get ( \'#nav\' ) . first ( ) . invoke ( \'trigger\' ,   \'contextmenu\' )   Example of right clicking on an element without jQuery  // need to create the event to later dispatch  var  e  =   new   Event ( \'contextmenu\' ,   { bubbles :   true ,  cancelable :   true } )  // set coordinates of click e . clientX  =   451 e . clientY  =   68 cy   . get ( \'#nav\' ) . first ( ) . then ( function ( $el )   {     $el [ 0 ] . dispatchEvent ( e )    } )   Hover Issue #10  Sometimes an element has specific logic on hover. Maybe the element doesn’t even display to be clickable until you hover over a specific element.  Workaround  Oftentimes you can use  .invoke()  or  cy.wrap()  to show the element before you perform the action.  Example of showing an element in order to perform action  cy . get ( \'.content\' ) . invoke ( \'show\' ) . click ( )   You can also force the action to be performed on the element regardless of whether the element is visible or not.  Example of clicking on a hidden element  cy . get ( \'.content\' ) . click ( { force :   true } )   Example of checking a hidden element  cy . get ( \'.checkbox\' ) . check ( { force :   true } )   Difficult use cases Cypress does not support the following use cases.  Iframes Issue #136  You cannot target elements or interact with anything in an iframe - regardless of it being a same domain or cross domain iframe.  This is actively being worked on in Cypress and you’ll first see support for same domain iframes, followed by cross domain (they are much harder to do).  Workaround  Sit tight, comment on the issue so we know you care about this support, and be patient.  OAuth This is related to the iframe issue above, but basically  oauth  usually will not work. This is one of the hardest things for Cypress to be able to handle as there are so many different implementations and mechanisms.  Likely we will be able to support server side oauth redirects, but for client side popups you’ll use sinon  and  stub  the oauth response directly in your code. This is actually possible to do right now but we don’t have any good docs or tutorials on it.  Workaround  Come into Gitter  and talk to us about what you’re trying to do. We’ll tell you if you’re able to mock this and how to do it.  window.fetch routing and stubbing Issue #95  Support for  fetch  has not been added but it’s possible to handle in the same way as we handle  XHRs . This biggest challenge here is that you can use  fetch  in  Service Workers  outside of the global context. We’ll likely have to move routing to the server and handle it in the proxy layer but it should be possible.  While we currently provide things like the stack trace and initiator line for XHR’s we will not be able to provide that for  fetch .  Workaround  Sit tight, comment on the issue so we know you care about this support, and be patient', 'matchLevel': 'full', 'fullyHighlighted': false, 'matchedWords': ['click', 'issue', '53'] }, 'hierarchy_camel': [{ 'lvl0': { 'value': 'Known Issues', 'matchLevel': 'none', 'matchedWords': [] } }] },
            },
          ], 'nbHits': 1, 'page': 0, 'nbPages': 1, 'hitsPerPage': 5, 'processingTimeMS': 1, 'exhaustiveNbHits': true, 'query': '"click Issue #53" ', 'params': 'query=%22click%20Issue%20%2353%22%20&hitsPerPage=5', 'index': 'cypress',
        },
      ],
    },
  }).as('postAlgolia')
  cy.visit('https://docs.cypress.io')
  cy.get('#search-input').type('g')
  cy.wait('@postAlgolia')
  cy.get('.ds-dropdown-menu').should('be.visible')
})

Versions

3.5.0

[pedrotorchio]

Same issue here. Rolling back to 3.4. Thanks for this tool btw

[flotwig]

3.5.0 should've increased the max header size: #76 But it looks like there's some sort of regression.

Node 12 (which Cypress 3.5.0 uses) made the max headers size only 8kb, down from 80kb: nodejs/node#25528

They also added a --max-http-header-size flag: nodejs/node#24811

[AshleyHollis]

I've hit this issue also. Rolling back to 3.4.1.
Thanks for reporting it so quickly.

[nottyo]

I also found this issue because I have a lot of XHR stubbed responses. Cypress returns HTTP 431 for some of stubbed responses. Has to roll back to 3.4.1

[flotwig]

Workaround

Setting the environment variable NODE_OPTIONS=--max-http-header-size=1000000 should work as a workaround:

NODE_OPTIONS=--max-http-header-size=1000000 npm run cypress:open

[idxrx]

If you are going back to Cypress 3.4.1 don't update NodeJs to the latest (12.13.0 LTS), because of this bug: #5241 (solved in Cypress 3.5.0) Install NodeJs v12.10 and you be fine.

[jennifer-shehane]

There is a new PR to fix this, as the other PR to fix this encountered newer issues. #5525

[cypress-bot]

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

[cypress-bot]

Released in 3.6.0.

[tzhou102]

Is there any update? 3.8.2 still got 431

[jennifer-shehane]

This issue will be closed to further comment as the exact issue here was resolved and tested in Cypress 3.6.0.

@tapa-nama If you're experiencing a bug similar to this in Cypress, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.