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

On 12/16/2013 01:06 PM, Marcus Kool wrote:
>
>
> On 12/16/2013 01:46 PM, Alex Rousskov wrote:
>> 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=...
>
> Does this mean that a response like
> http://www.example.com/cgi?cat=adult&uri=foo
> will be parsed correctly? (note the "uri=" at the end)

Yes (if implemented correctly) because a key name cannot be preceded by
a '&' character. Whether the current parser actually works that way, I
do not know.

Cheers,

Alex.
Received on Mon Dec 16 2013 - 22:41:34 MST