Custom HTTP Response Status Text's are being lost when using TestCafe's and Hammerhead

[AnonDeveloper-js]

What is your Scenario?

We're trying to use Testcafe to implement automated testing of a NodeJS website. The website uses AJAX requests to communicates with a RESTful API which leverages custom HTTP status text's for some of it's API responses (mainly failure responses). The website client then uses these custom HTTP Status codes to determine which error handler should be used to display the failure.

The issue we are running into is that the custom HTTP status texts returned from the API are being buried by the Hammerhead proxy wrapper. The attached screenshot shows the problem; the same API request and subsequent responses are returning a different HTTP status text when ran using Testcafe.

We really need these custom HTTP Status texts to persist.

What is the Current behavior?

Custom HTTP status text's (messages) are being defaulted to their standard values for their matching HTTP Status Codes.

What is the Expected behavior?

The original, custom HTTP Status Text's (messages) from the API responses need to be retained.

What is your public website URL? (or attach your complete example)

N/A (can't provide)

What is your TestCafe test code?

N/A

Your complete configuration file

{ "browsers": ["chrome --window-size=1900,1020"], "speed": 0.6, "skipJsErrors": true, "disablePageCaching": true, "reporter": ["spec"], "screenshots": { "path": "tests/artifacts/screenshots/", "pathPattern": "${DATE}_${TIME}/${USERAGENT}/${TEST}-${FILEINDEX}.png", "thumbnails": false, "takeOnFails": true }, "videoPath": "tests/artifacts/videos/", "videoOptions": { "pathPattern": "${DATE}${TIME}/${USERAGENT}/${FILE_INDEX}.mp4", "singleFile": true, "takeOnFails": true } }

Your complete test report

N/A

Screenshots

I have had to obfuscate the API address, but I can confirm that in the above screenshot both API addresses are the exact same. The first screenshot shows the API response when using the RAW website. The second screenshot shows the API response when using Testcafe with website's API requests wrapped via Hammerhead.

Steps to Reproduce

Write a test to ping a webserver which returns a HTTP 400 response with a custom status text / message.

TestCafe version

2.0.1

Node.js version

16.17.0

Command-line arguments

testcafe chrome test.js

Browser name(s) and version(s)

Chrome 106.0.5249.119 x64

Platform(s) and version(s)

Windows 10 x64

Other

No response

[Dmitry-Ostashev]

Thank you for your report. I reproduced the issue in the following ExpressJS simple app:

const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
    res.statusMessage = 'Custom status text';
    res.status(400).end();
});

app.listen(port, () => {
    console.log(\\`Example app listening on port ${port}\\`)
});

[miherlosev]

Hi @AnonDeveloper-js,

TestCafe runs tests using the URL-rewritten proxy. This approach is good. However, there is a way to improve the stability and speed of test execution - the native browser automation API. We have a test execution mode uses native browser automation - we call it the Proxyless mode. In Proxyless mode, a few issues are already fixed. By the way, this issue was also fixed in Proxyless mode. Try running your tests in Proxyless mode and let us know the results. This option is available in all interfaces:

// Command-line
testcafe chrome tests --experimental-proxyless

// Programmatic
const testcafe = await createTestCafe({ experimentalProxyless: true });

// Configuration file
{
   "experimentalProxyless": "true"
}   

Note that at present it is an experimental mode. Also, the Proxyless mode is implemented only in Google Chrome. It will not work correctly if you run tests in a non-Chrome browser or in a combination of other browsers.

[miherlosev]

Hi @AnonDeveloper-js,

This issue is not reproduced with combination of testcafe@3.0.1 and the Google Chrome browser. Feel free to reopen this issue if you encounter it in other browsers.