Cypress returns 500 error on successful 304 responses from rails server for application/x-javascript requests
Closed this issue · 2 comments
Current behavior:
Calling visit() or click() that triggers subsequent internal resource calls will fail for resources that are returning 304 status codes on application/x-javascript content-types.
Desired behaviour:
The expected behaviour would be for Cypress to properly return the cached javascript files upon receiving a 304 status code from a backend server rather than producing 500 server errors in the chrome debugger.
Steps to reproduce:
As the steps to reproduce are not contained to Cypress scenarios the following describes the environment and actions that appear to be non coincidental triggers that cause this issue in Cypress.
The environment in question is running a Rails server. In this case the request is a routed request on the server such that templates are used to generate the final javascript response body for the initial 200 status responses.
Urls are of the form:
http(s)://some.automation.site/page/js_dyn_gen
Subsequent request to the same url are sending valid etags in the request header and the server does process and respond using the described Rails statement below.
head :not_modified
The tests involved in creating this particular issue were essentially login-logout-login with the same user. Due to required architecture these javascript files are also requested on most subsequent login action requests as both the user and administrators can make changes that effect the dynamically generated content in the javascript files. So lots of 304's until a preference change.
Login scenarios are written to use elements on the page directly rather than routes to mimic user interaction as closely as possible.
Further Testing Details
It is important to note that Cypress was chosen as it allows testing of functionality using only UI elements found on the page. These were the test cases we were trying to rebuild using Cypress. Other direct test using routes and the such are readily available through other more low level frameworks. So our tests mainly focus on using .click() and .visit() events to trigger url requests on the server.
All browsers tested directly correctly process this response as a 304 and do use a valid cached version of the generated javascript from the previously successful 200 response.
It was noticed that files such as .woff do correctly return from service 304 status codes in Cypress testing runs. Also Cypress setup js files also correctly return on 304's too!
Removing etag caching on the server completed the requests successfully but as 200 responses. This is not feasible from an architectural standpoint.
Attempts to override cached requests in cypress using Cypress.$.ajaxSetup({cache:false}) as ajaxSetup was not made visible to the end user through the Cypress JQuery wrapper. Even if we could turn off xhr caching it would seem a little bit like cheating.
Using static fixtures in place for these files and loading them in place using the following mechanism did work but also overrides any successful 200 result the server may respond with say if preferences were changed and the site reloaded.
beforeEach(() => {
Cypress.config("js_stub", cy.fixture("js/js_stub.js"))
Cypress.on("window:before:load", win => {
Cypress.$("head").prepend(Cypress.config("js_stub"));
...
})It does seem feasibly possible to dynamically load these javascript paths as requests at key times and store 200 status responses as fixtures. To do so would mean that every visit() / click() would require a test request() to validate whether the xhr response was a 200 or 500 error. At which point finding a 500 error would result in using the fixture. And although this seems possible, how is one to know if the 500 error was due to a 304 or a real 500? So big assumptions would be made about the outcomes of the servers response.
Versions
The current issue was found with Cypress Beta 3.1.0 using both Chrome 69 and Electron 59 browsers
I see that you are using an older version of Cypress. Before I dive in to completely recreate the issue, could you update to the current version of Cypress and let me know if this is still happening for you? Your issue may have already been fixed. Thanks!
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.