>> I have a login page that redirects (actually appends the parameter
>> "?error=true" to the URL and lets the user try again).
>>
>> I was trying to re-define "access_log" with a full path and (for now)
>> "combined" to a separate file in that location
> nginx chooses configuration based (primarily) on the "location", which
> is the local part of the request, excluding query string.
>
> So whatever location matches /my/login/page will also match
> /my/login/page?error=true.
>
> Does that explain why your initial attempts did not do what you expected?
No, unfortunately it doesn't. I copied the "GET" from the "usual"
access log exactly. Thus, I know the call is being made, because it's
being logged in the normal log, and I'm pretty sure I have the right
location string, because I copied it right out of the log.

Do I need to escape anything? I've tried = and ^~ matching and neither
seems to catch it.

>> This doesn't seem to work at all. An empty log gets created at startup,
>> but nothing ever gets written there. Is it because the access logging
>> is already done by the time the location is determined?
> No, the access logging is done in the context of whichever location the
> request finishes in. It doesn't appear in your error=true log, because
> a request like /my/login/page%3Ferror=true was not made.
>
> (As a test, make a request like that, and you should see it in the
> new file.)
Yes, as I mentioned above, my requests DO get logged (always). They
just don't go to the log I want them to.

>> How can I somehow log when someone accesses the "login" page with the
>> "error=true" parameter on the URL?
>>

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx