Have you tried the HttpCompliance.RFC2616 mode in Jetty? https://github.com/eclipse/jetty.project/blob/jetty-9.3.16.v20170120/jetty-server/src/main/config/etc/jetty-http.xml#L32
Set the property `jetty.http.compliance=RFC2616` and try again. Joakim Erdfelt / [email protected] On Wed, Feb 15, 2017 at 10:54 AM, Lothar Kimmeringer <[email protected]> wrote: > Hi, > > Am 15.02.2017 um 18:35 schrieb Joakim Erdfelt: > >> The "message/http" content-type is typically only seen in the response >> body content >> to a TRACE method (which is unsupported by Jetty for security reasons). >> > > I know but that was not the point of my mail. > > It was removed from the spec specifically because it causes security >> issues. (header injection) >> > > I know, I've read the bug report I mentioned in my original mail > > Note: Internet Explorer, Chrome, Firefox, and most proxies do not support >> header folding anymore. >> > > The other side of EDI-installations are seldom browsers but other programs > implemented in whatever programming language you can think of decades ago > and uable to be changed. > > What are you trying to do is going to be increasingly more difficult as >> time goes >> on (not only will Jetty reject it, but so must http proxies and the like) >> > > Not sure about proxies since that part of the RFC mandates > proxies to do the replacement to spaces at least for the response- > headers so it's logical (at least for me) to expect the same thing > to happen for the request headers. > > >> The spec is pretty clear https://tools.ietf.org/html/rf >> c7230#section-3.2.4 >> >> Historically, HTTP header field values could be extended over >> multiple lines by preceding each extra line with at least one space >> or horizontal tab (obs-fold). This specification deprecates such >> line folding except within the message/http media type >> (Section 8.3.1 <https://tools.ietf.org/html/rfc7230#section-8.3.1>). >> A sender MUST NOT generate a message that includes >> line folding (i.e., that has any field-value that contains a match to >> the obs-fold rule) unless the message is intended for packaging >> within the message/http media type. >> > > You ignored the subsequent paragraph I explicitly quoted to make my point: > > A server that receives an obs-fold in a request message that is not >>> within a message/http container MUST either reject the message by >>> sending a 400 (Bad Request), preferably with a representation >>> explaining that obsolete line folding is unacceptable, or replace >>> each received obs-fold with one or more SP octets prior to >>> interpreting the field value or forwarding the message downstream. >>> >> > Your clients MUST NOT send folded http headers. >> > > My (HTTP-)clients don't do that but the clients of others that communicate > with my server. I have no control over these and they are sending > important stuff that escalate quicker than you can say "just in > time deliveries are going to be delayed" if the server stops accepting > it due to this issue. > > It is highly unlikely that Jetty will reintroduce header folding. >> You'll have to make a very good (security minded) case for it. >> > > My case is "Real Life" and since replacing newlines by spaces is > explicitly mentioned in the RFC as legal I need to go this way > to keep my sanity when shipping a release with Jetty 9.3 "underneath". > > > Thanks and cheers, Lothar > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
