** Enhancements requests ** Hi, I've just spent the last five hours debugging a "problem": one of our micro services has an endpoint /api/v1/instances/filter. Now that I upgraded Spring Boot to the latest version, requests from another micro service to /api/v1/instances/filter/, note the trailing slash, throws an exception. I accept that, but what I find hard to swallow is the logging from the Exception:

org.springframework.web.servlet.resource.NoResourceFoundException: No static resource api/v1/cases/filter.
...

Some layer strips: 1. The leading slash. 2. The trailing slash.

Would it be impossible to use log something like:

"No static resource '%s'".formatted(resourcePathExactlyAsReceived);

I.e. stop chomping the resource path and log it as it is?

Comment From: bclozel

Thanks for reaching out and sorry for the delayed response.

First, let me zoom on the root issue. If I understand correctly, this external service was calling /api/v1/instances/filter/ and this was not matching the /api/v1/instances/filter route because we do not support the trailing slash matching anymore. We do have a URL Handler filter that can help with that, automatically sending HTTP redirects or "rewriting" the request on the fly, fully configurable. Would that help for your case?

Now, since the expected endpoint did not match, the matching process continues and reaches the static resource handling part as a last resort. The path that you're seeing logged is indeed pre-processed to get the "path within the application", meaning:

  • the servlet context path (or reactive context path) is removed
  • the semi-colon content is removed (think ;JSESSIONID= and similar)
  • I don't think this variant decodes the path segment though

So the tradeoff here is mostly between removing the context path from the logs vs. showing a "processed" view of the path. I would keep the current behavior for consistency but since the resource handler is typically the last in the chain, this indeed shows an incomplete view. As for what we could use instead, request.getPathInfo() is also incomplete because it does not contain the servlet path and it is canonicalized. request.getRequestURI() seems to be the most sensible choice, even if the string is not decoded and this could throw off log parsers.

CC'ing @rstoyanchev for an opinion on this.