Embedded Jetty ServletContextHandler unexpectedly returns 405 for POST requests

[brettkail-wk]

Jetty version(s)
12.1.9

Jetty Environment
ee

HTTP version
N/A

Java version/vendor (use: java -version)
N/A

OS type/version
N/A

Description
When using embedded Jetty with a ServletContextHandler (not a WAR), requests without a matching servlet are handled by ServletHandler.Default404Servlet (not DefaultServlet). For this configuration, it seems like Default404Servlet should return 404 for all methods, not just GET.

I've looked at related issues #11889 (and #10231), but those seem to be discussing DefaultServlet, where 405 is reasonable since the servlet is matching all possible resources, and POST isn't supported in that context.

I found ServletHandler.setEnsureDefaultServlet(false), and that does produce 404 for POST, but it also prevents filters from running. It seems like the intent of Default404Servlet (commit c21ce11, bug 417023) was to enable filters to run but otherwise to not change the 404 handling. It seems like the intent of setEnsureDefaultServlet (commit 8855b79, bug 433431) was to allow fallback handling, not as a workaround to avoid the 405 handling.

How to reproduce?
Here is a crude test program demonstrating the scenarios. It starts a server and then executes requests for GET+POST on an unmatched context, a matched context with Default404Servlet, and a matched context without Default404Servlet.

public static void main(String[] args) throws Exception {
  final int port = 8000;
  Server server = new Server(port);
  HttpFilter filter = new HttpFilter() {
    @Override
    protected void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException {
      System.out.println("- " + req.getRequestURL());
      chain.doFilter(req, res);;
    }
  };
  ServletContextHandler ch1 = new ServletContextHandler("/test-context1");
  ch1.addFilter(filter, "/*", null);
  ServletContextHandler ch2 = new ServletContextHandler("/test-context2");
  ch2.addFilter(filter, "/*", null);
  ch2.getServletHandler().setEnsureDefaultServlet(false);
  server.setHandler(new ContextHandlerCollection(ch1, ch2));
  server.start();

  try (var closeable = (AutoCloseable) server::stop) {
    for (String path : new String[] {
        "/doesnotexist",
        "/test-context1/doesnotexist",
        "/test-context2/doesnotexist"
    }) {
      for (String method : new String[] { "GET", "POST" }) {
        URL url = URI.create("http://localhost:" + port + path).toURL();
        HttpURLConnection uc = (HttpURLConnection) url.openConnection();
        uc.setRequestMethod(method);
        int status = uc.getResponseCode();
        String s;
        try {
          s = new String(uc.getInputStream().readAllBytes());
        } catch (IOException e) {
          s = e.toString();
        }
        System.out.println(method + " " + url + "\n\t" + status + ": " + s);
        uc.disconnect();
      }
    }
  }
}

I expected 404 for all combinations, but POST on the matched context with Default404Servlet produces 405. It seems like changing Default404Servlet to override service rather than doGet would give the desired result.

[joakime]

In testing of DefaultServlet just now (Jetty 12.1.9, using ee11)

A POST to DefaultServlet for a resource that exists is a 405
A POST to DefaultServlet for a resource that doesn't exist is a 405
A POST to DefaultServlet for the root resource directory is a 405
A GET to DefaultServlet for a resource that exists is a 200
A GET to DefaultServlet for a resource that doesn't exists is a 404
A GET to DefaultServlet for the root resource directory is a 302 to the welcome file

First, DefaultServlet per the servlet spec, only handles GET.
But if you reach the point of the url-pattern / (default) being used, then all methods should return a useful response.
A 405 Method Not Allowed makes sense for a status code in this situation.
A POST is, by definition, not suitable for DefaultServlet, so return 405.
In fact, the 405 you are getting is from the Servlet spec HttpServlet class itself.

• https://github.com/jakartaee/servlet/blob/6.1.0-RELEASE/api/src/main/java/jakarta/servlet/http/HttpServlet.java#L331-L335

The DefaultServlet only has special case handling of POST, but only if the request is a DispatcherType ERROR, all other request go to the Servlet Spec HttpServlet implementation that returns 405.

• https://github.com/jetty/jetty.project/blob/jetty-12.1.9/jetty-ee11/jetty-ee11-servlet/src/main/java/org/eclipse/jetty/ee11/servlet/DefaultServlet.java#L82-L88

[brettkail-wk]

Understood, but I'm not using DefaultServlet.

[joakime]

The Default404Servlet and DefaultServlet behave the same with regards to POST.
Both return 405 Method Not Allowed.

[brettkail-wk]

I understand the reason for that behavior for DefaultServlet, but I don't understand for Default404Servlet, which seems to exist only to allow filters to work, so it seems like it should uniformly return 404 for all methods.