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)

* Otherwise, you may continue to use bare URIs.

What would work great for the URL redirector is:
if the response starts with OK, ERR or BH, it can be parsed as the new 3.4 
protocol with kv-pairs,
and if not, it is the old pre-3.4 protocol and should be parsed as such.

I wonder if the same logic works for the other interfaces.
disclaimer: I am not very familiar with all interface changes, only the changes 
for the URL redirector.

Marcus


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.



Reply via email to