The Apache Log4j2 library has suffered a series of critical security issues (see this page at the Log4j2 project). Eclipse Jetty by default does not use and does not depend on Log4j2 and therefore Jetty is not vulnerable and thus
Community Projects & Contributors Take on Jakarta EE 9

With the recent release of JakartaEE9, the future for Java has never been brighter. In addition to headline projects moving forward into the new jakarta.* namespace, there has been a tremendous amount of work done throughout the community to stay
Jetty 10 and 11 Have Arrived!

The Eclipse Jetty team is proud to announce the release of Jetty 10 and Jetty 11! Let’s first get into the details of Jetty 10, which includes a huge amount of enhancements and upgrades. A summary of the changes follows.
Renaming Jetty from javax.* to jakarta.*

The Issue The Eclipse Jakarta EE project has not obtained the rights from Oracle to extend the Java EE APIs living in the javax.* package. As such, the Java community is faced with a choice between continuing to use the
Indexing/Listing Vulnerability in Jetty

If you are using DefaultServlet or ResourceHandler with indexing/listing, then you are vulnerable to a variant of XSS behaviors surrounding the use of injected HTML element attributes on the parent directory link. We recommend disabling indexing/listing or upgrading to a
Eat What You Kill without Starvation!

Jetty 9 introduced the Eat-What-You-Kill[1]The EatWhatYouKill strategy is named after a hunting proverb in the sense that one should only kill to eat. The use of this phrase is not an endorsement of hunting nor killing of wildlife for food
CometD 4.0.0 Released

The CometD Project is happy to announce the availability of CometD 4.0.0. CometD 4.0.0 builds on top of the CometD 3.1.x series, bringing improvements and new features. You can find a migration guide at the official CometD documentation site. What’s
Fast MultiPart FormData
Jetty’s venerable MultiPartInputStreamParser for parsing MultiPart form-data has been deprecated and replaced by the much more efficient MultiPartFormInputStream, based on a new MultiPartParser. This is much faster, but less forgiving of non-compliant format. So we have implemented a legacy mode
Conscrypting native SSL for Jetty

By default, Jetty uses the JSSE provider from the JVM for SSL, which has three significant problems: It’s slow! It doesn’t support ALPN in Java 8, which is needed for HTTP/2 It’s REALLY slow! There are workarounds for both problems:
HTTP Trailers in Jetty

HTTP/1.1 and HTTP/2 have the concept of trailers, that is HTTP headers that can be sent after the message body, in both requests and responses. In HTTP/1.1 trailers can be sent using the chunked transfer coding, for example in requests