You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is the same as #18818, except that it concerns the HTTP method instead of the headers.
AbstractRequestLoggingFilter has options to include various parts of the request, including the URL, request headers, and the payload. It would be nice if it also had a standard option to log the HTTP method. I imagine it could be something like AbstractRequestLoggingFilter.setIncludeHttpMethod().
The rationale here is that sometimes it is helpful or necessary to know what the request headers were in order to troubleshoot an issue. I recently came across such an issue where the client was troubleshooting an issue where it eventually turned out that they were making the request with the wrong HTTP method. It was still technically a valid request returning 200 OK, so they didn't initially notice that call was incorrect.
A workaround is to override the createMessage method to append the header information:
Note though that since the name of the logger that is used is based on the name of the class, the logging configuration has to be set to log the new subclass to DEBUG, not e.g. CommonsRequestLoggingFilter.
The text was updated successfully, but these errors were encountered:
This is the same as #18818, except that it concerns the HTTP method instead of the headers.
AbstractRequestLoggingFilter
has options to include various parts of the request, including the URL, request headers, and the payload. It would be nice if it also had a standard option to log the HTTP method. I imagine it could be something likeAbstractRequestLoggingFilter.setIncludeHttpMethod()
.The rationale here is that sometimes it is helpful or necessary to know what the request headers were in order to troubleshoot an issue. I recently came across such an issue where the client was troubleshooting an issue where it eventually turned out that they were making the request with the wrong HTTP method. It was still technically a valid request returning
200 OK
, so they didn't initially notice that call was incorrect.A workaround is to override the
createMessage
method to append the header information:Note though that since the name of the logger that is used is based on the name of the class, the logging configuration has to be set to log the new subclass to DEBUG, not e.g.
CommonsRequestLoggingFilter
.The text was updated successfully, but these errors were encountered: