Response is modified by cypress #2599

yuki-93 · 2018-10-12T14:23:23Z

Sometimes cypress seems to modify the responses from my server. This happens if I use a (virtual) host to simulate an other server than localhost. After the html output is the expected output from my request (the json part at the end).

<head> 
  <script type='text/javascript'> 
    document.domain = 'localhost'; 
    var Cypress = window.Cypress = parent.Cypress; 
    if (!Cypress){ 
      throw new Error('Something went terribly wrong and we cannot proceed. We expected to find the global Cypress in the parent window but it is missing!. This should never happen and likely is a bug. Please open an issue!'); 
    }; 
    Cypress.action('app:window:before:load', window); 
  </script> 
</head>
{"success":true,"msg":"my response string"}

jennifer-shehane · 2018-10-12T16:06:22Z

@FlorianM93 Could you be more specific about what modifications are done to responses that is causing issues?

yuki-93 · 2018-10-12T18:36:13Z

@FlorianM93 Could you be more specific about what modifications are done to responses that is causing issues?

The pasted code above is the response I got from a GET in my application. So the cypress runner somehow wraps the html-document into that response.

jennifer-shehane · 2018-10-12T23:46:48Z

Could you paste your test code (omitting sensitive urls if needed)? Also, the request headers / response headers of the request that's doing this?

yuki-93 · 2018-10-15T06:51:31Z

The failing code (there is a comment, where my applicaiton crashes)

describe('Test Fail', () => {
    before(() => {
        cy.visit('#dashboard').then(() => {
            cy.get('.x-window', {timeout: 25000}).contains('Login').should('be.visible');
            cy.get('.x-panel').within(() => {
                cy.get('input:first').type('user');
                cy.get('input:last').type('password');
                cy.get('.x-btn').click();
            });

            // after login, the first request (login successful) from my main application fails
            cy.get('.main-header-logo', {timeout: 25000}).should('be.visible');
        });
    });
    
    it.only('should upload the test data', () => {
        cy.title().should('be', 'Page Title');
    });
});

Request Headers:

