WebSocket handshake failure when app is built with Bazel about swift-nio

[Lukasa]

The other thing you can try to do to debug this is to get a packet capture of the two different handshakes.

[Lukasa]

The websocket key (in Sec-Websocket-Key) is set by the client, not the server. It's typically generated randomly, but the server has no influence over it: it can only compute over it. Is it the case that the client repeatedly connect to the Xcode-built server, but not the Bazel-built server? Does it always fail to connect to the Bazel server?

[luispadron]

@Lukasa correct, the client is able to always connect to the server (macOS app) when the server is built with Xcode but handshake always fails when I build the server with Bazel

[Lukasa]

Does this reproduce with the sample servers in this repo?

[luispadron]

I can give that a try and report back.

I did try to create a minimal server and client to share but that worked for both build systems (this was using a stripped down version of both the server and client).

The minimal server I built also worked with our large iOS client to establish a connection using both build systems, which I can only imagine means the issue is with the server and how it gets built/linked?

Is there anything I can enable to debug further? All I have to go off on is the error message I posted above.

The handshake failure comes right after calling resume on a URLSessionWebSocketTask on the iOS client.

[luispadron]

@Lukasa thanks for your help here! I'm very much a newb here.

I haven't had a chance to get the exact web info yet but on the android client when it connects to the Bazel built server we do get some more info:

Throwable java.net.ProtocolException: 
Expected 'Sec-WebSocket-Accept' header value 'eabW+NOBcvdzRVggc2z4oTgL8Og=' but was 'CBn5S5K8ShGNaOtKxZc7/ldcyno='

[luispadron]

One of our engineers also determined the culprit seems to be from the hash of SHA1.swift differing between the two build systems.

Using CryptoKit we get the same SHA but using SHA1 from swift-nio these values differ for the same input.

Xcode:

Bazel:

Do you know of any build time flags, language standards and such that would change this behavior?

[luispadron]

I've confirmed the root cause is BYTE_ORDER is coming back as BIG_ENDIAN which is incorrect for macOS arm64. Seems like a similar issue to: #2584

[luispadron]

This minimal repo demonstrates the issue: https://github.com/luispadron/bazel-big-endian-on-macos

[Lukasa]

Can you confirm that you're using version 2.62.0? That contains the fix from #2584.

[luispadron]

Confirmed that 2.62.0 fixes this issue for Bazel build. Thanks so much for your responsiveness here @Lukasa