[jetty-users] Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

[Lothar Kimmeringer]

Hi,

I switched from 9.2 to 9.3 and two dozens of testcases now fail due
to the fact that they create HTTP-requests containing folded HTTP-
request-headers. I'm aware of Bug 444222 where it's mentioned that
Jetty 9.3 will follow RFC 7230 more strictly so I know why I now
get HTTP 400 responses.

The RFC allows to ways of reacting to folded HTTP-headers:

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

Since we use Jetty as HTTP-server for AS2, WebService- and RESTful-
Service data exchanges on a couple thousand distinct installations
where we have absolutely no control over the other side sending in
these requests, the default-behavior will definetly break production
EDI setups. So I'm forced to use option 2 of the RFC.

How can I set up Jetty to replace line-breaks to spaces in order
to keep existing data exchanges running with the new version?


Thanks and best regards,

Lothar Kimmeringer

[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).

eg:

TRACE http://www.company.com/ HTTP/1.1
Host: www.company.com
Connection: Close
(blank line)

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Wed, 15 Feb 2017 09:44:21 GMT
Content-Type: message/http
Connection: close
Server: ImpressiveServer/1.2.3.4 (Unix)
Connection: close
Via: 1.1 bogusproxy

9d
TRACE / HTTP/1.1
Connection: keep-alive
Host: www.company.com
Via: 1.1 bogusproxy
X-Foo: Value1,
Value2,
Value3
X-Forwarded-For: 111.69.185.59, 111.69.5.234

0


It was removed from the spec specifically because it causes security
issues. (header injection)
Note: Internet Explorer, Chrome, Firefox, and most proxies do not support
header folding anymore.

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)

The spec is pretty clear https://tools.ietf.org/html/rfc7230#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.


Your clients MUST NOT send folded http headers.
It is highly unlikely that Jetty will reintroduce header folding.
You'll have to make a very good (security minded) case for it.

Post by Lothar Kimmeringer
Hi,
I switched from 9.2 to 9.3 and two dozens of testcases now fail due
to the fact that they create HTTP-requests containing folded HTTP-
request-headers. I'm aware of Bug 444222 where it's mentioned that
Jetty 9.3 will follow RFC 7230 more strictly so I know why I now
get HTTP 400 responses.
| 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.
Since we use Jetty as HTTP-server for AS2, WebService- and RESTful-
Service data exchanges on a couple thousand distinct installations
where we have absolutely no control over the other side sending in
these requests, the default-behavior will definetly break production
EDI setups. So I'm forced to use option 2 of the RFC.
How can I set up Jetty to replace line-breaks to spaces in order
to keep existing data exchanges running with the new version?
Thanks and best regards,
Lothar Kimmeringer
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

[Lothar Kimmeringer]

Hi,

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/rfc7230#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.

Post by Lothar Kimmeringer
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

[Joakim Erdfelt]

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.

Post by Lothar Kimmeringer
Hi,

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.

A server that receives an obs-fold in a request message that is not

Post by Lothar Kimmeringer
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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

[Lothar Kimmeringer]

Hi Joakim,

Post by Joakim Erdfelt
Have you tried the HttpCompliance.RFC2616 mode in Jetty?

since I wasn't aware of that, no ;-)

Post by Joakim Erdfelt
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.

I set the configuration first by setting it in a static block within my classes and
after that as property being set as run-conguration. Both tries failed. Here some
code how I set that up:

System.out.println("Starting HTTP-server with comliance setting: " + System.getProperty("jetty.http.compliance"));
Server hs = new Server();
ServerSocket ss = new ServerSocket(0);
LISTEN_PORT = ss.getLocalPort();
ss.close();
hs.setServerName("testserver"+LISTEN_PORT);
assertNotNull("check existance of testserver", Server.getServer("testserver"+LISTEN_PORT));
ServerConnector sconn = new ServerConnector(hs, new ConnectionFactory[]{
new HttpConnectionFactory(),
});
sconn.setPort(LISTEN_PORT);
hs.addConnector(sconn);
assertNotNull("check existance of testserver after second call", Server.getServer("testserver"+LISTEN_PORT));
ContextHandlerCollection coll = new ContextHandlerCollection();
hs.setHandler(coll);
hs.start();

