Le 23/11/2019 à 20:38, William Dauchy a écrit :
we were decoding all substring and then parsing; this could lead to
consider & and = in decoding result as delimiters where it should not.
this patch reverses the order by first parsing and then decoding each key
and value separately.

This patch should be backported to 2.0


Hi William,

Many thanks. I found some issues.

First, a key without value is not properly handled. You must not try to parse the value, otherwise the following parameter is read as value. For instance "/metrics?no-maint&scope=server".

Then, if empty keys are forbidden (and it seems to be reasonable), you should throw an error if the delimiter is an equal sign (so a value with an empty key), or, at least, you should skip the value. For instance, "/metrics?=value" or "/metrics?k1=v1&=v2". Another way to catch this case is to consider a key without value as equivalent to a value with an empty key. This way "/metrics?no-maint" could be equivalent to "/metrics?=no-maint". Your choice :) But be careful to make a difference between a key without value ("?a") and a key with an empty value ("?a=").

The equal sign should probably be forbidden in a value (before decoding). For instance, "/metrics?k1=val=ue" or "/metrics?k1==v1".

Finally, it could be good to stop the parsing on the number sign (#). To not parse the fragment part of the uri, if any. The current version is also affected by this issue.

--
Christopher Faulet

Reply via email to