My question pertains to using Squid as a url-rewriter and problems encountered when used in conjunction with https pages.
Setup
Basically, we allow all CONNECTs and http_access requests. The requests then go through a url_rewriter, which checks against a list of bad/good/etc URLs to see if the URL should be rewritten. If it should, the rewriter program outputs 307:newurl. (Where newurl typically is a page of our own explaining that the wanted page contains blocked material, etc)
Problem
This setup works quiet well, but in the case that a page that is blocked (redirected) is behind a https protocol, the browser considers the connection broken. This results in the browser (Chrome, as it were) displaying a "Connection broken 111 error" - page. Which makes sense, I guess, and it would be fine if we only could present the user with some explanation as to why the page could not be retrieved.
The question
How can we, if at all possible during these circumstances, communicate to the user that the page could not be retrieved due to content/policy/etc? I.e. is there a way for us to complement/circumvent the connection broken info and give the user some feedback? Either by means of the initial connect request, or subsequential rewritten GET/POST requests in scope of the https connection (if that makes sense).
What we tried
Our first attempt was to make a helper program that would be run on connect requests, and deny connect requests that would later be blocked. We thought that this combined with a deny-info directive could perhaps, with a bit of luck, do the trick. But alas, it did not. The symptoms from a user perspective (i.e. the resulting page in the browser) was still the same.
Our second attempt was to post this question. :)
Thanks in advance for your time.
