Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse Error on DELETE request #1398

Closed
albertored opened this issue Mar 1, 2018 · 7 comments

Comments

5 participants
@albertored
Copy link

commented Mar 1, 2018

Current behavior:

My page send a DELETE request with a json body to the server that correctly respond with status 204 and empty body (I verified it both on server logs and using wireshark)

cypress instead show a 500 status in the command log and if I print the response body with

cy.wait('@deleteApn').then(xhr => {
    cy.exec(`echo ${JSON.stringify(xhr.response.body)} > aaa.json`)
})

I get

<!DOCTYPE html>
<html>
<body>
Cypress errored attempting to make an http request to this url:
http://172.17.102.170:3000/nc/api/apn/
The error was:
Parse Error
The stack trace was:
Error: Parse Error
    at Socket.socketOnData (_http_client.js:454:20)
    at emitOne (events.js:115:13)
    at Socket.emit (events.js:210:7)
    at addChunk (_stream_readable.js:252:12)
    at readableAddChunk (_stream_readable.js:239:11)
    at Socket.Readable.push (_stream_readable.js:197:10)
    at TCP.onread (net.js:589:20)
</body>
</html>
  • Operating System: Debian 9 virtual machine
  • Cypress Version: 2.0.4
  • Browser Version: electron 59
@brian-mann

This comment has been minimized.

Copy link
Member

commented Mar 1, 2018

This is likely a bug in Cypress but it's likely your server doing something funky to cause it.

My guess is that your server is sending back something like: Content-Type: application/json but then sending an empty response body (which is invalid). Cypress should probably handle this instead of dying - but we need to be able to reproduce this in order to fix it.

Can you send us the response exactly from your server - including headers and body. You could export as HAR. Even sending what it looks like when you work outside of Cypress would be enough for us to mimic and likely reproduce.

If what I suspect is the problem it will be easy to fix and we can get a patch out.

@albertored

This comment has been minimized.

Copy link
Author

commented Mar 1, 2018

Thanks for your reply. Yes, it is indeed an error in my server, it was sending a non empty body with status 204 that is forbidden, 204 responses must have empty body.

It would be nice if cypress could handle it without dying or maybe just showing a better error message. If you only watch the command log you a see a 500 response that seems to be sent from the server. Only a check of the actual response body shows the real error.

If you still need the response tomorrow I will send it but you can easily reproduce it by having a 204 response with any non empty body.

@pietmichal

This comment has been minimized.

Copy link

commented May 24, 2018

Cypress should just accept browser's behaviour instead of altering status codes even when the response isn't technically correct.

@lgt1001

This comment has been minimized.

Copy link

commented Jul 11, 2018

is this defect fixed?

we also face this on RedHat 7.2
Cypress 3.0.2
google-chrome-stable-64.0.3282.140-1

{ Error: Parse Error
    at Error (native)
    at TLSSocket.socketOnData (_http_client.js:361:20)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at TLSSocket.Readable.push (_stream_readable.js:134:10)
    at TLSWrap.onread (net.js:543:20)
 bytesParsed: 0, code: 'HPE_INVALID_CONSTANT' }
Error: Parse Error
    at Error (native)
    at TLSSocket.socketOnData (_http_client.js:361:20)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at TLSSocket.Readable.push (_stream_readable.js:134:10)
    at TLSWrap.onread (net.js:543:20)
@brian-mann

This comment has been minimized.

Copy link
Member

commented Jul 11, 2018

It is not fixed yet. If we have to put together a reproducible repo, and we analyze that only a few users are affected, then we don't really prioritize these fixes over other ones.

To be clear, we have our team working full time on Cypress (and we're adding more resources) but we cannot fix everything immediately in the order that everyone wants fixed.

If you want us to prioritize things, then having a cloneable repo that's immediately demonstrating the problem that we can instantly extract into a test and fix the issue, that would make a big difference in how quickly we get to the problem. As it stands, us having to recreate it and doing the legwork and research often accounts for hours of work per issue. Sometimes we're never able to recreate and issues will sit until someone does. I don't think this issue would be the case, but this is the truth of the matter.

Of course, PR's are always welcome, but even without one, we'll eventually fix this issue at some point.

@cypress-bot

This comment has been minimized.

Copy link

commented May 17, 2019

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

@cypress-bot

This comment has been minimized.

Copy link

commented May 17, 2019

Released in 3.3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.