<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hello Maxim,<br><br></div>Thank you. In fact since I never saw this type of URI before on an API I thought that<br></div>trying to use the path segment parameters as a query string argument was borderline<br>
</div>RFC compliant.<br><br></div>The original API I was referring to uses the parameter as an argument since they pass a session token<br></div>as a parameter:<br><br></div>/api;jsessionid=somehash?t=1&q=2 <br><br></div>
obviously they have some issues with their API well beyond merely being non RFC 3986 <br></div>compliant :)<br><br></div>Thanks,<br><br><div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div>----appa<br>
<br></div>
<br><br><div class="gmail_quote">On Wed, Feb 12, 2014 at 11:51 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<div><div class="h5"><br>
On Wed, Feb 12, 2014 at 02:07:50AM +0100, António P. P. Almeida wrote:<br>
<br>
> Hello,<br>
><br>
> While doing an audit for a client I came across an URL of the from:<br>
><br>
> <a href="http://host/foobar;arg=quux?q=en/somewhere&a=1&b=2" target="_blank">http://host/foobar;arg=quux?q=en/somewhere&a=1&b=2</a><br>
><br>
> Now doing something like:<br>
><br>
> location /test-args {<br>
>     return 200 "u: $uri\nq: $query_string\na: $args\n";<br>
>  }<br>
><br>
> This returns as the value of $uri the string foobar;arg=quux, i.e., the<br>
> first parameter arg=quux is not being interpreted as an argument but as<br>
> part of the URI.<br>
><br>
> This is confirmed by changing the location to be exact using = /test-args<br>
> in which case nginx cannot find a configuration for handling the request.<br>
><br>
> Now if I understand correctly section 3.3 of the RFC<br>
> <a href="http://tools.ietf.org/html/rfc3986#section-3.3" target="_blank">http://tools.ietf.org/html/rfc3986#section-3.3</a><br>
><br>
>    The path may consist of a sequence of path segments separated by a<br>
>    single slash "/" character.  Within a path segment, the characters<br>
>    "/", ";", "=", and "?" are reserved.  Each path segment may include a<br>
>    sequence of parameters, indicated by the semicolon ";" character.<br>
>    The parameters are not significant to the parsing of relative<br>
>    references.<br>
><br>
><br>
> Which means that the above URL is perfectly legal with arg being considered<br>
> a parameter.<br>
><br>
> Shouldn't nginx interpret arg=quux as an argument and not part of the URI<br>
>  in order to fully support the RFC in question?<br>
<br>
</div></div>I don't see any incompatibilities with RFC in current nginx<br>
behaviour.  Parameters aren't significant to the parsing of<br>
relative references, much like RFC states - i.e., "../foo" from<br>
both "/bar;param/bazz" and "/bar/bazz" will result in the same<br>
URI.<br>
<br>
Parameters are not query string though.  Note that semantically<br>
parameters are for a path segment, and something like<br>
"/foo;v=1.1/bar;v=1.2/bazz" indicates a reference to version 1.1<br>
of foo, and version 1.2 of bar.  Representing parameters as a part<br>
of the query string will be just wrong.<br>
<br>
Current nginx behaviour is to treat parameters as a part of a path<br>
segment, which is believed to be compliant behaviour.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></div></div></blockquote></div><br></div>