It would be very nice if someone would add the following variable to
Nginx:
$request_path
Right now, we have $request_uri which includes the query string of the
original request. We also have the $uri which is the path portion of
the $request_uri, but it is the path AFTER the rewrites. What would be
very useful is the $request_path, which would be the original path
portion of the $request_uri.
I use a very efficient TSV access log that can be imported and parsed
VERY quickly by our analytics software. The problem with logging the
$uri is that for requests that generate a 500 error, we lose the
original request path since the error_page directed rewrites the $uri.
It would be very nice if someone would add the following variable to
Nginx:
$request_path
Right now, we have $request_uri which includes the query string of
the original request. We also have the $uri which is the path
portion of the $request_uri, but it is the path AFTER the rewrites.
What would be very useful is the $request_path, which would be the
original path portion of the $request_uri.
If I understand your problem you want to keep the original URI in a
variable to log it later.
Try setting a variable at the server level. Note that both set and
rewrite happen at the rewrite phase. So if you have server level
rewrites, make sure the variable is set before the rewrites appear.
server { #…
set $orig_uri $uri; # $orig_uri is the variable having the
António, this was a really good idea, but with fastcgi_intercept_errors
and proxy_intercept_errors turned on, the $orig_uri is logged as
whatever the error_page is (in my case /error.html).
I’ve tried a bunch of approaches in the nginx.conf to get the original
request path isolated to a variable for logging, but all have failed.
I’m
pretty desperate for this variable, but I don’t have the time to apply a
patch to the source code. I’m willing to pay for someone to do this.
If
anyone is interested, just let me know. It really shouldn’t be that
complicated.
kolbyjack, this is really smart. I didn’t think about this approach.
The
only downside is doing an additional regex for each request. But, in
the
meantime, this will work. Thanks!
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.