Jetty 12.1.0 fails to serve big (> 1MiB) static web resources located inside a jar file

[yurkom]

Jetty version(s)
Jetty 12.1.0

Jetty Environment
Core + all EE*

Java version/vendor (use: java -version)
openjdk version "21.0.8" 2025-07-15 LTS
OpenJDK Runtime Environment Zulu21.44+17-CA (build 21.0.8+9-LTS)
OpenJDK 64-Bit Server VM Zulu21.44+17-CA (build 21.0.8+9-LTS, mixed mode, sharing)

OS type/version
OS name: "mac os x", version: "15.6.1", arch: "aarch64", family: "mac"

Description
When accessing to a web resource, located in /META-INF/resources in a jar file, and the resource has size more than 1MiB, the Jetty throws the exception:

2025-09-07 00:34:57.652:WARN :oeje10s.ServletChannel:qtp898406901-37: /index.html
java.lang.UnsupportedOperationException
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$1.map(ZipFileSystem.java:1116)
        at org.eclipse.jetty.util.BufferUtil.toMappedBuffer(BufferUtil.java:1197)
        at org.eclipse.jetty.util.BufferUtil.toMappedBuffer(BufferUtil.java:1181)
        at org.eclipse.jetty.http.content.FileMappingHttpContentFactory$SingleBufferFileMappedHttpContent.<init>(FileMappingHttpContentFactory.java:105)
        at org.eclipse.jetty.http.content.FileMappingHttpContentFactory.getContent(FileMappingHttpContentFactory.java:80)
        at org.eclipse.jetty.http.content.VirtualHttpContentFactory.getContent(VirtualHttpContentFactory.java:61)
        at org.eclipse.jetty.http.content.PreCompressedHttpContentFactory.getContent(PreCompressedHttpContentFactory.java:49)
        at org.eclipse.jetty.http.content.CachingHttpContentFactory.getContent(CachingHttpContentFactory.java:240)
        at org.eclipse.jetty.server.ResourceService.getContent(ResourceService.java:89)
        at org.eclipse.jetty.ee10.servlet.ResourceServlet.doGet(ResourceServlet.java:528)
        at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
        at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
        at org.eclipse.jetty.ee10.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1386)
        at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:752)
        at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1620)
        at org.eclipse.jetty.ee10.websocket.servlet.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:199)
        at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
        at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1592)
        at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1554)
        at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:805)
        at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:442)
        at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
        at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:719)
        at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1174)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:178)
        at org.eclipse.jetty.server.Server.handle(Server.java:182)
        at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:682)
        at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:411)
        at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1819)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
        at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:999)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1229)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1184)
        at java.base/java.lang.Thread.run(Thread.java:1583)

How to reproduce?

1. Create a web application with the following structure:

my-web-app
+-- WEB-INF
     +-- lib
          +-- assets.jar
               +-- META-INF
                    +-- resources
                         +-- index.html

where assets.jar is a java jar file of a Servlet API Web Resources, containing index.html file with size more than 1MiB.

2. Deploy it to the Jetty Home v12.1
3. Access to the my-web-app like http://localhost:8080/my-web-app/ or http://localhost:8080/my-web-app/index.html.

The issue is reproduced for any static files in size more than 1 MiB.
It is work correctly on Jetty Home v12.0.25.

It is similar to the #12695

[gregw]

@yurkom to work around this for now, you can set the minMappedFileSize init parameter to 0 on the DefaultServlet.
That will prevent any file mapping.

@lorban what do you think the correct fix for this is? Always try to map a buffer and if the filesystem in use throws, then always fallback to other means? Or do we cache that result somehow and not try again?

[gregw]

@lorban Ah I think the issue is that org.eclipse.jetty.http.content.FileMappingHttpContentFactory#getContent catches only IOException, thus UnsupportedOperationException is not handled. It should probably catch Throwable? Thoughts?

[lorban]

@gregw it looks like the problem is in BufferUtil.toMappedBuffer(Path, long, long): channel.map() is surrounded by a try-catch block that catches UnsupportedEncodingException.

AFAIK, FileChannel.map() never throws UnsupportedEncodingException but that exception's name is similar enough to UnsupportedOperationException that I suspect it's a typo that could easily be missed in a review.

Looking closely at the code in the reported stack, if BufferUtil.toMappedBuffer() caught UnsupportedOperationException and returned null, FileMappingHttpContentFactory.SingleBufferFileMappedHttpContent whould throw IOException which would be caught in FileMappingHttpContentFactory.getContent() to simply serve the underlying content without trying to memory-map it.

Let me write a test to confirm this theory.

[lorban]

Confirmed; see changes in #13565

[jluehe]

From the stacktrace:

java.lang.UnsupportedOperationException
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$1.map(ZipFileSystem.java:1116)
        at org.eclipse.jetty.util.BufferUtil.toMappedBuffer(BufferUtil.java:1197)
        at org.eclipse.jetty.util.BufferUtil.toMappedBuffer(BufferUtil.java:1181)
        at org.eclipse.jetty.http.content.FileMappingHttpContentFactory$SingleBufferFileMappedHttpContent.<init>(FileMappingHttpContentFactory.java:105)
        at org.eclipse.jetty.http.content.FileMappingHttpContentFactory.getContent(FileMappingHttpContentFactory.java:80)
        at org.eclipse.jetty.http.content.VirtualHttpContentFactory.getContent(VirtualHttpContentFactory.java:61)
        at org.eclipse.jetty.http.content.PreCompressedHttpContentFactory.getContent(PreCompressedHttpContentFactory.java:49)
        at org.eclipse.jetty.http.content.CachingHttpContentFactory.getContent(CachingHttpContentFactory.java:240)
        at org.eclipse.jetty.server.ResourceService.getContent(ResourceService.java:89)
        ...

it looks like ee9 would also be affected in the same manner, as those frames are env-agnostic? Can you confirm?

[lorban]

@jluehe Yes, EE9, EE10 and EE11's DefaultServlets all internally use the ResourceService so they are impacted by this bug too.