We recently switched from Jetty v 6_1_26 to 9_4_11.
We followed following url: http://jetty.4.x6.nabble.com/Configuring-option-2-of-RFC-7230-paragraph-5-HTTP-header-folding-td4966330.html
And made required changes in our code to set the compliance mode to RFC2616 as we need multiple-line header support in our product.
This is how we have set it:
public class JettyPsServerConnector extends ServerConnector {
public JettyServerConnector(Server server, PsSelectorProvider psProvider,Map<String,String> configMap, boolean useSSL) throws Exception{
super(server,0,-1, new SslConnectionFactory( getSSLContextFactory(configMap),HttpVersion.HTTP_1_1.asString()),
new HttpConnectionFactory( getHTTPConfiguration(), HttpCompliance.RFC2616 ));
}
And we have verified it successfully using following code that the compliance mode is getting changed.
Connector[] connectorArray = server.getConnectors();
for(Connector conn: connectorArray){
Collection col = conn.getConnectionFactories();
for(ConnectionFactory con: col){
if (con instanceof HttpConnectionFactory)
System.out.println("HTTP Compliance Mode:"+((HttpConnectionFactory)con).getHttpCompliance());
}
}
This prints compliance mode as 'RFC2616'.
But even after setting the compliance mode to RFC2616 - we still see this issue.
Bad Message 400: Folding Header
We are hitting our server code through a proxy server in between.
We are not able to figure out what can cause this.
First, don't extend from
ServerConnector
unless you fully (and I mean 100%) understand the entireHttpConnectionFactory
andEndpoint
behaviors within Jetty 9.x. One tiny mistake and you will break many things. This is not intended to be an extensible public API and will likely be marked final in a future version of Jetty.If you need custom behavior, start by looking at the
HttpConfiguration.Customizer
, then if you still need other customization, use a customHttpConnectionFactory
instead.Next, know that
HttpCompliance
is just a holder for a Set/Collection ofHttpComplianceSection
settings. You might want to ensure that you don't have theHttpComplianceSection.NO_FIELD_FOLDING
included in your chosenHttpCompliance
setting.Finally, make sure you get those problematic clients identified and fixed, the trend in recent years to be more and more strict with HTTP, due to the numerous security issues that the relaxed behaviors (such as your line folding) cause/create. There will be a day where even your load balancer, proxy, router, etc will reject those kinds of requests too.
The obsolete RFC2616 was updated for many reasons, a large chunk was to specifically call out certain behaviors (such as line folding) as dangerous using language such as
MUST NOT
(a phrase defined clearly in RFC2119 Section 2) making the behavior non-optional for the updated specs. The reason the IETF deprecated Header Field line folding in 2013 was due to many security issues related to variations of Header injection vulnerabilities. With header field line folding enabled, you have no protection against response splitting, session fixation, cross-site scripting, security origin checks, and malicious redirection.Many modern firewalls / gateways / routers / load balancers do not support header folding.
Also note that HTTP/2 does not support header folding.
If correcting those problematic clients is not possible (for whatever reason) then your only option is to not upgrade any of your server software from here on out to delay that day from occurring. (other intermediaries outside of your control can fail those requests before it even reaches you!)
Anyway, here's a standalone demo of this behavior with RFC2616 compliance mode and Line Folding.
Output ...
If you change the
HttpCompliance
mode to say RFC7230, you'll get a different result.