Hi Lachlan,
Yes, the very root-directory of the whole application is a symbolic
link. There are no symbolic links in the rest of the paths to the static
resources, everything is located inside the root directory.
Adding the ContextHandler.ApproveAliases does resolve the problem.
Without it the requests simply end up being handled by the servlet at /
instead of the ContextHandler/ResourceHandler pairs.
Unfortunately I do not think I can post a simple reproducer. The Jetty
embedding code is wrapped inside a generic Servlet container abstraction
so the application that sets up the server does not call any Jetty
specific methods directly. But below are the most important methods of
the wrapper.
I hope you can tell me how I can resolve the issue. Taking out the
symlink is a no-go for us.
Kind regards,
Silvio
defaddServletContext[T<: Servlet](contextPath: String,servletPath:
String,servletClass: Class[T],uploadLimit: Int) =
{
classServletContextextendsServletContextHandlerwithServletConfig
{
defsetParameter(name: String,value: Any) = setAttribute(name,value)
setContextPath(contextPath)
valfileSizeThreshold= 1024* 1024
valsh= newSessionHandler
sh.setUsingCookies(false)
sh.setSessionIdPathParameterName(ServletContainer.sessionIdName)
sh.setMaxInactiveInterval(sessionTimeout)
setSessionHandler(sh)
valholder= newServletHolder(servletClass)
valmc=
newMultipartConfigElement(System.getProperty("java.io.tmpdir"),uploadLimit,uploadLimit,fileSizeThreshold)
holder.getRegistration.setMultipartConfig(mc)
addServlet(holder,servletPath)
}
valctx= newServletContext
contexts ::= ctx
ctx
}
defaddDirectoryContext(contextPath: String,directoryPath: String)
{
classDirectoryContextextendsContextHandler()
{
addAliasCheck(newContextHandler.ApproveAliases)
setContextPath(contextPath)
valresourceHandler= newResourceHandler
resourceHandler.setResourceBase(directoryPath)
resourceHandler.setDirectoriesListed(false)
resourceHandler.setCacheControl("max-age="+ 24* 60* 60)
setHandler(resourceHandler)
}
valctx= newDirectoryContext
contexts ::= ctx
}
defstart
{
valsam= sessionMapping match
{
caseSome(mapping) =>
{
newDefaultSessionIdManager(server)
{
overridedefnewSessionId(request: HttpServletRequest,seed: Long) =
mapping(super.newSessionId(request,seed))
}
}
case_ =>
{
newDefaultSessionIdManager(server)
}
}
sam.setWorkerName(null)
valhouseKeeper= neworg.eclipse.jetty.server.session.HouseKeeper
houseKeeper.setIntervalSec(60)
sam.setSessionHouseKeeper(houseKeeper)
server.setSessionIdManager(sam)
valctxHandler= newContextHandlerCollection
ctxHandler.setHandlers(Array(contexts.reverse:_*))
server.setHandler(ctxHandler)
server.start
server.getErrorHandler.setShowStacks(false)
}
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