[squid-users] ICAP and 403 Encapsulated answers (SSL denied domains)

[Alex Rousskov]

On 1/21/19 3:35 AM, FredB wrote:

> I'm playing with Squid4 and e2guardian as ICAP server.
> 
> I'm seeing something I misunderstand, when a SSL website is blocked
> e2guardian returns a encapsulated "HTTP/1.1 403 Forbidden" header this
> part seems good to me with an encrypted website a denied or redirection
> page can't be added

> But unfortunately Squid adds a "Connection: keep-alive" header

It is not clear _why_ you consider that header "unfortunate" and the
connection "wasted". That header may or may not be wrong, and the
connection may or may not be reusable, depending on many factors (that
you have not shared).


> and if I
> just reload the page I'm waiting a timeout a long moment, (and there is
> no ICAP request between squid and e2) it's like the previous connection
> still opened.
> 
> So the first request is well denied, but the second is without answer

Can the browser reuse the connection after receiving the HTTP 403
(Forbidden) response? Does it? If you provide a sample of client-Squid
request and response headers (including CONNECT messages, if any), and
specify whether they were all sharing the same TCP connection, then we
may be able to assign the blame for the "timeout".

If (some of) the messages are encrypted, providing ALL,2 cache.log may
work. Otherwise, a packet capture (in pcap format) is probably the
easiest sharing method.


> I tried to add "Connection: close" in encapsulated header from
> e2guardian without more success, but anyway "Connection: close" value is
> removed by squid

Yes, by ICAP design, an ICAP service does not have direct control over
HTTP connections maintained by the host application (e.g., Squid).

Alex.