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)://18.104.22.168:443 <IP>/<IP> - NONE
>>> Squid generates internally request to serve the non-HTTP client request,
>>> and this is what you are seeing as "(unknown)://22.214.171.124:443".
>> How about sending a CONNECT-like "126.96.36.199: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).
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.
squid-dev mailing list