On 18/10/2016 7:54 a.m., Christos Tsantilas wrote: > On 10/17/2016 05:42 PM, Alex Rousskov wrote: >> On 10/17/2016 01:57 AM, Christos Tsantilas wrote: >>> On 10/14/2016 02:30 PM, Marcus Kool wrote: >>>> Squid sends the following line to the URL rewriter: >>>> (unknown)://173.194.76.188:443 <IP>/<IP> - NONE >> >>> Squid generates internally request to serve the non-HTTP client request, >>> and this is what you are seeing as "(unknown)://173.194.76.188:443". >> >> How about sending a CONNECT-like "173.194.76.188:443" URI instead of a >> malformed one? That is, using option #3 below: >> >> 1. Current syntactically malformed URI: (unknown)://host:port" >> >> 2. Lying about the protocol/scheme: http://host:port/ >> >> 3. Authority form URI, as in HTTP CONNECT: host:port >> >> 4. Using made-up URI scheme: tcp://host:port/ >> See http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml > > > We can use on of the 3 or 4. We can just define a new proto for this > case eg a PROTO_TCP or PROTO_TUNNEL and define a Uri::Scheme for this. > > Personally I like the tcp://host:port. But I do not have actually a > strong opinion. Looks that we should also take in account squid helpers > (and maybe other external tools like log analysers). > > Opinions?
If TLS and provides ALPN stating unsupported protocol, use that as the UriScheme image with PROTOCOL_OTHER, else if Tunnel-Protocol from clients CONNECT, same using that value ..., Otherwise the CONNECT with authority-URI Alex mentioned is correct for both helpers and logs. Basically, the most accurate true information - no lies or guesses. If a helper assumes that port 443 means HTTPS that is a helper bug, nothing we can do about it (unless its our helper). Create a new LogTag flag for unsupported protocol and always set it for these transactions, regardless of what URI is able to be used. Amos _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev