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.