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

[Simone Bordet]

Hi,

On Mon, Oct 11, 2021 at 7:18 PM Julia Boes <julia.boes at oracle.com> wrote:
>
> Hi Simone,
>
> On 09/10/2021 17:32, Simone Bordet wrote:> 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
>
> Let me start by saying that this JEP does not add new functionality, but rather
> exposes existing implementations. The Simple Web Server is located in
> jdk.httpserver/com.sun.net.httpserver, a package that has been there since 2006
> (JDK 1.6) and that is officially supported.

Sorry, but considering that truly official java.* APIs are being
removed, I fail to understand how classes in jdk.* or com.sun.* are
"officially supported", when it was made very clear that developers
should not depend on those because they can change without any advice,
etc.
Can you clarify what you mean here?

> The original motivation for the jdk.httpserver module was to support web
> services callbacks, which can indeed get dangerous quite quickly. The Simple Web
> Server however is very different, it only serves static files and only supports
> the idempotent GET and HEAD requests. As such it is much easier to secure.

Now I am really confused.
If the original motivation was to support web services callbacks, but
now it doesn't, then it seems that serving files is a use case that
nobody asked for?
I may be too old to understand what "developer activation energy"
means -- but to me feels too weak to justify this JEP.

> With regard to the security considerations, let me summarize the central points
> from the JEP, which in their sum help us be confident about this enhancement.

[snip]

Your list is fine, but my experience and that of other major server
developers was the same: we were confident, but got CVEs.

> It is true that plenty of alternatives exist, I mention some of them in the JEP.
> While that can be an argument for not "reinventing the wheel", it can also be an
> argument for the opposite: The variety of existing choices is a testament to the
> recognized need and usefulness of such a tool. If such a static server is
> commonly used in a variety of scenarios, why should it not be in the JDK,
> particularly if it's merely an extension of the existing server implementation
> in com.sun.net.httpserver?

Sorry, but the list of tools for which "The variety of existing
choices is a testament to the recognized need and usefulness of such a
tool" and therefore needs to be included in OpenJDK is quite long, and
I can think of many that would be more relevant than this JEP.

Anyway, I said mine about this JEP :)

Thanks!

Regards
-- 
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