ResourceServlet Download link broken

[luxiao0000]

Jetty version(s)
12.1.0~12.1.3

Jetty Environment
ee10, ee11

HTTP version
HTTP1.1

Java version/vendor (use: java -version)
openjdk version "21.0.2" 2024-01-16 LTS
OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode)

OS type/version
macos

Description
Using the Resource Servlet to provide the download service, if the client can complete the download within 30 seconds (not necessarily exactly 30 seconds, usually a little over 30 seconds), there is no problem. If it exceeds 30 seconds, an error will occur. This issue exists in version 12.1.x, but not in 12.0.29

How to reproduce?
java code

        <dependency>
            <groupId>org.eclipse.jetty.ee10</groupId>
            <artifactId>jetty-ee10-servlet</artifactId>
            <!--            <version>12.1.3</version>-->
            <version>12.1.0</version>
            <!--            <version>12.0.29</version>-->
        </dependency>

import org.eclipse.jetty.ee10.servlet.ResourceServlet;
import org.eclipse.jetty.ee10.servlet.ServletContextHandler;
import org.eclipse.jetty.ee10.servlet.ServletHolder;
import org.eclipse.jetty.server.HttpConfiguration;
import org.eclipse.jetty.server.HttpConnectionFactory;
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.ServerConnector;
import org.eclipse.jetty.util.thread.QueuedThreadPool;

import java.nio.file.Files;
import java.nio.file.Path;

public class Main {

    public static void main(String[] args) throws Exception {

        Server server = new Server(new QueuedThreadPool() {{
            setMaxThreads(10);
            setName("jetty-pt");
        }});

        HttpConnectionFactory httpConnectionFactory = new HttpConnectionFactory(new HttpConfiguration() {{
            setSendServerVersion(false);
            setIdleTimeout(30000000);
        }});

        server.addConnector(new ServerConnector(server, httpConnectionFactory) {{
            setPort(9080);
            setIdleTimeout(30000000);
        }});

        server.setHandler(new ServletContextHandler("/") {{
            addServlet(new ServletHolder("default", ResourceServlet.class) {{
                setInitParameter("dirAllowed", "false");
            }}, "/download/*");
            setBaseResourceAsPath(Files.createDirectories(Path.of("download")));
        }});

        server.start();
    }

}

wget

➜  ~ wget --limit-rate=100k http://127.0.0.1:9080/download/test.txt -O /dev/null

--2025-10-29 09:32:10--  http://127.0.0.1:9080/download/test.txt
Connecting to 127.0.0.1:9080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22032000 (21M) [text/plain]
Saving to: '/dev/null'

/dev/null                          17%[=========>                                                  ]   3.70M   101KB/s    in 38s     

2025-10-29 09:32:47 (100 KB/s) - Connection closed at byte 3877548. Retrying.

--2025-10-29 09:32:48--  (try: 2)  http://127.0.0.1:9080/download/test.txt
Connecting to 127.0.0.1:9080... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 22032000 (21M), 18154452 (17M) remaining [text/plain]
Saving to: '/dev/null'

/dev/null                          18%[++++++++++>                                                 ]   3.98M  99.8KB/s               ^C

[lorban]

This happens because the ResourceServlet is sending large files asynchronously and as such, it is interrupted after the default AsyncContext timeout of 30 seconds mandated by the Servlet spec.

If you want to override the default timeout, you can set the org.eclipse.jetty.ee10.servlet.ServletChannelState.DEFAULT_TIMEOUT system property to a long value in millisecond.

[luxiao0000]

Why is 12.0.29 fine

[lorban]

This looks like a bug in 12.0, it should abort the request upon timeout and close the connection.

[lorban]

I can confirm that this is a bug in 12.0 that was fixed in 12.1 with this change: #11325

[lorban]

Since it is rather inconvenient that the only way to configure this timeout is via a system property, I've opened a new enhancement request to add a new init parameter to ResourceServlet to be able to configure that timeout more easily: #13928

[sbordet]

@lorban I don't see the fix in #11325 like you report, and 12.1.x still has the problem.

[lorban]

@sbordet the bug I'm talking about that #11325 fixes is the fact that an async timeout triggering does not abort an already committed request.