JEP proposed to target JDK 18: 408: Simple Web Server

[Simone Bordet]

Hi,

On Fri, Oct 8, 2021 at 12:07 AM <mark.reinhold at oracle.com> wrote:
>
> The following JEP is proposed to target JDK 18:
>
>   408: Simple Web Server
>        https://openjdk.java.net/jeps/408
>
>   Summary: Provide a command-line tool to start a minimal web server
>   that serves static files in the current directory. This low-threshold
>   utility will be useful for prototyping, ad-hoc coding, and testing
>   purposes, particularly in educational contexts.

As a Jetty Project co-lead, and having witnessed:

* the number of perils in URL parsing
* the number of perils in URL decoding
* the number of perils in URL to file-system Path conversions, which
are file-system/os dependent
* the number of perils in file-system aliasing, also file-system/os dependent

I really wonder if this JEP is going to be an OpenJDK liability, also
considering that there are quite a few (and many open source) choices
out there that allow setting up a file server in less than 10 lines of
code, and that are already widely used in testing and educational
contexts, and battle tested over the course of decades.
I am not sure what this JEP proposes is really needed, as there are
plenty of other options outside the JDK.

For example, using Jetty in code:

Server server = new Server(8080);
ResourceHandler resourceHandler = new ResourceHandler();
resourceHandler.setBaseResource(new PathResource("/var/www"));
server.setHandler(resourceHandler);
server.start();

I'm pretty sure someone has wrapped the Jetty APIs into builder-style
APIs and the above can probably be folded in a single line.
I'm sure Tomcat, Undertow, etc. provide equally small snippets to do the same.

Also worth consideration is that penetration testing companies and
tools (and not only) will target what's proposed by this JEP with
special persistence, and each vulnerability discovered will be an
OpenJDK security issue that will need to be handled for the current
Java version and backported to all previous Java versions that apply.

For example, even the venerable Apache HTTPD has disclosed a path
traversal vulnerability just a few days ago, to say that no matter the
amount of experience and battle testing a vulnerability is always
behind the corner.

FWIW -- I'm an OpenJDK author, but not a committer -- my suggestion is
to dismiss this JEP and leave it to existing, decades old, proven,
feature-packed, open source projects out there.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz