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? Thank you, ----appa
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
