Ahh squid, how I love to hate to love you… most of the time, you work great for me. But sometimes… grr. Anyway…
So here’s my problem — have squid (3.1.18) being used in both a transparent and reverse proxy configuration (transparent proxy for everything inside my network going out to the internet, reverse proxy to redirect certain CNAME virtual hosts to my various other servers on my network). However, I do not want to permit http traffic to go through the reverse proxy peers, I want everything https. No problem, right? Simple configuration directive for just one of my cache peers:
cache_peer 10.18.75.1 parent 80 0 no-query originserver login=PASS name=xlorep
acl sites_xlorep url_regex ^https://xlorep.darkhelm.org
cache_peer_access xlorep allow sites_xlorep
http_access allow sites_xlorep
acl http_xlorep url_regex ^http://xlorep.darkhelm.org
http_access deny http_xlorep
deny_info https://xlorep.darkhelm.org/ http_xlorep
Basically, it uses a couple regular expressions to figure out when someone is accessing the xlorep.darkhelm.org host. If it is https, it connects to that server. If it is http, if denies access, and sends a HTTP redirect command to send the person to the https equivalent.
Perfectly fine configuration, unless the person wants to, let’s say, go to http://xlorep.darkhelm.org/some/other/path.html. Rather than going to https://xlorep.darkhelm.org/some/other/path.html, the person is sent to https://xlorep.darkhelm.org/. Because squid 3.1 is too dumb to do anything better. For almost every request I use, this is *perfectly fine* — most of my redirects go to sites that all handle themselves in a friendly way to this kind of scenario.
Enter mpd‘s client175, and suddenly this causes a problem. For some reason, client175 likes to send links to the unsecured version of the URL (http rather than https), which gets hosed because of the deny_info redirecting going on in my squid configuration. So… client175 becomes only partway functional. I needed to find some way to properly change the URL to the exact https equivalent of the http url.
Well, I found out that squid 3.2 did exactly that. Oh, other than it being beta software and completely crippling my configuration from the ground up preventing any http to https redirects from happening, even those from the transparent proxy side of things… so… 3.2 didn’t work.
Solution #2 came to me rather simply — I write a simple redirect script that could do the work for me, and put the URL for that in my deny_info directive above. So… after installing mod_python into my in-house apache server (why mod_python? because I like python — same thing for client175, it is a python-based mpd client). So… get mod_python configured with a simple addition to the default site for apache:
<Directory /var/www/py>
AddHandler mod_python .py
PythonHandler mod_python.publisher
PythonDebug On
</Directory>
from mod_python import apache, util
import re, urllib
def redir(req):
req.log_error('handler')
reqURI = req.unparsed_uri
patt = re.compile(r"^/py/redirect.py/redir?uri=")
reSearch = re.search(patt, reqURI)
oldURL = urllib.unquote(reqURI[reSearch.end():])
newURL = re.sub(r"^http://","https://",oldURL)
# req.content_type = 'text/html'
# req.send_http_header()
# req.write('')
# req.write('' + reqURI + '<br />')
# req.write('' + newURL + '<br />')
# req.write('')
# return apache.OK
return util.redirect(req, newURL)
I configure this to be handled through redirect.darkhelm.org, and it basically translates a given URL parameter from http to https. I can then go back to that squid configuration, and change it as follows:
cache_peer 10.18.75.1 parent 80 0 no-query originserver login=PASS name=xlorep
acl sites_xlorep url_regex ^https://xlorep.darkhelm.org
cache_peer_access xlorep allow sites_xlorep
http_access allow sites_xlorep
acl http_xlorep url_regex ^http://xlorep.darkhelm.org
http_access deny http_xlorep
deny_info https://redirect.darkhelm.org/py/redirect.py/redir?uri=%s http_xlorep
And now, if someone goes to http://xlorep.darkhelm.org/some/other/path.html they get redirected to https://xlorep.darkhelm.org/some/other/path.html — exactly what I want. And it makes client175 work perfectly! As we used to say in the Army, HOOAH! problem solved.