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
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
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.