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 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 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
