Testcafe: Server responses with status 222 unexpectedly when window.fetch() is called in Chrome

[dzannotti]

Are you requesting a feature or reporting a bug?

Reporting a possible bug

What is the current behavior?

Some requests in chrome seem to return 222 from the proxy and no json content, however the same tests work correctly in firefox and safari. There don't seem to be major differences investigating curl differences which sort of leads me to believe it's a chrome fetch related issue

What is the expected behavior?

That a page with a third party xhr request works consistently in browser.

How would you reproduce the current behavior (if this is a bug)?

Do not have a repro currently, it seems that xhr requests in chrome are not currently working

Specify your

• operating system: macOS Sierra 10.12.1
• testcafe version: 0.11 and 0.12-alpha5
• node.js version: 7.1

[AndreyBelym]

Hello, Daniele! Please, can you give us some more information about your issue: the Chrome version, your test code and the tested page URL or source code?

[AlexanderMoskovkin]

@dzannotti, Also It possible that some chrome extension breaks test running. Please try to run it in the incognito mode:
testcafe "chrome --incognito" your-test.js

[dzannotti]

Hi Thanks for the support, trying to put together a repro. It's definitely not extensions breaking (as it has the same behaviour in incognito/on ci. The weird thing is the 222 http codes from the testcafe proxy

[AlexanderMoskovkin]

Could you please provide us URL to your tested page or create a simple example to reproduce the problem on our side?

[Darmody]

Met the same problem.

When I make a request window.fetch('http://locahost:3000/api/current_user'),
it will actually call http://10.254.254.254:64304/B1tIW9A9e/http://localhost:3000/api/current_user

[AlexanderMoskovkin]

Hi,

When I make a request window.fetch('http://locahost:3000/api/current_user'),
it will actually call http://10.254.254.254:64304/B1tIW9A9e/http://localhost:3000/api/current_user

It's ok because testcafe works via its own proxy, so it sends requests to the proxy (10.254.254.254:64304) and the proxy sends them to your web app server (localhost). Does it break your application during testing?

[Darmody]

@AlexanderMoskovkin Hi. I only get an unknow response.

Request URL:http://10.254.254.254:64899/B1weE9Acl/http://localhost:3000/api/aliyun_oss
Request Method:GET
Status Code:222 unknown
Remote Address:10.254.254.254:64899

[AlexanderMoskovkin]

@Darmody Is it possible to share your application or create a simple example to reproduce the problem on our page? Or maybe you can give us some tips to create the same simple application to reproduce the problem? It's too hard to determine the cause of the problem without a page

[Darmody]

@AlexanderMoskovkin After run testcafe, you can directly call window.fetch() in the chrome console, and I think you will see the same thing.

[AlexanderMoskovkin]

It works ok on the simple page on my side. I think the problem is specific to your backend realization.

[Darmody]

@AlexanderMoskovkin Hm.. could you show me the response? Maybe I missed some headers?

[Darmody]

the request too, thank you. @AlexanderMoskovkin

[AlexanderMoskovkin]

https://www.screencast.com/t/JTqk1YJr

[Darmody]

Request URL:http://10.254.254.254:50483/SybX1iCce/http://localhost:3000/api/current_user
Request Method:GET
Status Code:222 unknown
Remote Address:10.254.254.254:50483
Response Headers
view source
Connection:keep-alive
Content-Length:0
Date:Thu, 09 Mar 2017 09:24:08 GMT
Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
authorization:
Cache-Control:no-cache
Connection:keep-alive
content-type:application/json
Host:10.254.254.254:50483
Pragma:no-cache
Referer:http://10.254.254.254:50483/SybX1iCce/http://localhost:8080/merchant
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
x-hammerhead|fetch|request-credentials:include
x-hammerhead|xhr|origin:http://localhost:8080

Above is the infomation about request.

It is a cors json API call, and I use rails as backend

[Darmody]

@AlexanderMoskovkin thank you

[Darmody]

does json api call cause the problem?

[AlexanderMoskovkin]

Could you please provide the same info (request,response) when you call this on the original page (without testcafe)

[Darmody]

