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?
Joakim Erdfelt / joa...@webtide.com
On Mon, Nov 29, 2021 at 10:09 AM Silvio Bierman
<sbier...@jambo-software.com> wrote:
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!)
See:
https://github.com/jetty-project/embedded-jetty-cookbook/blob/jetty-10.0.x/src/main/java/org/eclipse/jetty/cookbook/DefaultServletFileServer.java
You can even have multiple DefaultServlet added serving different
content.
See:
https://github.com/jetty-project/embedded-jetty-cookbook/blob/jetty-10.0.x/src/main/java/org/eclipse/jetty/cookbook/DefaultServletMultipleBases.java
If you do it this way, then you get more features, such as
request range support, better caching, last-modified support,
etag support, etc...
Joakim Erdfelt / joa...@webtide.com
On Mon, Nov 29, 2021 at 8:23 AM Silvio Bierman
<sbier...@jambo-software.com> wrote:
Hi Lachlan,
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.
cheers
On Tue, Nov 30, 2021 at 12:15 AM Silvio Bierman
<sbier...@jambo-software.com> wrote:
Thanks Lachlan,
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.
cheers
On Mon, Nov 29, 2021 at 12:39 PM Silvio Bierman
<sbier...@jambo-software.com> wrote:
Hi Lachlan,
An additional observation:
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?
cheers,
Lachlan
On Sun, Nov 28, 2021 at 2:40 AM Silvio Bierman
<sbier...@jambo-software.com> wrote:
Hello all,
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.
Thanks,
Silvio
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
