Re: issue with ICAP message for redirecting HTTPS/CONNECT

On 9/06/2014 2:22 a.m., Marcus Kool wrote:
> I ran into an issue with the ICAP interface.
> The issue is that a GET/HTTP-based URL can be successfully rewritten but a
> CONNECT/HTTPS-based URL cannot. I used debug_options ALL,9 to find out
> what is going wrong
> but I fail to understand Squid.

Nathan pretty accurately pinned the problem I think. Beyond that you had
to general Q's about CONNECT I can answer.

Firstly, why the CONNECT does not have https:// is because CONNECT
reuqests use an "authority" URL syntax. RFC7230 explains it far better
than RFC2616 did, http://tools.ietf.org/html/rfc7230#section-5.3.3

Secondly, the sanityCheck parse function is attempting to find the reply
message syntax "HTTP/1.0 ..." and being passed the request "CONNECT
...". I am not sure exectly why the ICAP parser is using HttpReply:: to
parse a request header though, maybe just to eliminate the possibility
of it being an error reply before parsing the request details. Nothing
to worry about though if the ICAP syntax is valid and correct.

Amos
Received on Mon Jun 09 2014 - 00:54:39 MDT