[...]

Server is a class derived by me from the jetty-Server-class providing the
method getServer(String) in case you wonder.

These are the logs given out (plus some debug-text outputted by my testcase:

Starting HTTP-server with comliance setting: RFC2616
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.Server doStart
INFORMATION: jetty-9.3.z-SNAPSHOT
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.AbstractConnector doStart
INFORMATION: Started ***@1c93084c{HTTP/1.1,[http/1.1]}{0.0.0.0:27848}
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.Server doStart
INFORMATION: Started @1224ms
[...]
20:05:42 NORMAL SYSTEM:AS2:AS2PARTNERMANAGER(AUTH) Started
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Setting context for servlet with server 'testserver27848', context '/project/*' and pathSpec '/AS2Retrieve/*'
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Trying to start HTTP-Context /project'
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.handler.ContextHandler doStart
INFORMATION: Started ***@50eac852{/project,null,AVAILABLE}
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Adding servlet to context
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Trying to set callback to servlet
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Set callback to servlet
[...]
20:05:43 NORMAL SYSTEM:SERVICEFACTORY Started all configured subsystems
=========================
POST /project/AS2Retrieve/ HTTP/1.1
Message-ID: <***@example.com>
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; name=filename.dat;
smime-type=compressed-data
Content-Transfer-Encoding: binary
Disposition-notification-options: signed-receipt-protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1,md5
AS2-Version: 1.1
Content-Disposition: attachment;filename=filename.dat
Date: Mon, 11 Jul 2005 11:40:54 +0200
From: Lothar Kimmeringer <***@example.com>
To: ***@example.com
AS2-From: as2from
AS2-To: as2to
Subject: Other Subject
Content-Length: 175
Host: 127.0.0.1:27848
Connection: close

[...]
=========================
Feb 15, 2017 8:05:43 PM org.eclipse.jetty.http.HttpParser parseNext
WARNUNG: bad HTTP parsed: 400 Header Folding for ***@6d4ba4da{r=0,c=false,a=IDLE,uri=null}
stopping server
Stopping listener 27848
Feb 15, 2017 8:05:45 PM org.eclipse.jetty.server.AbstractConnector doStop
INFORMATION: Stopped ***@1c93084c{HTTP/1.1,[http/1.1]}{0.0.0.0:27848}


The request is a fixed text in the testcase in case you wonder about the Date.
The debug output shows that the system property is really set but it seems
to be ignored.


Thanks and cheers, Lothar

[Joakim Erdfelt]

You are still seeing "400 Header Folding".
That's only seen during the 7230 compliance mode.

https://github.com/eclipse/jetty.project/blob/jetty-9.3.16.v20170120/jetty-http/src/main/java/org/eclipse/jetty/http/HttpParser.java#L1003-L1004

The 2616 compliance mode wasn't set for that connector.

Post by Lothar Kimmeringer
Hi Joakim,

Post by Joakim Erdfelt
Have you tried the HttpCompliance.RFC2616 mode in Jetty?

since I wasn't aware of that, no ;-)
https://github.com/eclipse/jetty.project/blob/jetty-9.3.16.

Post by Joakim Erdfelt
v20170120/jetty-server/src/main/config/etc/jetty-http.xml#L32
Set the property `jetty.http.compliance=RFC2616` and try again.

I set the configuration first by setting it in a static block within my classes and
after that as property being set as run-conguration. Both tries failed. Here some
System.out.println("Starting HTTP-server with comliance
setting: " + System.getProperty("jetty.http.compliance"));
Server hs = new Server();
ServerSocket ss = new ServerSocket(0);
LISTEN_PORT = ss.getLocalPort();
ss.close();
hs.setServerName("testserver"+LISTEN_PORT);
assertNotNull("check existance of testserver",
Server.getServer("testserver"+LISTEN_PORT));
ServerConnector sconn = new ServerConnector(hs, new ConnectionFactory[]{
new HttpConnectionFactory(),
});
sconn.setPort(LISTEN_PORT);
hs.addConnector(sconn);
assertNotNull("check existance of testserver after second
call", Server.getServer("testserver"+LISTEN_PORT));
ContextHandlerCollection coll = new
ContextHandlerCollection();
hs.setHandler(coll);
hs.start();
[...]
Server is a class derived by me from the jetty-Server-class providing the
method getServer(String) in case you wonder.
Starting HTTP-server with comliance setting: RFC2616
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.Server doStart
INFORMATION: jetty-9.3.z-SNAPSHOT
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.AbstractConnector doStart
0.0.0.0:27848}
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.Server doStart
[...]
20:05:42 NORMAL SYSTEM:AS2:AS2PARTNERMANAGER(AUTH) Started
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Setting context for servlet with
server 'testserver27848', context '/project/*' and pathSpec '/AS2Retrieve/*'
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Trying to start HTTP-Context /project'
Feb 15, 2017 8:05:42 PM org.eclipse.jetty.server.handler.ContextHandler doStart
50eac852{/project,null,AVAILABLE}
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Adding servlet to context
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Trying to set callback to servlet
20:05:42 NORMAL SYSTEM:AS2:AS2SERVICE: Set callback to servlet
[...]
20:05:43 NORMAL SYSTEM:SERVICEFACTORY Started all configured subsystems
=========================
POST /project/AS2Retrieve/ HTTP/1.1
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; name=filename.dat;
smime-type=compressed-data
Content-Transfer-Encoding: binary
Disposition-notification-options: signed-receipt-protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1,md5
AS2-Version: 1.1
Content-Disposition: attachment;filename=filename.dat
Date: Mon, 11 Jul 2005 11:40:54 +0200
AS2-From: as2from
AS2-To: as2to
Subject: Other Subject
Content-Length: 175
Host: 127.0.0.1:27848
Connection: close
[...]
=========================
Feb 15, 2017 8:05:43 PM org.eclipse.jetty.http.HttpParser parseNext
WARNUNG: bad HTTP parsed: 400 Header Folding for
stopping server
Stopping listener 27848
Feb 15, 2017 8:05:45 PM org.eclipse.jetty.server.AbstractConnector doStop
0.0.0.0:27848}
The request is a fixed text in the testcase in case you wonder about the Date.
The debug output shows that the system property is really set but it seems
to be ignored.
Thanks and cheers, Lothar
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

[Lothar Kimmeringer]

... answering to my own mail ;-)

