> On 23 Oct 2017, at 8:50 pm, Piotr Dobrogost > <[email protected]> wrote: > > > On Friday, October 20, 2017 at 11:40:38 PM UTC+2, Graham Dumpleton wrote: > This is your own request ID is it? > > Yes. > > Is there a reason the name for the type of device can't be in the body of a > single message for the request instead of the prefix of every message. Is it > just because if all goes okay you don't want noise being logged? > > Sort of. As I'm mainly concerned with access_log I think there's only one > entry per request and it's generated by Apache itself so I don't get to log > anything myself there. In other words I think that the only way to add > something to access_log is to specify it in log format. Btw, what do you mean > by "body" exactly?
My mistake. I was thinking the error log. Forgot for a moment you were talking about access log. And because it is the access log, that is where things get very complicated. > Looking at http://httpd.apache.org/docs/current/mod/mod_log_config.html > neither body nor message is mentioned; there is only a list of format > specifiers one can use to add specific information to what's being logged. > Your remark suggests there's some way of adding custom information to log > entry (as opposed to using log specifier from the list) however I'm not aware > of any such an api. There isn't an API provided to Python code via mod_wsgi and that is because of the complications with mod_wsgi daemon mode. Usually I try and avoid adding special APIs geared towards Apache as all it does it lock you into Apache as a web server thereby destroying a primary goal of WSGI, which was to make it easy to migrate WSGI applications between different WSGI servers. The uWSGI server is particularly bad at destroying application portability and creating lock in for users by providing all manner of non standard APIs that are outside of the scope of the WSGI specification. > Because your WSGI application can run in a daemon process, there is no way > for it to transfer back request variables or notes for interpretation by a > later Apache module. > > Could you please elaborate? I don't see how being a daemon process would > forbid mod_wsgi from modifying Apache's environment. I don't know Apache > internals but the way I envision it works is each module is run in turn and > environment is passed from preceding to following module. The daemon processes cause a big problem for this. This is because your code does run in a separate process. The only back channel for passing back any information to the Apache child processes which proxied the request is in the HTTP response itself. There is no side channel for passing any other information. The access logging is done not from the daemon process, but the Apache child processes, so having a Python API you can call doesn't necessarily help as it isn't being called in the process where the information is needed. Right now I can only see one way of being able to do this without changing drastically how the mod_wsgi daemon processes communicate with the Apache child processes. This is to use the Apache mod_header module. Try the following. In your WSGI application, set a response header: X-Applicaton-Request-Id: <your-request-id> In the Apache configuration enable mod_headers and then use: Header note X-Application-Request-Id wsgi:application-request-id Then in your LogFormat use: %{wsgi:application-request-id}n We also need to remove the response header as we don't want it to be passed back to a HTTP client. So also add: Header unset X-Application-Request-Id My only concern here is the order in which the Header directives are applied. I am hoping it is just in the order given in the Apache configuration file, so as long as this unset is last, you will not remove it before you set the note from it. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
