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