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

Reply via email to