Request URL:http://localhost:3000/api/current_user
Request Method:GET
Status Code:200 OK
Remote Address:[::1]:3000
Response Headers
view source
Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Origin:http://localhost:8080
Access-Control-Expose-Headers:X-Total, X-Per-Page, X-Page
Access-Control-Max-Age:1728000
Cache-Control:max-age=0, private, must-revalidate
Content-Type:application/json; charset=utf-8
ETag:W/"651970599faff1ffff31ec2c64dc8a8f"
Set-Cookie:_jxcat_session=cVkvWTBOOHFTK09kZkdhd2tqcGZ5U3VCUXJNckFqMi9nNTRURnlRMTVXZzZ6Und3L3c0T09HSjZ1N1FlaWdQT0hDTFk1dnFVdjRLT1lveW9Rc2J2L0tzemRFTG1hNWl3S0hjSEhSMkZmclcwbmhBOGpyK0w2ZmtOUXlTTktqTDJTcWpUZGZMSzA5L2NTT1NHSkhncnJZVHZUWjhWTytsQmRRMlB0V1lSNGRMVkhmRklrME9qczFLRjdyR3dNSlBkLS1hcTZvZHNIV0pTeXdNcjZjWVVHN1l3PT0%3D--3ed6cda5f2910a057f06cb02535ea462f825d0bc; path=/; HttpOnly
Transfer-Encoding:chunked
Vary:Origin
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:f437c702-e5f6-45bb-9d54-315338908b38
X-Runtime:0.731044
X-XSS-Protection:1; mode=block
Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
authorization:
Cache-Control:no-cache
Connection:keep-alive
content-type:application/json
Cookie:oss_policy=eyJleHBpcmF0aW9uIjoiMjAxNy0wMy0xMFQwNzo0OTo1My43NTRaIiwiY29uZGl0aW9ucyI6W3siYnVja2V0IjoianhjYXQtbmV3LWRldiJ9XX0=; oss_signature=Puxpjyl6ZPXk1nZe9gSGPiCkJ1s=; _jxcat_session=aXpRVlBUek9ZYkMzakxteXFCVm5PZ0VWTVQzVzBRcTVpKzZVSDRlenNXcVphTnFvc2RySncrbU1ncmlWMThkMkErc3laenA5NFlmY1J0d2JiRFZkd21VdWIxc2Q5R2g4czN5eStWS1lyY090NnJjTkhqOWlQcEZ1T2xiV1VFcWJQMm0wNTRTemdDL3RWUldodjdjVDZNajRkb1hzR3Vvb0lvZkRoWUN4YjdNZE94SWNxRW05TlVuQ1I5QWZDOE4xLS1vTDUvSFFESVBscTc4ak82UXJPRitBPT0%3D--f9f853eac2f4f21bf16f3ebef44d128c4b93dd5e
Host:localhost:3000
Origin:http://localhost:8080
Pragma:no-cache
Referer:http://localhost:8080/admin/shop_applies
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

[AlexanderMoskovkin]

Thanks for the info. We'll try to investigate it. If we need some more info we will write you.
Please notify us if you will find something on your side

[Darmody]

OK! That's cool.

[LavrovArtem]

Hi @Darmody

I investigated this problem and I think that it relates with the our CORS emulation. We response with the 222 status code if the CORS conditions are failed. I figured out that our proxy does't send the origin header to the origin site. I guess that the problem may be in this. Can you please check out my guess?

[Darmody]

@LavrovArtem Hi. This is my sever-side setting:

I don't limit origin, right?

[LavrovArtem]

@Darmody thanks for information. I've reproduced this problem and I've created an issue: Wrong CORS emulation

[Darmody]

@LavrovArtem cool

[AndreyBelym]

Hello @Darmody! We've just released the new TestCafe alpha version that fixed your issue! You can try it by executing npm install testcafe@alpha. So I'm closing the issue, but feel free to reopen it if the fix didn't help you!

[Darmody]

@AndreyBelym awesome!

[RichiCoder1]

I'm running into this issue w/ Alpha still. It looks like the proxy is stripping the Content-Type header off the fetch

[RichiCoder1]

Update: Switching from Aurelia's fetch client to raw fetch fixed it????

[miherlosev]

It looks like the proxy is stripping the Content-Type header off the fetch

I am trying to reproduce this behavior on the latest version of the proxy and all works right.
See video.
Example to reproduce - 1134.zip

Could you provide an example that reproduces the problem, please.

[RichiCoder1]

@miherlosev It's weird. Normal fetch works fine, but aurelia-fetch-client fails with the header getting stripped off. I plan to look into it to see why.

[miherlosev]

It looks like the proxy is stripping the Content-Type header off the fetch

I think I've reproduced your problem. See https://github.com/DevExpress/testcafe-hammerhead/issues/1116

[RichiCoder1]

@miherlosev Awesome! Sorry for the vague repro steps.

[Gpx]

Hi there, I'm running in this problem when I try to execute a fetch to my backend.

Playing around with it I found out that the problem doesn't happen if I remove the header x-hammerhead|fetch|request-credentials: include. Weirdly enough x-hammerhead|xhr|origin: http://localhost:3000 doesn't cause issues.

I'm trying to figure out if it's a problem on testcafe's side or my server.

I have this issues in Chrome, Firefox, and Safari. I couldn't test with other browsers.

Do you have any idea what could be the problem?

[Gpx]

Update: if I call my server directly there's no problem. If I call it through testcafe I encounter the issue.

