websocket

[hdorgeval]

Are you requesting a feature or reporting a bug?

May be a bug. Otherwise I am requesting a feature.

What is the current behavior?

We are currently stuck to the 0.18.3 version of TestCafe. In all versions > 0.18.3, web sockets are not processed correctly in our apps. It seems there is a change in web socket processing between the 0.18.3 and 0.18.4.
If on your side, it is not possible to solve this issue, is it possible to have a command-line option to revert to the 0.18.3 behavior concerning web sockets?

What is the expected behavior?

Web sockets should be correctly processed and, in case of any issue, revert back to the 0.18.3 behavior concerning web sockets

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

Upgrade TestCafe version from 0.18.3 to any other version (up to the last one)

Provide the test code and the tested page URL (if applicable)

Without TestCafe

Web site url: https://xxxx-yyy.fr.world.zzzzz/sp/devci/#/

web socket headers:
Request URL:wss://machine-name.fr.world.zzzzz:12345/sv/ws
Request Method:GET
Status Code:101 Switching Protocols
HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: PgEUluLdc54eoOEqTNMrOddXmxI=
GET wss://machine-name.fr.world.zzzzz:12345/sv/ws HTTP/1.1
Host: machine-name.fr.world.zzzzz:12345
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: https://xxxx-yyy.fr.world.zzzzz
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: cookie1=...; cookie2=...; cookie3=...
Sec-WebSocket-Key: Z3WnauKCeKPGw+N4ap9nLA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

With Testcafe 0.18.3

Web site url: http://000.00.00.0:58762/BkIWXQ3vG/https://xxxx-yyy.fr.world.zzzzz/sp/devci/#

web socket headers:
Request URL:wss://machine-name.fr.world.zzzzz:12345/sv/ws
Request Method:GET
Status Code:101 Switching Protocols
Connection:Upgrade
Sec-WebSocket-Accept:PsVeRIDCcPSc8X3MYvncSZgmbA0=
Upgrade:WebSocket
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.9
Cache-Control:no-cache
Connection:Upgrade
Host:machine-name.fr.world.zzzzz:12345
Origin:http://000.00.00.0:58762
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:ClNhTdt40wBnoy0NvJYbmA==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36

With TestCafe > 0.18.3

web socket headers:
Request URL:ws://000.00.00.0:54321/Sk056E2Dz!w!https%3A%2F%2Fxxxx-yyy.fr.world.zzzzz/https://machine-name.fr.world.zzzzz:12345/sv/ws
Provisional headers are shown
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.9
Cache-Control:no-cache
Connection:Upgrade
Host:000.00.00.0:54321
Origin:http://000.00.00.0:54321
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:SoezN5rmDs5E2MDLn63O0w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36

Tested page URL:

Test code

Specify your

• operating system: Windows 10
• testcafe version: 0.18.3
• node.js version: 8.9.4

[miherlosev]

Starts from 0.18.4 version, we send websocket requests through our proxy.
Net logs from issue description show this updated behaviour.
Our tests cover many cases of using WebSocket requests (ws and wss protocols, cookie processing and etc.).

If your application work right with 0.18.3 version and it does not work with 0.18.4 and later - it is a bug.
To understand a reason of the problem, we need a direct access to the your application (public link or remote session) or example demonstrating the problem.

[hdorgeval]

Thanks for your answer. I was wondering if the problème was due to the fact that the http url is:

• https://xxxx-yyy.fr.world.zzzzz/sp/devci/#

but the websocket url is:
wss://machine-name.fr.world.zzzzz:12345/sv/ws

(machine-name is not the same as xxxx-yyy, but the suffix is the same : .fr.world.zzzzz)

but this schema seems not be reflected in the built url:
ws://000.00.00.0:54321/Sk056E2Dz!w!https%3A%2F%2Fxxxx-yyy.fr.world.zzzzz/https://machine-name.fr.world.zzzzz:12345/sv/ws

it should be:
ws://000.00.00.0:54321/Sk056E2Dz!w!https%3A%2F%2Fxxxx-yyy.fr.world.zzzzz/wss://machine-name.fr.world.zzzzz:12345/sv/ws

Am i wrong?

[hdorgeval]

Hello @miherlosev, is there a way to clone the hammerhead repo locally on my machine and use this cloned repo over a standard testcafe install.

It would enable me to step into the websocket code to investigate what is wrong on our side.

Thanks a lot for your support.

[LavrovArtem]

Hi @hdorgeval,
The web socket has correct url.
For debugging, start the playground gulp task of thetestcafe-hammerhead repository with --dev flag.

[hdorgeval]

Hi @LavrovArtem, thank's to wireshark, we discovered that the http headers are always sent in a lower cased format. Is it possible, to change the hammerhead behavior so that headers casing is not changed when they are sent over the network?

[LavrovArtem]

Hi @hdorgeval,
It's duplicate of DevExpress/testcafe-hammerhead#1383.

It's not a bug. Nodejs http/https modules convert header names to lowercase.

The HTTP/1.1 spec states "Field names are case-insensitive." (http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html