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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
