User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Hello Joakim,
Adding a DefaultServletFilerServer Servlet on / is no good for us
since we have our own Servlet there. But if I understand you
correctly we should add a DefaultServletFileServer on the other
context paths (/scripts, /images etc) instead of using the
ContextHandler/ResourceHandler pairs.
The features you mention are supported by our own Servlet for static
content on different levels but although the static resources
involved in this case are very small and never change that support
would be nice to have here as well. I will look into it.
Kind regards,
Silvio
On 11/29/21 16:09, Joakim Erdfelt
wrote:
You don't even need the ResourceHandler or ContextHandler.
Your ServletContextHandler does all of that already.
Just set a reasonable ResourceBase there and define a
DefaultServlet on url-pattern of `/` (be sure to name the
servlet!)
Well, that was spot on! I added a call to
setResourceBase(directoryPath) to the ContextHandler (just
like is done on the ResourceHandler) and that does indeed
work as intended.
But to be honest I am confused now. I was surprised to find
that setResourceBase exists at all on the ContextHandler. I
was under the impression the ContextHandler defines the
contextPath so it picks up the requests with URLs that match
the path. The ResourceHandler defines the resourceBase to
map URL paths inside the contextPath to directories and
files. The ContextHandler then uses the ResourceHandler to
delegate requests to. Having a resourceBase on the
ContextHandler tells me my understanding of things is wrong
(which is not unlikely at all of course).
Kind regards,
Silvio
On 11/29/21 15:01, Lachlan Roberts wrote:
Silvio,
I
think the fix for this is to add the baseResource to
the ContextHandler as well as on your
ResourceHandler.
Try
that and let me know if it fixes it for you.
If
that doesn't work revert back to using
AllowSymLinkAliasChecker, but definitely do not use
ApproveAliases.
It is not a big problem for us to skip 10.0.7 and
wait for 10.0.8 so keeping things as they are now is
probably the simplest option. On the other hand, if
we happen to push out an update of our core
application in the meantime I may decide to add the
ApproveAliases and move to 10.0.7. Anyway I will be
looking forward to 10.0.8.
Thanks for the help,
Kind regards,
Silvio
On 11/29/21 03:02, Lachlan Roberts wrote:
Silvio,
Thanks for the info, I
will look into it.
The intention of the
AliasChecker change was not to break the usage
of symlinks but to improve safety. The fact
that you have experienced a change in
behaviour probably means there is a bug in the
new SymlinkAllowedResourceAliasChecker
implementation.
For now you should be
able to revert to the previous behaviour by
adding the AllowSymLinkAliasChecker which has
now been deprecated. But we will try to get a
fix out in the upcoming 10.0.8 release.
Th symbolic link helps us (among other
things) to use the same configuration
properties in various development and
testing environments as we use in most
production environments. I manually modified
one development configuration to not use the
symbolic link and upgraded it to Jetty
10.0.7. And as you expected that does work
correctly.
Can you explain to me what the issue is with
having symbolic links in paths and what the
consequence would be if I turned off this
behavior in production? I would expect
symbolic links in paths to be transparent to
the application.
Kind regards,
Silvio
On 11/29/21 00:53, Lachlan Roberts
wrote:
Hi Silvio,
Do you have
any symlink in the path to these
static resources? If so, this could be
related to the AliasChecker changes.
You can test if this is related to the
AliasCheckers by adding the
`ContextHandler.ApproveAliases` to the
`ContextHandler` and see if you still
get the 404's. But even if this fixes
it, do not add
`ContextHandler.ApproveAliases` to
your production code.
Would you be
able to post a simple reproducer that
works on 10.0.6 but not on 10.0.7?
I use an embedded Jetty 10 server. My
server setup code adds a number of
ContextHandlers that each wrap a
ResourceHandler to server static
content on paths like /images and
/scripts etc. Finally a single
ServletContextHandler that wraps a
ServletHolder is added at / to handle
all other requests.
This same setup code has been used
through various Jetty versions (with
some slight modifications for major
version jumps) and has worked fine
up until Jetty 10.0.6. But starting
from Jetty 10.0.7 it no longer works
because requests for the static
contents all result in 404 errors.
Did anything change in the 10.0.7
release that could explain this? I did
not see anything in the change log
that sounds remotely related but I
could be wrong.
