Some Calls to cy.visit() Fail with a Parse Error when experimentalNetworkStubbing is Turned On #8497
Assignees
Labels
Comments
|
@todd-m-kemp for example yours doesn't work when you visit "https://secure.vidyard.com/user/sign_in" |
@alim16 Agreed; I noticed the same thing and wondered if it was related to redirects. It certainly seems to make sense based on what we are both experiencing. |
cypress-bot
bot
added
the
stage: needs investigating
|
I have the same problem and my route also redirects. |
|
in case anyone is looking for a temporary workaround, here is mine //my function looks like this export const loadAppWithRedirect = (path:string) => cy.request({
url: path,
followRedirect: true
}).then((resp) => {
const urlRegex = /(https?:\/\/[^ ]*)/
//ts-ignore because ts claims"redirects" does not exist, but it does for me
//@ts-ignore
const stringWithRedirectedUrl = resp.redirects[resp.redirects.length - 1] //get the last link in the redirect chain
const url = stringWithRedirectedUrl.match(urlRegex)[1].toString()
cy.visit(url)
})//and my test would look like this it("should go to my site even if it redirects", () => {
loadAppWithRedirect('https://secure.vidyard.com/user/sign_in')
cy.contains("Welcome back").should('exist')
})@todd-m-kemp I needed an example url and can't use mine, I hope you don't mind my experience with cypress is limited so if anyone has better/easier way, please let me know |
|
I ran into this issue as well. Building on the workaround from @alim16, I added the following to Caveats:
|
|
@rbell-mfj but I like the idea of overwriting the visit command to not have to change tests, so I might do the same |
|
@alim16 I should have also noted that the code I posted will only follow a single redirect, so if you have a series of multiple redirects, it may need to be modified accordingly (just a guess) |
|
@rbell-mfj yeah that is sometimes the case for me |
|
The Can someone with this issue try running your tests with debug logs enabled, and share those logs here? It will show the cookie being parsed and from there I can isolate and reproduce the issue.
Make sure to scrub any private data from the logs before sharing here. |
|
@flotwig here's the DEBUG log output from an isolated repro test case |
|
@rbell-mfj thank you for the workaround. I tried it and it worked for me 👍 |
|
Hey @todd-m-kemp - I am trying to reproduce your issue using Cypress 5.4.0 and am getting a more descriptive error:
However, I think that Cypress should accept this malformed response and just ignore Content-Length, as the RFC calls for, since that is the behavior of a normal web browser (Node.js discussion here: nodejs/node#7136) |
|
To expand on the Node.js discussion:
Although RFC 7230 supersedes RFC 2616, RFC 7230 only recommends erroring because the redundant header may be an indicator of HTTP request smuggling, which is not a concern in Cypress, since Cypress's security model assumes that you have full control of the destination web server. I am not sure if Node.js exposes a way to bypass this behavior, but I can look into it. |
2 tasks
cypress-bot
bot
added
stage: work in progress
cypress-bot
bot
added
stage: pending release
|
The code for this is done in cypress-io/cypress#8896, but has yet to be released. |
|
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
cypress-bot
bot
removed
the
stage: pending release
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current behavior:
Some (but not all) of my calls
cy.visitare failing with a genericParse Errorwhen I haveexperimentalNetworkStubbingturned on. One such failing call is in the provided below.Desired behavior:
Calls to
cy.visitsucceed regardless of whether or notexperimentalNetworkStubbingis on.Test code to reproduce:
Versions:
Cypress version 5.1.0 on macOS 10.14.6 using Chrome 85.
The text was updated successfully, but these errors were encountered: