> I'm looking at https://issues.jboss.org/browse/RESTEASY-1244 "Resteasy > swallowing Netty Http decoding exceptions". Netty has a limit on header > sizes, but if a too big header arrives, the header just gets ignored. It > turns out that netty passes information about the failure into Resteasy, > which is ignoring that information. > > Now, I ran the same test to see what Undertow does, and I get this: > > >> 21:43:37.135 ERROR [io.undertow.request] (XNIO-1 I/O-2) UT005006: >> Connection from /127.0.0.1:49488 terminated as request header was >> larger than 1048576 >> RESTEASY004655: Unable to invoke request This can be controlled by http listener configuration rsvoboda  rs  ~  TESTING  710DR13  $  grep -e max-header-size -e max-headers jboss-eap-7.1/docs/schema/wildfly-undertow_4_0.xsd <xs:attribute name="max-header-size" type="xs:long" default="1048576"/> <xs:attribute name="max-headers" type="xs:long" default="200"/> > That is, Undertow closes the connection, and all Resteasy can do on the > client side is ¯\_(ツ)_/¯ . At first, I thought that the server should > send back some useful information, but now I'm thinking that Undertow > suspects a Denial of Service situation. > > That seems to make sense. Now, in resteasy-netty4, the fact of the long > header is communicated to Resteasy, and I'm thinking that Resteasy > should do the same thing.

> > What do you think? > > -Ron > > -- > My company's smarter than your company (unless you work for Red Hat) > > _______________________________________________ > resteasy-dev mailing list > resteasy-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev > _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

> I'm looking at https://issues.jboss.org/browse/RESTEASY-1244 "Resteasy > swallowing Netty Http decoding exceptions". Netty has a limit on header > sizes, but if a too big header arrives, the header just gets ignored. It > turns out that netty passes information about the failure into Resteasy, > which is ignoring that information. > > Now, I ran the same test to see what Undertow does, and I get this: > > >> 21:43:37.135 ERROR [io.undertow.request] (XNIO-1 I/O-2) UT005006: >> Connection from /127.0.0.1:49488 terminated as request header was >> larger than 1048576 >> RESTEASY004655: Unable to invoke request This can be controlled by http listener configuration rsvoboda  rs  ~  TESTING  710DR13  $  grep -e max-header-size -e max-headers jboss-eap-7.1/docs/schema/wildfly-undertow_4_0.xsd <xs:attribute name="max-header-size" type="xs:long" default="1048576"/> <xs:attribute name="max-headers" type="xs:long" default="200"/> > That is, Undertow closes the connection, and all Resteasy can do on the > client side is ¯\_(ツ)_/¯ . At first, I thought that the server should > send back some useful information, but now I'm thinking that Undertow > suspects a Denial of Service situation. > > That seems to make sense. Now, in resteasy-netty4, the fact of the long > header is communicated to Resteasy, and I'm thinking that Resteasy > should do the same thing. > > What do you think? > > -Ron > > -- > My company's smarter than your company (unless you work for Red Hat) > > _______________________________________________ > resteasy-dev mailing list > resteasy-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev > _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev