Cypress removes custom status text/reason phrase from http response

[mattiaskagstrom]

Current behavior

Server responds with a http 400 with the text "Åtgärden kan inte vara utförd innan bristen upptäcktes."
generated by the code
var resp = new HttpResponseMessage(HttpStatusCode.BadRequest) { Content = new StringContent(""), ReasonPhrase = "Åtgärden kan inte vara utförd innan bristen upptäcktes." };
in C# for .NET 4.8
Cypress then strips that text and returns http.STATUS_CODES[400]

shows up in Chromiums network tab as:

The only other resource I found about this issue was this:
https://stackoverflow.com/questions/63050722/cypress-not-receiving-custom-status-text

Desired behavior

The status text /reason phrase should be forwarded as is to the client.

running outside of Cypress, Chromium shows this

Versions

Running Cypress 5.6.0. Unable to upgrade to 6+ due to #14447
Chromium Version 90.0.4427.0
Windows 10 Enterprise 2004
Cypress-ntlm-auth 3.2.2-beta.1 (bjowes/cypress-ntlm-auth#175)

[mattiaskagstrom]

Same issue with Cypress 7.5.0

[sainthkh]

It's happening because Cypress normalizes the statusMessage in the code below:

cypress/packages/server/lib/request.js

Lines 499 to 505 in 8550842

	_.extend(response, {
	// normalize what is an ok status code
	statusText: statusCode.getText(response.status),
	isOkStatusCode: statusCode.isOk(response.status),
	requestHeaders: getOriginalHeaders(req),
	requestBody: req.body,
	})

It's been added at 4/21/2017 by @chrisbreiding (23209b2).

It's not hard to fix this but I'm not sure it's OK to do so.

[Jeje2201]

Up, Im needing this, or at least an option to trigger if yes or no I want my custom header message

[flotwig]

I think this would be fine to open a PR for if someone wants to fix this. I don't think we should be messing with the statusText here.

[HughParsons]

I found a work around for this issue which allows defining a custom statusText and statusCode simultaneously by first stubbing the response with a staticResponse and then modifying that response with a routeHandler:

cy.intercept("PUT", "/url", { statusCode:422 });
cy.intercept("PUT", "/url", (req) => {
  req.on("before:response", (res) => {
    res.statusMessage = "ConcurrentLiveEvent";
    res.send();
  });
});

This also works using req.reply() within a routeHandler in the first intercept.

[kshastri]

I would like to take this up and drill down more into it. Kindly let me know whether the approach proposed by @Jeje2201 can be taken forward?

[flotwig]

@kshastri Yes, please feel welcome to open a PR and tag me if you need help or a review.

The solution that I would like to see implemented would involve our proxy not manipulating the "reason phrase" at all. The proxy should transparently proxy the reason phrase - if the server sends an empty phrase, we should proxy an empty phrase, if the server sends "200 foo", we should proxy "200 foo".

I think you'll most likely be able to make this happen inside of response-middleware.ts in packages/proxy. You can test it in that package or in the http_requests_spec file within the packages/server tests.

Up, Im needing this, or at least an option to trigger if yes or no I want my custom header message

I don't think we need an option, this behavior is pretty universally undesirable from a proxy.

[flotwig]

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

[cypress-bot]

Released in 10.2.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v10.2.0, please open a new issue.