Path components interpretation by nginx.

[António P. P. Almeida]

This means that if relying solely on nginx we need multiple regexes to
extract the parameters
(we need to match on both the unescaped and escaped characters)
or using Lua we can unescape and do string processing using the Lua
libraries to extract the parameters.


 Correct?

----appa



On Wed, Feb 12, 2014 at 3:51 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Feb 12, 2014 at 02:16:29PM +0100, António P. P. Almeida wrote:
>
> > 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 :)
>
> I don't think that passing session id as a path segment parameter
> is wrong per se.  One can think of it as ""api" path segment,
> version for a session specified", and it should work as long as
> it's properly handled by the server which implements the API.  But
> it may be non-trivial to work with such URIs in various software,
> including nginx, as path segment parameters support is usually
> quite limited.
>
> --
> 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/20140213/e5c0094e/attachment.html>