Hello! 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 > 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? 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 URI. 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 http://nginx.org/ _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