Post by Lothar Kimmeringer
ServerConnector sconn = new ServerConnector(hs, new ConnectionFactory[]{
new HttpConnectionFactory(),
});

should have been
ServerConnector sconn = new ServerConnector(hs, new ConnectionFactory[]{
new HttpConnectionFactory(new HttpConfiguration(), HttpCompliance.RFC2616),
});

With that the request goes through.

Thanks for creating the feature request for the support of option 2 of the RFC.

Since I don't want to be forced to change the jetty.xml-files out there I
solved the setting of the compliance-setting programmatically by overwriting
doStart in my Server-class:


@Override
protected void doStart() throws Exception {
super.doStart();
Connector[] conns = getConnectors();
for (int i = 0; i < conns.length; i++) {
Connector c = conns[i];
if (!(c instanceof ServerConnector)) {
continue;
}
@SuppressWarnings("resource")
ServerConnector sc = (ServerConnector) c;
HttpConnectionFactory factory = sc.getConnectionFactory(HttpConnectionFactory.class);
if (factory == null) {
continue;
}
factory.setHttpCompliance(HttpCompliance.RFC2616);
}
}

If your RFE goes through I can remove that block again ;-)


Thanks and cheers, Lothar

[Lothar Kimmeringer]

Hi,

sorry for "reopening" a mail this old.

Post by Joakim Erdfelt
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.

Is this still a feature in Jetty? I downloaded Jetty 9.2.26 and ran into
a compilation error at the line that sets the compliance:

factory.setHttpCompliance(HttpCompliance.RFC2616)

The method and the class that is passed to it aren't part of Jetty
anymore.

