Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Joakim Erdfelt-8
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:

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


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


Joakim Erdfelt / [hidden email]

On Wed, Feb 15, 2017 at 10:13 AM, Lothar Kimmeringer <[hidden email]> wrote:
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
_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Lothar Kimmeringer
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/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.

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Joakim Erdfelt-8
Have you tried the HttpCompliance.RFC2616 mode in Jetty?


Set the property `jetty.http.compliance=RFC2616` and try again.

Joakim Erdfelt / [hidden email]

On Wed, Feb 15, 2017 at 10:54 AM, Lothar Kimmeringer <[hidden email]> 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/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.

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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Joakim Erdfelt-8
In reply to this post by Joakim Erdfelt-8
Either way, this has been filed/tracked as https://github.com/eclipse/jetty.project/issues/1333

Joakim Erdfelt / [hidden email]

On Wed, Feb 15, 2017 at 10:35 AM, Joakim Erdfelt <[hidden email]> wrote:
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:

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


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


Joakim Erdfelt / [hidden email]

On Wed, Feb 15, 2017 at 10:13 AM, Lothar Kimmeringer <[hidden email]> wrote:
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
_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Lothar Kimmeringer
In reply to this post by Joakim Erdfelt-8
Hi Joakim,

Am 15.02.2017 um 19:21 schrieb 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.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 ServerConnector@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 o.e.j.s.ServletContextHandler@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: <[hidden email]>
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 <[hidden email]>
To: [hidden email]
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 HttpChannelOverHttp@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 ServerConnector@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
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

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


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


Joakim Erdfelt / [hidden email]

On Wed, Feb 15, 2017 at 12:22 PM, Lothar Kimmeringer <[hidden email]> wrote:
Hi Joakim,

Am 15.02.2017 um 19:21 schrieb 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.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 ServerConnector@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 o.e.j.s.ServletContextHandler@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: <[hidden email]>
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 <[hidden email]>
To: [hidden email]
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 HttpChannelOverHttp@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 ServerConnector@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
_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Lothar Kimmeringer
In reply to this post by Lothar Kimmeringer
... answering to my own mail ;-)

Am 15.02.2017 um 20:22 schrieb 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
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Lothar Kimmeringer
In reply to this post by Joakim Erdfelt-8
Hi,

sorry for "reopening" a mail this old.

Am 15.02.2017 um 19:21 schrieb 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
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Joakim Erdfelt-8
Jetty 9.2.x is EOL (End of Life).

Please us a supported and stable version of Jetty.

9.4.12.v20180830 was released not that long ago.

Joakim Erdfelt / [hidden email]


On Mon, Oct 15, 2018 at 4:22 AM Lothar Kimmeringer <[hidden email]> wrote:
Hi,

sorry for "reopening" a mail this old.

Am 15.02.2017 um 19:21 schrieb 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
_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

Lothar Kimmeringer
Hi,

Am 15.10.2018 um 14:08 schrieb 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
_______________________________________________
jetty-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: Configuring option 2 of RFC 7230 paragraph 5 (HTTP header folding)

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

Joakim Erdfelt / [hidden email]


On Mon, Oct 15, 2018 at 9:38 AM Lothar Kimmeringer <[hidden email]> wrote:
Hi,

Am 15.10.2018 um 14:08 schrieb 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
_______________________________________________
jetty-users mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users