On 10/17/2016 10:56 PM, Amos Jeffries wrote: > 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.
I agree in principle, but recommend doing just #3 for now, in this patch: Everything else mentioned by Amos sounds good, and we can probably add more scheme/protocol information sources as well, but accurate extraction and reporting of unsupported protocol schemes is a separate (and clearly non-trivial!) issue. Let's fix the much bigger known problems first, which is what the proposed patch attempts to do. I hope that option #3 allows us to do that without causing a regression that Marcus have identified and without creating extra work compared to the final state where more schemes may be reported as outlined by Amos (and option #4). Thank you, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev