The HTTP RFC(s) require that method names are case-sensitive, so that "Get" and "GET" are considered different methods. Jetty releases prior to 9.4 used a case-insensitive cache to match method names, thus this requirement was violated. Deployments which wish to retain this legacy violation can include this violation in the HttpCompliance mode.

The HTTP RFC(s) require that field names are case-insensitive, so for example the fields "Content-Type: text/xml" and "content-type: text/xml" are considered equivalent. Jetty has been optimized to take advantage of this by looking up field names in a case-insensitive cache and will by default provide the standard capitalisation of a field name rather than create a new string with the actual capitalisation received. However, some applications have been written to expect a specific capitalisation of field, so deployments of such applications must include this violation in their HttpCompliance mode to prevent Jetty altering the case of the fields received. Jetty itself will still match and handle fields names insensitively and this violation only affects how the names are reported to the application. There is a small performance and garbage impact of using this mode.

Since RFC 7230: Section 5.4, the HTTP protocol says that a Server must reject a request duplicate host headers. A deployment may include this violation to allow duplicate host headers on a received request.

Since RFC 7230, the expectation that HTTP/0.9 is supported has been removed from the specification. If a deployment wished to accept HTTP/0.9 requests, then it can include this violation in it's HttpCompliance mode.

Since RFC 7230: Section 5.4, the HTTP protocol must reject a request if the target URI has an authority that is different than a provided Host header. A deployment may include this violation to allow different values on the target URI and the Host header on a received request.

Since RFC 7230, the HTTP protocol no longer supports line folding, which allows a field value to be provided over several lines. Deployments that wish to receive folder field values may include this violation in their HttpCompliance mode.

Since RFC 7230, the HTTP protocol has required that a request is invalid if it contains multiple Content-Length fields or values. The request may be treated as invalid even if the multiple values are the same. A deployment may include this violation to allow multiple Content-Length values to be received, but only if they are identical.

Prior to RFC 7230, the HTTP protocol allowed a header line of a single token with neither a colon nor value following, to be interpreted as a field name with no value. A deployment may include this violation to allow such fields to be in a received request.

Since RFC 7230, the HTTP protocol has required that a request is invalid if it contains both a Transfer-Encoding field and Content-Length field. A deployment may include this violation to allow both fields to be in a received request.

Since RFC 7230, the HTTP protocol should reject a request if the Host headers contains an invalid / unsafe authority. A deployment may include this violation to allow unsafe host headesr on a received request.

Since RFC 7230, the HTTP protocol has required that a request header field has no white space after the field name and before the ':'. A deployment may include this violation to allow such fields to be in a received request.