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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
