Re: [PATCH] Re: URL redirection with Squid 3.4

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Mon, 16 Dec 2013 08:46:05 -0700

On 12/14/2013 06:28 AM, Amos Jeffries wrote:
> On 14/12/2013 6:59 a.m., Marcus Kool wrote:
>> all,
>>
>> as discussed in a previous thread, the URL rewriter protocol of Squid
>> 3.4 is different than with previous versions of Squid.
>> Despite Amos' belief, I found out yesterday that there is no backward
>> compatibility since a typical redirection URL is
>>
>> www.example.com/foo.cgi?category=adult&url=http://www.example.com/foo/bar
>> and Squid 3.4 has a parser that splits tokens at '=' and then complains
>> that it does not understand the answer of the URL redirector.
>>
>
> Ouch. Thank you for finding this one.
>
> The fix appears to be limiting the character set we accept for key names
> such that it does not match any valid URL. I have now applied a patch to
> trunk as rev.13181 which limits characters in kv-pair key name to
> alphanumeric, hyphen and underscore.

Based on icap_service experience that had a similar chain of
developments/bugs/fixes, the best fix may be to require uri=... or a
similar key=value pair for communicating URLs.

There is an issue of backward compatibility which might be addressed by
prohibiting bare URLs when newer key=value support is enabled (and
honoring them otherwise). The presence of a uri=... key=value pair can
be used to distinguish the two cases more-or-less reliably.

In other words:

* Want to use the newer key=value format? Use uri=...
* Otherwise, you may continue to use bare URIs.

Please do _not_ interpret the above as a vote against restricting key
name characters. However, we should probably restrict them the same way
for key names _everywhere_ (in all key=value pairs) and not just in
helper responses.

Cheers,

Alex.
Received on Mon Dec 16 2013 - 15:46:37 MST

This archive was generated by hypermail 2.2.0 : Tue Dec 17 2013 - 12:00:11 MST