[squid-users] websockets through Squid

[Alex Rousskov]

On 10/16/20 3:35 AM, Vieri wrote:
> squid-5.0.4-20200825-rf4ade365f/src/cf.data.pre contains:
>         Usage: http_upgrade_request_protocols <protocol> allow|deny [!]acl ...
> 
>         The required "protocol" parameter is either an all-caps word OTHER or an
>         explicit protocol name (e.g. "WebSocket") optionally followed by a slash
>         and a version token (e.g. "HTTP/3"). Explicit protocol names and
>         versions are case sensitive.

> That's why I used "WebSocket" instead of "websocket" in my example.
> To avoid confusion, cf.data.pre could be updated to be more clear.

My email saying "websocket" was based on an actual traffic sample that I
have seen. I agree that the text should be changed, but I would prefer
that this change is done by somebody more knowledgeable about the
prevailing WebSocket spelling(s) in Upgrade headers (than I am).


> https://drive.google.com/file/d/1jryX5BW4yxLTSBe0QDavPSiKLBpOvtnV/view?usp=sharing
> https://drive.google.com/file/d/1QYRr-0F-DGnCZtyuuAw8RsEgcHICN_0c/view?usp=sharing

> The connection to wss://ed1lncb62801.webex.com/direct?type=websocket&dtype=binary&rand=1602830016480&uuidtag=5659FGE6-DF29-47A7-859A-G4D5FDC937A2&gatewayip=PUB_IPv4_ADDR_2 was interrupted while the page was loading.

AFAICT, Squid did not see this particular HTTP Upgrade request. While
there are approximately 6 requests mentioning
5659FGE6-DF29-47A7-859A-G4D5FDC937A2, none of them have
rand=1602830016480. It is possible that the random number changes in the
middle of a connection, I guess, but that does not help with
identification of the relevant HTTP transaction.


> Thanks for all the help you can give me.

Debugging logs are meant for Squid developers so do not feel bad about
being unable to use them in this triage. Unfortunately, I cannot help
you with interpreting this particular log right now because the log
contains too many transactions -- I do not know which transaction
corresponds to the client complaint, and I do not have enough time to
look through all 50+ HTTP requests in the log.

One way you can help is to use browser (or client-side) debugging tools
to identify the client port (or at least the millisecond-precision
timestamps) of the problematic transaction. This can help narrow down
the suspects in the new set of logs.


FWIW, I see 467 TLS server handshake parsing "state < atHelloReceived"
failures in your log, but I did not investigate further. They may be
normal/expected or problematic but unrelated to the problem at hand.

Alex.