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 / [email protected]
On Mon, Nov 29, 2021 at 8:23 AM Silvio Bierman
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
