3.3 Path...

End of para 1.

"The path is terminated by the first question mark ("?") or number sign
("#") character, or by the end of the URI."

although I think most web servers add & to ?.

Steve

On Wed, 2014-02-12 at 02:07 +0100, António P. P. Almeida wrote:
> Hello,
>
>
> While doing an audit for a client I came across an URL of the from:
>
>
> http://host/foobar;arg=quux?q=en/somewhere&a=1&b=2
>
>
> Now doing something like:
>
>
> location /test-args {
> return 200 "u: $uri\nq: $query_string\na: $args\n";
> }
>
>
> This returns as the value of $uri the string foobar;arg=quux, i.e.,
> the first parameter arg=quux is not being interpreted as an argument
> but as part of the URI.
>
>
> This is confirmed by changing the location to be exact using
> = /test-args in which case nginx cannot find a configuration for
> handling the request.
>
>
> Now if I understand correctly section 3.3 of the
> RFC http://tools.ietf.org/html/rfc3986#section-3.3
>
>
> The path may consist of a sequence of path segments
> separated by a
> single slash "/" character. Within a path segment, the
> characters
> "/", ";", "=", and "?" are reserved. Each path segment may
> include a
> sequence of parameters, indicated by the semicolon ";"
> character.
> The parameters are not significant to the parsing of
> relative
> references.
>
>
> Which means that the above URL is perfectly legal with arg being
> considered a parameter.
>
>
> Shouldn't nginx interpret arg=quux as an argument and not part of the
> URI in order to fully support the RFC in question?
>
>
> Thank you,
> ----appa
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

--
Steve Holdoway BSc(Hons) MIITP
http://www.greengecko.co.nz
Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx