Path components interpretation by nginx.

Maxim Dounin mdounin at
Wed Feb 12 10:51:29 UTC 2014


On Wed, Feb 12, 2014 at 02:07:50AM +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
>    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?

I don't see any incompatibilities with RFC in current nginx 
behaviour.  Parameters aren't significant to the parsing of 
relative references, much like RFC states - i.e., "../foo" from 
both "/bar;param/bazz" and "/bar/bazz" will result in the same 

Parameters are not query string though.  Note that semantically 
parameters are for a path segment, and something like 
"/foo;v=1.1/bar;v=1.2/bazz" indicates a reference to version 1.1 
of foo, and version 1.2 of bar.  Representing parameters as a part 
of the query string will be just wrong.

Current nginx behaviour is to treat parameters as a part of a path 
segment, which is believed to be compliant behaviour.

Maxim Dounin

More information about the nginx mailing list