$ http POST 'http://192.168.2.79:53431/reyoV8nEl/http://localhost:1234/be-mock/api-login/' 'Origin: http://192.168.2.79:53431' 'Accept-Encoding: gzip, deflate' 'Accept-Language: en-US,en;q=0.9' 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36' 'content-type: application/json' 'Accept: */*' 'Referer: http://192.168.2.79:53431/reyoV8nEl/http://localhost:3000/login' 'x-hammerhead|fetch|request-credentials: include' 'x-hammerhead|xhr|origin: http://localhost:3000' 'Connection: keep-alive' [email protected] password=password
HTTP/1.1 222 unknown
Connection: keep-alive
Content-Length: 0
Date: Wed, 11 Jul 2018 10:44:49 GMT



$ http POST 'http://localhost:1234/be-mock/api-login/' 'Origin: http://192.168.2.79:53431' 'Accept-Encoding: gzip, deflate' 'Accept-Language: en-US,en;q=0.9' 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36' 'content-type: application/json' 'Accept: */*' 'Referer: http://192.168.2.79:53431/reyoV8nEl/http://localhost:3000/login' 'x-hammerhead|fetch|request-credentials: include' 'x-hammerhead|xhr|origin: http://localhost:3000' 'Connection: keep-alive' [email protected] password=password
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://192.168.2.79:53431
Connection: Keep-Alive
Content-Length: 259
Date: Wed, 11 Jul 2018 10:45:03 GMT
Server: WEBrick/1.3.1 (Ruby/2.2.2/2015-04-13) OpenSSL/1.0.2d

{"token":"token123"}

[MarinaRukavitsyna]

@Gpx
Would you please create har files with and without TestCafe and send them to us?

[Gpx]

Hi @MarinaRukavitsyna the problem was that I was not configuring CORS correctly when making the request

[maheshjag]

I've got the same problem, and in my case, the issue might be that the proxy is not sending the correct cookies in the header. In my TestCafe terminal, I see the following cookies:

s_cc=true; already-seen-banners=cookie-wrapper;

However, when the XHR request goes out from the browser, the headers I see are

Cookie: c|QJwZZyXVg|s_sq|localhost|%2F||jn4ejelu=bskybfandwtvdev%3D%2526pid%253Dwatch%25253Apanels%25253Adelicious%2526pidt%253D1%2526oid%253Dfunction%252528%252529%25257B%25257D%2526oidt%253D2%2526ot%253DA

and the response is

Request URL: http://10.155.130.10:57807/QJwZZyXVg/http://localhost:5201/remotedownload/download/3830670
Request Method: POST
Status Code: 222 unknown
Remote Address: 10.155.130.10:57807
Referrer Policy: no-referrer-when-downgrade

[miherlosev]

@maheshjag

I am afraid this information is not sufficient to reproduce. Could you please provide a page or a small example so that we can reproduce it on our side?

[maheshjag]

Thanks for the quick response, @miherlosev, much appreciated! 😃

Here's the test code:

const appUrl = `http://localhost:${appPort}/watch`;

test.only('should request a download', async (t) => {
    await t
        .useRole(loggedInUser(appUrl))
        .navigateTo(appUrl);

    await setupMock(REMOTE_DOWNLOAD_URI, 'POST', { error: null, ok: 1 }, epgPort);
    await clickRemoteDownloadButton(t);
});

where loggedInUser and setCookie are defined thus:

const loggedInUser = url => Role(url, async () => {
    await setCookie({
        name: 'already-seen-banners',
        value: 'cookie-wrapper',
        domain: 'localhost'
    })();
    await setCookie({
        name: 'SSOCookie',
        value: 'loggedIn',
        domain: 'localhost'
    })();
});

const setCookie = ({ name, value, domain = 'localhost', url = `http://localhost:${appPort}` }) => ClientFunction(() => {
    document.cookie = `${name}=${value};domain=${domain};url=${url}`;
}, {
    dependencies: { name, value, domain, url }
});

setupMock is a custom function that makes use of mountebank-helper to set up some mock responses for endpoints. I suppose you could do the same with RequestMocks as well. appUrl is defined as

Additionally, the rendered page has a button clicking which generates a POST request to the mocked endpoint, http://localhost:5201/remotedownload/download/3830670 (as noted in my previous comment).

I hope this info is adequate for you to take a look at the issue.

[miherlosev]

Make sure that setupMock specifies the CORS headers (Access-Control-Allow-Origin and etc). You can check this using the 'Network' panel of the Google Chrome DevTools.

[maheshjag]

Make sure that setupMock specifies the CORS headers (Access-Control-Allow-Origin and etc).

Yes, this is how it is already:

            responseHeaders: {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*',
                'Access-Control-Allow-Credentials': true
            },

[miherlosev]

document.cookie doesn't have the url parameter. (https://developer.mozilla.org/ru/docs/Web/API/Document/cookie)

