User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Hello Joakim,
Naturally you are right and I should have been more precise. Our
application is not a proper web-application and does not use
Servlets in the proper web-application way. Actually, our system is
a generic HTTP server application and the single Servlet it uses is
supposed to handle ALL requests. Mappings are a very dynamic thing
in our system and user actions can at any time influence the way
URLs are mapped to actual content (be it static files or dynamically
generated). Aliasing and versioning are an essential part of the
application logic.
A default Servlet does not really make sense in our case. Probably
using /* would be the right thing to do. But for some reason we
still have some very generic resources (only a handful remainders
from a distant past to be honest) that are not within the scope of
the Servlet (they happen to be outside the directory structure it
controls). We have used some extra mappings with separate handlers
at the server level for those. Not because that made a lot of sense
but merely because it just worked and we never bothered to do
anything about it. As I write this I come to the conclusion that
this should actually be considered technical debt...
The main reason we made this a Servlet at the time was that we could
easily switch containers. We started with JRun, tried some
alternatives and committed to Jetty when version 5 was destined to
be replaced by 6 (as I remember not very long before the move from
Mortbay to Codehause).
Thanks for the pointers.
Kind regards,
Silvio
On 11/29/21 17:36, Joakim Erdfelt
wrote:
The default url-pattern of `/` is a special url-pattern
that has special meaning to the ServletSpec (it belongs to the
default servlet)
Have you implemented the other requirements of being a
default servlet for your specific servlet?
Perhaps you meant to put your servlet on `/*` instead?
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.
