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
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.
>
> T
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 tok
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: $u
3.3 Path...
End of para 1.
"The path is terminated by the first question mark ("?") or number sign
("#") character, or by the end of the URI."
although I think most web servers add & to ?.
Steve
On Wed, 2014-02-12 at 02:07 +0100, António P. P. Almeida wrote:
> Hello,
>
>
> While doing an aud
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,
