-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Do not decode path in EE9 Dispatcher #12796
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@janbartel can you triple check this for us.... I'm just a bit cautious about such changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to change the signatures of the constructors to just pass in the context and HttpURI and then do any encoding/decoding necessary so there's no confusion. If that's not possible, then I guess this solution is probably the best we can do.
@@ -251,7 +252,7 @@ public void forward(ServletRequest servletRequest, ServletResponse response) thr | |||
//if forwarding to the same environment we must mutate this request for Object wrapper identity | |||
if (_targetContext.getTargetContext().getContextHandler() instanceof ContextHandler.CoreContextHandler coreContextHandler) | |||
{ | |||
new Dispatcher(coreContextHandler.getContextHandler(), _uri, _decodedPathInContext).forward(httpServletRequest, httpServletResponse, DispatcherType.FORWARD); | |||
new Dispatcher(coreContextHandler.getContextHandler(), _uri, URIUtil.encodePath(_decodedPathInContext)).forward(httpServletRequest, httpServletResponse, DispatcherType.FORWARD); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a bit confusing with the changing back and forth between encoded, decoded or using the uri. We could change the signature of the constructor to remove the decodedPathInContext
and pass in just the context
and the httpUri
. From that, we can derive all the info we need, avoiding re-encoding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm I think we should look at what is done in jetty-10/11 and mimic that as much as possible. Will do....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a bit confusing with the changing back and forth between encoded, decoded or using the uri. We could change the signature of the constructor to remove the
decodedPathInContext
and pass in just thecontext
and thehttpUri
. From that, we can derive all the info we need, avoiding re-encoding.
That's more or less what we do now in >=EE10
jetty-ee9/jetty-ee9-nested/src/main/java/org/eclipse/jetty/ee9/nested/Dispatcher.java
Outdated
Show resolved
Hide resolved
@janbartel nudge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple small things to attend to, but good otherwise.
Path passed to EE9 Dispatcher is already decoded.