Dear All,
This is pretty lowlevel I think.
Sometimes I get issues with a particular websocket where it returns "200 OK" which in the websocket world is a handshake problem. This can happen after weeks of no issues, but when it does it can take hours till it works again.
The host does not support websocket issues, and the funny thing is that it´s running with no issues at the same when in google chrome. No failed connects - checked with developer tools - just immidiate connection.
So I had fiddler capturing the data from chrome and from java. The situation here is when it works well in both, but I see no reason why jwebsockets would suddenly connect in a different way than usually when the problem occurs, so I think this is fine for determining how things are done differently in chrome and b4j.
My suspicion is that the host has a fallback server with a different websocket implementation that doesn´t do the handshaking well with the jetty implementation, and I want to prepare for the next time that it happens.
So what I found is that there´s a whole lot more going on in the tunnel request sent from chrome than in the b4j one:
First of all, in chrome there´s this:
where in the b4j call, there´s this:
No SessionID!
Then comes the extensions. To make it simple(-ish), this is what´s NOT in the b4j header:
And the following part of the extension look different in chrome and b4j. First chrome:
Then b4j:
Some hashes left out there, and I get the feeling that this could be the culprit or maybe the session ID, but that´s only a guess of course.
So my question is.. is there any way to amend the headers of a websocket request?
This is pretty lowlevel I think.
Sometimes I get issues with a particular websocket where it returns "200 OK" which in the websocket world is a handshake problem. This can happen after weeks of no issues, but when it does it can take hours till it works again.
The host does not support websocket issues, and the funny thing is that it´s running with no issues at the same when in google chrome. No failed connects - checked with developer tools - just immidiate connection.
So I had fiddler capturing the data from chrome and from java. The situation here is when it works well in both, but I see no reason why jwebsockets would suddenly connect in a different way than usually when the problem occurs, so I think this is fine for determining how things are done differently in chrome and b4j.
My suspicion is that the host has a fallback server with a different websocket implementation that doesn´t do the handshaking well with the jetty implementation, and I want to prepare for the next time that it happens.
So what I found is that there´s a whole lot more going on in the tunnel request sent from chrome than in the b4j one:
First of all, in chrome there´s this:
B4X:
Version: 3.3 (TLS/1.2)
Random: D8 1B 34 3B DD E4 75 0E 4F 2C 4C 0B 01 DD EB 24 0E 7B 2A D5 5F ED DE E5 19 BB 04 99 4A 9A 35 5C
"Time": 23-06-2001 06:32:24
SessionID: A2 02 00 00 08 F1 F9 1A 64 61 F2 F5 5A EE AA 46 6E 77 4A 89 29 BC 13 8D BA EA 9A 8D 3D 1D 26 FDwhere in the b4j call, there´s this:
B4X:
Version: 3.3 (TLS/1.2)
Random: 5B 36 D3 CC D5 90 F2 05 6B D5 1D 01 9C BC 98 BE 56 FB 17 23 12 89 75 75 49 F4 D1 CC 4D F6 CC 8D
"Time": 23-11-2078 02:54:35
SessionID: emptyNo SessionID!
Then comes the extensions. To make it simple(-ish), this is what´s NOT in the b4j header:
B4X:
0xbaba empty
SessionTicket empty
status_request OCSP - Implicit Responder
SignedCertTimestamp (RFC6962) empty
channel_id(GoogleDraft) empty
0x0033 00 29 9A 9A 00 01 00 00 1D 00 20 CD 2A 49 E4 A6 2A 5E 6A BE 43 8E 7F 91 76 2A CE 20 B0 A2 4A 76 80 DC B0 44 B5 7A A4 7F D7 38 53
0x002d 01 01
0x002b 0A 1A 1A 7F 17 03 03 03 02 03 01
0xeaea 00
padding 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00And the following part of the extension look different in chrome and b4j. First chrome:
B4X:
signature_algs sha256_ecdsa, Unknown[0x8]_Unknown[0x4], sha256_rsa, sha384_ecdsa, Unknown[0x8]_Unknown[0x5], sha384_rsa, Unknown[0x8]_Unknown[0x6], sha512_rsa, sha1_rsaThen b4j:
B4X:
signature_algs sha512_ecdsa, sha512_rsa, sha384_ecdsa, sha384_rsa, sha256_ecdsa, sha256_rsa, sha256_dsa, sha1_ecdsa, sha1_rsa, sha1_dsaSome hashes left out there, and I get the feeling that this could be the culprit or maybe the session ID, but that´s only a guess of course.
So my question is.. is there any way to amend the headers of a websocket request?