Hello Maxim, Thank you. In fact since I never saw this type of URI before on an API I thought that trying to use the path segment parameters as a query string argument was borderline RFC compliant.
The original API I was referring to uses the parameter as an argument since they pass a session token as a parameter: /api;jsessionid=somehash?t=1&q=2 obviously they have some issues with their API well beyond merely being non RFC 3986 compliant :) Thanks, ----appa On Wed, Feb 12, 2014 at 11:51 AM, Maxim Dounin <[email protected]> wrote: > 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 >
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
