Path components interpretation by nginx.

[António P. P. Almeida]

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 <mdounin at mdounin.ru> 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
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140212/23024c02/attachment.html>