2 months ago
curl -v --no-progress-meter --http1.1 -N -T . \
"wss://utilities-us-west.up.railway.app/ws/raw" \
2>&1 | grep --line-buffered -i 'Sec-WebSocket-Key'
> Sec-WebSocket-Key: +rHtyhD5Mivjna9+yXMQCQ==
Sec-Websocket-Key: 5wcFGyMJskDpJGrH8S5zCw==The Sec-Websocket-Key is intercepted and regenerated between the HTTP ingress and my deployed service, causing issues when relying on the header on either side.
Continued from https://discord.com/channels/713503345364697088/1487349698472841267
5 Replies
2 months ago
This has been escalated.
2 months ago
for reference, this occurs with the cdn enabled or disabled. however, prior to the cdn being released, the header was passed corectly. this was true until a few months ago, when it stopped working for days but occasionally began working again (potentially testing with the cdn feature?)
last worked between 3/24-3/26
2 months ago
For some context:
- Regardless of whether the CDN is disabled or enabled, Fastly still in front of your service.
- There was a period of time where Fastly was on a random subset of domains.
2 months ago
Clients should not expect Sec-Websocket-Key to match. What's important according to spec, is that the Sec-Websocket-Accept is correctly derived from the original client Key. I've verified that the Accept values are correct from Fastly.
2 months ago
So, this is a client implementation issue; however we would like to support even misconfigurations so that we don't block certain applications or behaviors even if it's not "to spec". So we will look into this.