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 listjetty-us...@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, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >> >> _______________________________________________ >> jetty-users mailing listjetty-us...@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, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > > _______________________________________________ > jetty-users mailing listjetty-us...@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, visit > https://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
