request getPathInfo returns null

[liudonghua123]

Jetty version
9.4.26.v20200117

Java version
1.8.0_191

OS type/version
Windows 10 1909

Description
I use IPAccessHandler for restricting ip and url access. My config file is something like belows.

<?xml version="1.0"?><!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">

<!-- =============================================================== --><!-- Configure the test-jaas webapp                                  --><!-- =============================================================== -->
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">

  <Set name="contextPath">/auditlog</Set>
  <Set name="resourceBase">/d:/log/</Set>
  
  <Call name="insertHandler">
    <Arg>
      <New class="org.eclipse.jetty.server.handler.IPAccessHandler">
        <Call name="addWhite">
          <Arg>127.0.0.1|/*</Arg>
        </Call>
      </New>
    </Arg>
  </Call>

</Configure>

But when I browser http://127.0.0.1:8080/auditlog/, it always give me 403 error. After go through the code, I find it was baseRequest.getPathInfo() returned null instead of /auditlog/, so the validator logic failed.

[sbordet]

@gregw since IP|InetAccessHandler is a Handler and can be set in front of many different contexts, why do we use getPathInfo() to match, instead of the full URI path?

[gregw]

I think the idea was that if the access handler is installed outside of a context, then it will match paths on the entire URI. If it is installed within a context, it will match paths against the URI stripped of the contextPath.

However, in this case the servlet path has also been taken from the pathInfo, leaving null. So ideally we'd like to apply the path match before the servletHandler does. So perhaps it needs to be a ScopedHandler.... or operate on addPath(servletPath, pathInfo)

[sbordet]

@gregw ok so this needs a better fix than what provided in #4579, which is wrong because it only considers the context path.

[gregw]

@sbordet the solution is to use the target instead of the pathInfo as it will be the pathInContext if deployed in a context. I have fixed in #4580, but I think we need to handle named dispatches also...

[liudonghua123]

@gregw @sbordet Thanks. Will the next release contain this fix?

[gregw]

yes