Re: url_rewrite_program in Squid 3.4

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 12 Nov 2013 15:55:40 +1300

On 10/11/2013 3:20 a.m., Marcus Kool wrote:
> Hi,
>
> I noticed that 3.4.0.2 uses a new protocol for the url_rewrite_program
> that is incompatible with previous versions of Squid.
> I am updating ufdbGuard, a URL redirector for Squid, for Squid 3.4
> to support the new protocol of Squid version 3.4.
>
> I read
> http://www.squid-cache.org/Versions/v3/3.4/cfgman/url_rewrite_program.html
> and was utterly surprised to read that a URL redirector must return
> ERR
> to indicate that the URL is fine and does not need to be redirected,

It makes more sense if you consider this:
 re-writer/redirector is supposed to re-write/redirect the URLs sent
there. It is an "error" to be sending it URLs which should not be
re-written.
 In the ideal world admin would be using url_rewrite_access controls to
limit the amount of URLs sent to the handler instead of relying solely
on logics inside the URL-rewriter.

Also note that both OK and ERR codes are *success* results.
One is a positive-success and the other a negative-success if you
understand what I mean by that.

Failure is BH.

> and must return
> OK [status] url="newurl"
> for a URL that needs to be redirected.
>
> One would expect that ERR is used for an error, not for something
> that is the opposite of an error.

The error is that the re-writer could not or would not re-write the URL.

You can return OK without the url=, status= or rewrite-url= keys.

url= is only required *if* the URL is being redirected.
rewrite-url= is only required *if* the URL is being rewritten.

> Is there a chance that the protocol reply "ERR" can be changed into
> something logical like "PASS" or "UNCHANGED" ?

A chance, but not a big one. The code is shared with many other helper
APIs. That kind of response code would both add extra bytes to the
response lines and not make any more sense delivered to the other
helpers as ERR does to a URL-rewriter. So any change to teh result would
need to be agnostic to the helper type.

>
> Furthermore, I suggest that the BH status code gets a parameter,
> a quoted string explaining what is happening with the URL redirector.

BH status code has message= parameter reserved for this. The extensions
to make use of those parameters across helpers are not yet fully
implemented inside Squid.

Also, all result codes will accept any key=value you wish to send back.

If you want to make up a feature for your helper and request reservation
of a particular key name feel free to publish the details of what that
key is and how it should be used. See what Markus Moeller did with
group= from auth helpers for example. It just needs to make sense within
the semantics and scope of the particular helper interface.

Amos
Received on Tue Nov 12 2013 - 02:55:51 MST

This archive was generated by hypermail 2.2.0 : Tue Nov 12 2013 - 12:00:12 MST