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.
