On 10/06/2015 10:14 AM, Paul Carew wrote: > when accessing a blocked site over HTTPS the following ICAP > response is received: > > ICAP/1.0 200 OK > ISTAG: "PRODUCTNAME" > Attribute: Blocked Sites > Encapsulated: res-hdr=0, null-body=533 > > HTTP/1.0 403 Blocked > Content-Type: text/html > Pragma: no-cache > Cache-Control: no-cache > Location: http://192.168.0.10/block?session=12345678 > > <html> ... > </html>
> Chrome and IE just error upon receiving this response. In the case of > Chrome I get an ERR_TUNNEL_CONNECTION_FAILED error. I could be wrong > but I would imagine this error is by design, as Chrome will only > respond to a proxy authentication request or SSL handshake in response > to a HTTP CONNECT? Yes, this is by ["lazy"] browsers design (not specific to Chrome or IE). > If that's correct, I was wondering if there is a way to get this to > work, with peek and splice possibly or any alternative method? Yes, you have a few options: 1. Do not block CONNECT. Block the HTTP request after CONNECT instead. This does not require Squid modifications, but may require ICAP service modifications, including keeping state between HTTP requests. 2. If you do not care about the actual error message displayed to the user OR are OK with using [customizable] Squid error messages instead of the ICAP-generated error messages, then you may: 2a. Teach Squid to treat certain ICAP responses as an instruction to "block the virgin HTTP message". Squid eCAP client already supports that (see 2d below). Squid ICAP client needs more work, including a decision on how to define those "certain responses" in the ICAP context (should probably be done via a new ACL-driven squid.conf directive). 2b. Teach the ICAP service to allow the CONNECT request but add an extension HTTP header to it. Use adapted_http_access to block the adapted CONNECT request. 2c. Teach Squid to use non-standard ICAP response headers as transaction annotations (eCAP can do that already). Use adapted_http_access to block the CONNECT transaction with your "blocking" annotations. 2d. Switch from ICAP to eCAP and use the existing libecap::host::Xaction::blockVirgin() API. This option does not require Squid development. 3. If you must use ICAP-generated error messages and cannot use option #1 above, then you can do either #2a or #2d _and_ also teach Squid to save and serve the custom error message returned by the adaptation service. This option requires [very] difficult Squid development work (in addition to easier development work required by #2a), but it is possible. All of the above options require bumping the connection. There is no other way to serve an error message to the user (because of the browsers design). In the above text, "teach X to do Y" means "modify X code to [optionally] do Y", including finding somebody who can perform those source code modifications for you if needed. I believe the above options are reasonable/valid, but I have not tested any of them with a recent stock Squid. YMMV. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