Please, try to update your ClientFunction as follows:

const setCookie = ({ name, value, domain = 'localhost', path = `http://localhost:${appPort}` }) => ClientFunction(() => {
    document.cookie = `${name}=${value};domain=${domain};path=${path}`;
}, {
    dependencies: { name, value, domain, path }
});

[maheshjag]

That didn't work, nor did removing the path parameter entirely from the function. In both cases, the cookie seen for the remotedownload request is the same as the one I posted earlier. To recap, this is what I'm seeing in the DevTools console of the browser:

General:

Request URL: http://10.155.130.10:54257/bbq5LHO36/http://localhost:5201/remotedownload
Request Method: POST
Status Code: 222 unknown
Remote Address: 10.155.130.10:54257
Referrer Policy: no-referrer-when-downgrade

Request headers:

Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Content-Length: 0
Cookie: c|bbq5LHO36|s_sq|localhost|%2F||jn4nl9x1=bskybfandwtvdev%3D%2526pid%253Dwatch%25253Apanels%25253Adelicious%2526pidt%253D1%2526oid%253Dfunction%252528%252529%25257B%25257D%2526oidt%253D2%2526ot%253DA
Host: 10.155.130.10:54257
Origin: http://10.155.130.10:54257
Referer: http://10.155.130.10:54257/bbq5LHO36/http://localhost:1729/watch/delicious
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
x-hammerhead|xhr|origin: http://localhost:1729
x-hammerhead|xhr|request-marker: true
x-hammerhead|xhr|with-credentials: true

Response headers:

Connection: keep-alive
Content-Length: 0
Date: Thu, 11 Oct 2018 14:03:20 GMT

[miherlosev]

I don't have any ideas of how to find the cause of the problem without an example.
Would you please provide a simple example that I can download and run on my computer?

[maheshjag]

You can run just about any Node app with the example test code that I've given above. You can skip the setupMock step if you've got another app running on the specified port (or alternatively, you could make a POST request to the same Node app). I'm not sure what else you're looking for.

[miherlosev]

It is likely that the cause of the problem relates to your application specifics.
To reproduce the issue, I need the following things:

• an application with all necessary pages and routes;
• test code in which the problem is reproduced.

You can create an example as a separate repository with all required dependencies and share a link with us.

[maheshjag]

Sorry, @miherlosev - I've got a bit busy over the last few days. Will post an example app as soon as I can.

[maheshjag]

Here's the app:
app.zip

I've kept it very simple:

• you need to run npm install from the app folder
• then run npm start in a terminal window
• in another terminal, run npm test

The test expects the response to be what's stubbed in mountebank, but instead a 222 response comes back from testcafe's proxy.

[miherlosev]

At first glance, your mountebank setup has two issues:

• you mock a relative url (remotedownload/download) instead of the full (https://secure-epgservices.sky.com/remotedownload/download/5394973) url
• credentialed requests should specify the precise domain (change the value of the Access-Control-Allow-Origin header to http://localhost:3000)

I suggest using TestCafe's built-in RequestMock for route mocking instead of mountebank. I've modified your example to show this (
remote-download-spec.zip).

[maheshjag]

@miherlosev Thanks for this: setting Access-Control-Allow-Origin to http://localhost:3000 did the trick for me, and I could continue to use my own mocks as well. Very nice!

[alexis-tao]

I’m trying to do a fetch put request with storage.googleapis.com. However, I get a 222 status code back instead of 200. How do I resolve this without mocking the call instead?

[miherlosev]

@alexistaocognite

Could you please provide an example on which I can reproduce the problem on my computer?

[alexis-tao]

@miherlosev

First run some test from testcafe, then open up the dev tools console for the window the test is running in.

Enter (some sample code from https://gist.github.com/justsml/529d0b1ddc5249095ff4b890aad5e801)
await fetch('http://example.com/api/v1/users', { credentials: 'same-origin', // 'include', default: 'omit' method: 'PUT', body: JSON.stringify({user: 'Dan'}), // Coordinate the body type with 'Content-Type' headers: new Headers({ 'Content-Type': 'application/json' }), }) .then(response => response)

Then the response is something weird with things like statusText: "unknown"

However, if you run that code in a different window's devTools console, you would get a different response. In my code, I'm using a Google APIs url instead of the sample one above.

[miherlosev]

@alexistaocognite

We need a complete example. It should contain the test code and the tested web page (public web site, web app example or something else). We need to be able to easily download and run this code and reproduce the problem on our side.
Please don't write any message to the closed ticket. Create a separate ticket with all necessary information.

[alexis-tao]

@miherlosev Okay, it's here https://github.com/DevExpress/testcafe/issues/3535

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or feature requests. For TestCafe API, usage and configuration inquiries, we recommend asking them on StackOverflow.