Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to log HTTP method to AbstractRequestLoggingFilter #23759

Closed
mjustin opened this issue Oct 4, 2019 · 2 comments
Closed

Add option to log HTTP method to AbstractRequestLoggingFilter #23759

mjustin opened this issue Oct 4, 2019 · 2 comments
Labels
status: duplicate A duplicate of another issue

Comments

@mjustin
Copy link

mjustin commented Oct 4, 2019

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:

@Bean
public Filter logFilter() {
    CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter() {
        @Override
        protected String createMessage(HttpServletRequest request, String prefix, String suffix) {
            return super.createMessage(request, prefix, ";method=" + request.getMethod() + suffix);
        }
    };
    return filter;
}

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Oct 4, 2019
@rstoyanchev
Copy link
Contributor

This was done recently in #23567.

@rstoyanchev rstoyanchev added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Oct 5, 2019
@mjustin
Copy link
Author

mjustin commented Oct 7, 2019

Looks like I missed it in my search since it was created as a PR but never as an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

3 participants