Mass redirects/backend selection with Varnish?
Jason W.
jwellband at gmail.com
Sun Oct 23 19:40:57 CEST 2011
We're looking to move from squid as a reverse proxy to using varnish.
However, I'm not able to come up with a drop-in replacement for
backend selection and 301 redirects.
Currently, we have squid using squirm[1] as a redirector. For every
request coming to squid, a list of squirm patterns (regexes) is
consulted and a rewritten URL is constructed. This URL can be either a
301 redirect (URL prefaced with "301:") or a backend URL. If it's a
301, squid removes the 301: and serves up the redirect. If it's a
backend URL, squid rewrites the URL internally (the new URL is what
gets stored in the cache but the client never sees it) and fetches it
from the backend. We don't configure squid itself to use a single
origin. If the URL isn't matched by a squirm pattern, it's not
successfully served by squid.
Given a single squid instance (we have 7 currently), there can be
anywhere from 50 to 1000 patterns. They are stored in a
space-delimited text file with a regex that is matched on the URL and
a rewritten URL, some of which use backreferences from the matched
regex.
Obviously, we could do this with a giant list of if statements using
req.url and/or req.host. This doesn't strike me as ideal. Our thinking
is to abstract the selection of backend URL and/or whether to 301
redirect out of VCL. We've considered writing a custom VMOD to handle
this (either implement the squirm functionality or use squirm in the
same way that squid does), but I wanted to get the community's take
before we reinvent the wheel or do something crazy.
Is this something that is feasible with varnish or should I move this
functionality elsewhere in the stack? Any ideas are welcome.
Thanks much!
[1] http://squirm.foote.com.au/
--
HTH, YMMV, HANW :)
Jason
The path to enlightenment is /usr/bin/enlightenment.
More information about the varnish-misc
mailing list