POST http://localhost/myapp/login.php HTTP/1.1
Host: localhost
Proxy-Connection: keep-alive
Content-Length: 43
Origin: http://localhost
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/69.0.3497.81 Chrome/69.0.3497.81 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: */*
Referer: http://localhost/myapp
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: __cypress.initial=true

Response Headers:

HTTP/1.1 200 OK
date: Mon, 15 Oct 2018 06:44:47 GMT
server: Apache/2.4.18 (Ubuntu)
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-cache, no-store, must-revalidate
pragma: no-cache
connection: close
content-type: text/html; charset=UTF-8
Set-Cookie: PHPSESSID=foobar; path=/
Set-Cookie: __cypress.initial=; Domain=localhost; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Transfer-Encoding: chunked

jennifer-shehane · 2018-10-15T22:53:06Z

I see you posted the request headers for a POST endpoint, but your original issue outlined a problem with the response returned from a GET endpoint. Am I missing something?

I wish something were standing out more in the information you provided as the obvious problem, but we'll likely need a reproducible repo to get debugging started on this.

As a side note, you should not need the .then chained off of cy.visit(), the next command will not run until the load event is fired from visiting the page.

yuki-93 · 2018-10-16T06:37:21Z

Ah right, it's a POST not a GET request.

Thanks for the note with the visit and then.

yuki-93 · 2018-10-16T06:39:45Z

Sadly I have no public repo to publish for you :(

Maybe I can try to build an example later

yuki-93 · 2018-10-16T09:16:06Z

I figured out that it looks like a timing issue. My app only crashed for a producation build, which has minified JS. When I use a non minified build, then cypress runs normally.

So it looks like my app loads 'to fast' so that cypress is not correctly setted up?

yuki-93 · 2018-10-17T12:01:19Z

Hello again...

Ok this issue seems to be partially a cypress (injecting the cypress code into received request data) and partially an application issue (using appcache and setting content-type text/html on json).

Cypress doesn't properly work with web applications that use an appcache. Cypress fails to insert the __cypress.initial=true cookie due to the index page being cached in the appcache.

If you run the app with a cleared appcache, the index.html is correctly loaded and the cypress-loader properly injected. On the second run the index.html is used from the cache, where cypress fails to add the __cypress.initial cookie and thus delaying it to the first response with content-type text/html to a request with the __cypress.initial cookie (in our example it was the returned json).

Now if there's some XHR response with content-type text/html and the __cypress.initial, cypress injects it's loader code, regardless of it being a dynamically loaded HTML-snippet. This might probably result in event/action app:window:before:load triggering multiple times.

One would expect cypress to inject itself always into the visited application's index file and not into subsequent XHR-responses, potentially altering behavior.

Attached there's an example app and test spec to exhibit the behavior, described here.
dist.tar.gz

bahmutov · 2018-10-17T12:18:50Z

That’s really interesting information, good debugging

…

Sent from my iPhone

On Oct 17, 2018, at 08:01, Florian Macherey ***@***.***> wrote: Hello again... Ok this issue seems to be partially a cypress (injecting the cypress code into received request data) and partially an application issue (using appcache and setting content-type text/html on json). Cypress doesn't properly work with web applications that use an appcache. Cypress fails to insert the __cypress.initial=true cookie due to the index page being cached in the appcache. If you run the app with a cleared appcache, the index.html is correctly loaded and the cypress-loader properly injected. On the second run the index.html is used from the cache, where cypress fails to add the __cypress.initial cookie and thus delaying it to the first response with content-type text/html to a request with the __cypress.initial cookie (in our example it was the returned json). Now if there's some XHR response with content-type text/html and the __cypress.initial, cypress injects it's loader code, regardless of it being a dynamically loaded HTML-snippet. This might probably result in event/action 'app:window:before:load' triggering multiple times. One would expect cypress to inject itself always into the visited application's index file and not into subsequent XHR-responses, potentially altering behavior. Attached there's an example app and test spec to exhibit the behavior, described here. dist.tar.gz — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

yuki-93 · 2018-10-24T06:54:31Z

@bahmutov @jennifer-shehane do you have any progress or time here, when this might get fixed? :)

devsh4 · 2018-11-02T15:55:54Z

Facing the same issue. Would be great if it gets fixed soon. This bug doesn't necessarily stop me from testing my app further (atleast for now), but still should be fixed.

jennifer-shehane · 2018-11-02T19:39:12Z

Thanks for narrowing this issue down for us.

Would it be correct to say that things would work well for your use case if Cypress were to clear appcache before each it test instead of persisting across tests?

yuki-93 · 2018-11-02T20:36:55Z

Not fully. The problem is, for the second (and all other) run of the tests, the index.html is cached by browser. So cypress doesn’t plug in there but into the next “file” which here is an XHR response.

chincheeheng · 2021-02-03T08:48:25Z

Testing with the 6.4.0 version, when download CSV with click, the file injected with header.

Response Header
HTTP/1.1 200 OK
Server: nginx/1.19.1
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Content-Description: File Transfer
Content-Disposition: attachment; filename=xxxxxxxxxxx.csv
Content-Transfer-Encoding: binary
Expires: 0
Cache-Control: must-revalidate, post-check=0, pre-check=0
Pragma: public
Cache-control: no-store, max-age=0, no-cache
X-FRAME-OPTIONS: sameorigin
Content-Encoding: gzip

jennifer-shehane · 2021-02-04T06:21:25Z

@chincheeheng This is expected behavior. We have to inject this to run Cypress.

Since this issue hasn't had activity in a while, we'll close the issue until we can confirm this is still happening. Please comment if there is new information to provide concerning the original issue and we'd be happy to reopen.

chincheeheng · 2021-02-04T06:23:01Z

@chincheeheng This is expected behavior. We have to inject this to run Cypress.

Since this issue hasn't had activity in a while, we'll close the issue until we can confirm this is still happening. Please comment if there is new information to provide concerning the original issue and we'd be happy to reopen.

This will be a problem when we try to run download, when the thing injected to csv file, then the validation will not work.
May you advise? this related to the download file test.

jennifer-shehane · 2021-02-04T09:10:57Z

@chincheeheng Can you provide a basic example in a newly opened issue? HTML + cypress code where your validation is failing? Thanks!

marcospoliceno · 2022-10-10T12:52:47Z

cypress ainda tem esse problema

retorna o download CSV com o HTML <script type='text/javascript'> document.domain = .....
e não com a integridade do arquivo CSV
impossibilitando a validação do arquivo

jennifer-shehane added the stage: needs information Not enough info to reproduce the issue label Oct 12, 2018

cypress-bot bot added stage: needs investigating Someone from Cypress needs to look at this and removed stage: needs information Not enough info to reproduce the issue labels Mar 6, 2019

jennifer-shehane added the type: bug label Jul 24, 2019

jennifer-shehane closed this as completed Feb 4, 2021

jennifer-shehane removed the stage: needs investigating Someone from Cypress needs to look at this label Feb 4, 2021

Bohdan-Kalynovskyi mentioned this issue Oct 25, 2022

Getting '<head><script...' instead of data in response to XHR request #24395

Open

AtofStryker mentioned this issue Oct 28, 2022

Explore X-Cypress-Is-AUT-Frame over __cypress.initial cookie #24446

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Response is modified by cypress #2599

Response is modified by cypress #2599

yuki-93 commented Oct 12, 2018 •

edited by jennifer-shehane

jennifer-shehane commented Oct 12, 2018

yuki-93 commented Oct 12, 2018

jennifer-shehane commented Oct 12, 2018

yuki-93 commented Oct 15, 2018 •

edited

jennifer-shehane commented Oct 15, 2018

yuki-93 commented Oct 16, 2018

yuki-93 commented Oct 16, 2018

yuki-93 commented Oct 16, 2018

yuki-93 commented Oct 17, 2018 •

edited by jennifer-shehane

bahmutov commented Oct 17, 2018 via email

yuki-93 commented Oct 24, 2018

devsh4 commented Nov 2, 2018 •

edited

jennifer-shehane commented Nov 2, 2018

yuki-93 commented Nov 2, 2018

chincheeheng commented Feb 3, 2021 •

edited

jennifer-shehane commented Feb 4, 2021

chincheeheng commented Feb 4, 2021

jennifer-shehane commented Feb 4, 2021

marcospoliceno commented Oct 10, 2022

Response is modified by cypress #2599

Response is modified by cypress #2599

Comments

yuki-93 commented Oct 12, 2018 • edited by jennifer-shehane

jennifer-shehane commented Oct 12, 2018

yuki-93 commented Oct 12, 2018

jennifer-shehane commented Oct 12, 2018

yuki-93 commented Oct 15, 2018 • edited

jennifer-shehane commented Oct 15, 2018

yuki-93 commented Oct 16, 2018

yuki-93 commented Oct 16, 2018

yuki-93 commented Oct 16, 2018

yuki-93 commented Oct 17, 2018 • edited by jennifer-shehane

bahmutov commented Oct 17, 2018 via email

yuki-93 commented Oct 24, 2018

devsh4 commented Nov 2, 2018 • edited

jennifer-shehane commented Nov 2, 2018

yuki-93 commented Nov 2, 2018

chincheeheng commented Feb 3, 2021 • edited

jennifer-shehane commented Feb 4, 2021

chincheeheng commented Feb 4, 2021

jennifer-shehane commented Feb 4, 2021

marcospoliceno commented Oct 10, 2022

yuki-93 commented Oct 12, 2018 •

edited by jennifer-shehane

yuki-93 commented Oct 15, 2018 •

edited

yuki-93 commented Oct 17, 2018 •

edited by jennifer-shehane

devsh4 commented Nov 2, 2018 •

edited

chincheeheng commented Feb 3, 2021 •

edited