path with query string

[pillaryj]

Hi,

First of all, I appreciate this package.
I'd like to try this package in my project, so I wonder if you could help me out.

I hope the path of the message is also displayed as a query string.
I mean, I hope request.get_full_path() is used instead of request.path in the get_log_message function located in your RequestIDMiddleware class.
request.path is very inconvenient to know the exact url because it cuts all the paths behind '/?'.

Would that be possible?

[j4mie]

Thanks, that's a good suggestion. I'm not sure if we can just make the change, because some people might be relying on the current behaviour, and sometimes query strings can be very long. Maybe we could add a setting LOG_QUERY_STRING or something. Will get to this when I can.

[alexche-cchange]

This could be a rabbit hole. It starts with full path, then maybe we need headers somewhere (paging anyone?) and maybe response data, and maybe body (or certain parts of it).

We are doing like this:

1. At the start, Log Analytics-like message which contains all the necessary details of the request. It already contains request ID. Analytics we route in separate stream.
2. Log everything else with the request_id only.

Then if/when anything happens, it is easy to spot on the analytics stream, and further investigation only needs a token request_id.

[j4mie]

@alexche-cchange thanks for the comment. I think you're in agreement, the suggestion here is to log the query string in the RequestIDMiddleware, which logs a single message per-request (if LOG_REQUESTS is enabled) containing the user ID, request path, method etc. Subsequent logging calls just include the request ID. I'd agree that we definitely don't want to be logging headers or body.