https://github.com/eclipse/jetty.project/issues/1333
is still open, so does that mean, that folded http-request-headers will
now lead to 400-errors leading to interop failures without the ability
to solve that problem by configuration?


Thanks and best regards,

Lothar Kimmeringer

[Joakim Erdfelt]

Jetty 9.2.x is EOL (End of Life).

Please us a supported and stable version of Jetty.
https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html

9.4.12.v20180830 was released not that long ago.

Post by Lothar Kimmeringer
Hi,
sorry for "reopening" a mail this old.

Post by Joakim Erdfelt
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

Post by Joakim Erdfelt
Set the property `jetty.http.compliance=RFC2616` and try again.

Is this still a feature in Jetty? I downloaded Jetty 9.2.26 and ran into
factory.setHttpCompliance(HttpCompliance.RFC2616)
The method and the class that is passed to it aren't part of Jetty
anymore.
https://github.com/eclipse/jetty.project/issues/1333
is still open, so does that mean, that folded http-request-headers will
now lead to 400-errors leading to interop failures without the ability
to solve that problem by configuration?
Thanks and best regards,
Lothar Kimmeringer
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

[Lothar Kimmeringer]

Hi,

Post by Joakim Erdfelt
Jetty 9.2.x is EOL (End of Life).
Please us a supported and stable version of Jetty.
https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
9.4.12.v20180830 was released not that long ago.

I'm aware of that but my question concerning the compliance-configuration
stays the same (or is Jetty 9.4 still allowing to set the compliance
as shown in my mail)?


Thanks and cheers, Lothar

[Joakim Erdfelt]

HttpCompliance features were added in Jetty 9.4.x (and then at a later date
had a partial backport to 9.3.x)

Post by Joakim Erdfelt
Hi,

Post by Joakim Erdfelt
Jetty 9.2.x is EOL (End of Life).
Please us a supported and stable version of Jetty.

https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html

Post by Joakim Erdfelt
9.4.12.v20180830 was released not that long ago.

I'm aware of that but my question concerning the compliance-configuration
stays the same (or is Jetty 9.4 still allowing to set the compliance
as shown in my mail)?
Thanks and cheers, Lothar
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

[Joakim Erdfelt]

Either way, this has been filed/tracked as
https://github.com/eclipse/jetty.project/issues/1333

Post by 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).
TRACE http://www.company.com/ HTTP/1.1
Host: www.company.com
Connection: Close
(blank line)
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Wed, 15 Feb 2017 09:44:21 GMT
Content-Type: message/http
Connection: close
Server: ImpressiveServer/1.2.3.4 (Unix)
Connection: close
Via: 1.1 bogusproxy
9d
TRACE / HTTP/1.1
Connection: keep-alive
Host: www.company.com
Via: 1.1 bogusproxy
X-Foo: Value1,
Value2,
Value3
X-Forwarded-For: 111.69.185.59, 111.69.5.234
0
It was removed from the spec specifically because it causes security
issues. (header injection)
Note: Internet Explorer, Chrome, Firefox, and most proxies do not support
header folding anymore.
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)
The spec is pretty clear https://tools.ietf.org/html/rfc7230#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.
Your clients MUST NOT send folded http headers.
It is highly unlikely that Jetty will reintroduce header folding.
You'll have to make a very good (security minded) case for it.

Post by Lothar Kimmeringer
Hi,
I switched from 9.2 to 9.3 and two dozens of testcases now fail due
to the fact that they create HTTP-requests containing folded HTTP-
request-headers. I'm aware of Bug 444222 where it's mentioned that
Jetty 9.3 will follow RFC 7230 more strictly so I know why I now
get HTTP 400 responses.
| 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.
Since we use Jetty as HTTP-server for AS2, WebService- and RESTful-
Service data exchanges on a couple thousand distinct installations
where we have absolutely no control over the other side sending in
these requests, the default-behavior will definetly break production
EDI setups. So I'm forced to use option 2 of the RFC.
How can I set up Jetty to replace line-breaks to spaces in order
to keep existing data exchanges running with the new version?
Thanks and best regards,
Lothar Kimmeringer
_______________________________________________
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users