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.