Update comment in Javadoc of ServletRequestPathFilter DispatcherServlet relating to DispatcherServlet#30014
Update comment in Javadoc of ServletRequestPathFilter DispatcherServlet relating to DispatcherServlet#30014sergiuprdn wants to merge 1 commit intospring-projects:mainfrom sergiuprdn:main
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
rstoyanchev
added
the
in: web
There was a problem hiding this comment.
Thanks for bringing this up. You're right that the Javadoc reflects original intent rather than current behavior.
For a FORWARD, the filter would also get involved, so technically the DispatcherServlet can always decide to stick with the existing one. The problem is that when there is no Filter, on FORWARD we would find a previous value, and the path would need to be parsed again. This is why in the end DispatcherServlet ended up with always doing its own parsing, while the Filter is there mostly if anything in the Filter chain relies on the parsed path.
There are also other scenarios with ERROR and ASYNC dispatches, and I'm not sure it's worth doing anything more here. We might just have to correct the Javadoc of the filter accordingly.
rstoyanchev
added
type: documentation
rstoyanchev
changed the title
rstoyanchev
changed the title
…et relating to DispatcherServlet
|
Updated javadoc as indicated by PR title. Please check |
3 participants
The following behavior documented by
org.springframework.web.filter.ServletRequestPathFilterdoes not hold true with current version:This PR adds the logic to skip parse and cache
RequestPathifServletRequestPathUtils.PATH_ATTRIBUTEalready exists.The exception where multiple parsing must happen is for Forward requests.