https://github.com/apache/tomcat/pull/723 is a draft PR of the idea I was talking about earlier, i.e close the connection on a bad request but otherwise allow it to be configurable by the user.
Currently you need to subclass Http11Processor and override statusDropsConnections, but this is just to get early feedback. If people are aligned with this approach, I can polish the PR (add tests, make the status code list actually configurable etc etc) On Fri, Apr 19, 2024 at 5:51 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Harri, > > On 4/19/24 08:10, Harri Pesonen wrote: > > I have developed a restful web service, which uses HTTP response codes > 200 OK, 201 Created, 204 No Content and 404 Not Found. > > It does not use 400 Bad Request or 500 Internal Server Error normally. > > 400 Bad Request is more common than 500 Internal Server Error, which > should basically never happen. > > I disagree. There aren't many good 5xx errors, so sometimes "500 Oops" > is the best you can do. HTTP 5xx doesn't even really allow you to > differentiate between "server error" and "application error". > > > 400 Bad Request is the best response in many cases, if client gives some > query parameter which is not supported by the application logic. > > -1 > > 400 means that the HTTP request is bad. In your situation, the HTTP > request is 100% valid. It's your application that is saying "sorry, > client, you did something we don't allow". This is an application-level > error, not a protocol-level error. To me, 400 means "HTTP protocol > error" and should never be substituted for "application protocol error". > > > I think that it would be better not to close connection in this case, if > the error comes from application. > > I wonder if there is option for application to define that connection > should be closed or not after the response has been sent? > > Or is the option only from the client. > > > > For me this 404 Not Found is also a small problem, as it is error, but > it can happen quite often. > > HTTP errors are not nice in logs. > > Normally if you try to fetch some restful resource, which does not > exist, then it returns 404 Not Found. > > GET /service/resource/id => 404 Not Found > > If I now had an option to rewrite the service, I would probably use 204 > No Content in this case as well, to avoid errors. > > 404 and 204 are fundamentally different responses. 404 means "this > resource does not exist" and 204 means "this resource DOES EXIST but it > doesn't contain anything". Your application may not differentiate > between those two cases, but as a client I would be confused if "Not > Found" was replaced by "Found to be empty" in all cases. > > > 204 No Content is normally used with PUT and DELETE requests. > > Yes, you can use those. 200 would also make sense and, of course 201 for > new resources. > > -chris > > > -----Original Message----- > > From: Christopher Schultz <ch...@christopherschultz.net> > > Sent: perjantai 19. huhtikuuta 2024 14.27 > > To: users@tomcat.apache.org > > Subject: Re: Tomcat closes connections on unexpected status codes > > > > Mark, > > > > On 4/18/24 11:38, Mark Thomas wrote: > >> On 18/04/2024 15:16, Adwait Kumar Singh wrote: > >>> I think we should *always* close connections in cases where it can > >>> lead to request smuggling vulnerabilities like when there is an error > >>> during header or request line parsing, but allowing the user to > >>> control connection close when the status is being set by the user, > >>> should be safe? > >> > >> I'm not (yet) convinced distinguishing between those scenarios is > >> always going to be possible. > >> > >>> It allows users to send back responses like InvalidInputException > >>> with a > >>> 400 status without being forced to close the connection. > >> > >> I appreciate why a 400 is used here but 400 has always struck me as > >> more for protocol level issues rather than application level issues. > > > > Didn't someone tell me recently that, technically, ANY client-error is > allowed to trigger a 400 response without being more specific? > > > >> That is the fundamental problem here. The status codes are being used > >> for two completely different purposes. > > > > +1 > > > > I've always found it distasteful when REST services do this. To me, 400 > means "the request was actually malformed". If you need authentication, > that's a 401. If you aren't allowed, that's 403. If you didn't provide a > required header, that's a 412, etc. I've usually found the "correct" > > response code to use for every situation and I've never written an > application that returns a 400 response directly. > > > > -chris > > > >>> On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat <r...@apache.org> > wrote: > >>> > >>>> On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas <ma...@apache.org> wrote: > >>>>> > >>>>> On 18/04/2024 09:07, Stefan Ansing wrote: > >>>>>> Hi, > >>>>>> > >>>>>> We've observed some unexpected behaviour in Apache Tomcat (version > >>>> 10.1.19) > >>>>>> where we see that HTTP/1.1 connections are closed whenever a > >>>>>> servlet application returns the following status codes: 400, 408, > >>>>>> 411, 414, > >>>> 500, > >>>>>> 503, 501. This causes client applications to rapidly reconnect and > >>>> induce > >>>>>> high server-side CPU load due to doing TLS handshakes. > >>>>>> > >>>>>> The 400 and 500 status codes are commonly used in RESTful > >>>> microservices to > >>>>>> communicate errors. Reviewing RFC 9112 I couldn't find any > >>>>>> requirement > >>>> for > >>>>>> closing connections on these status codes. > >>>>>> > >>>>>> After testing with Undertow (version 2.3.12), where we didn't see > >>>>>> the > >>>> same > >>>>>> behaviour, we believe that these status codes do not necessitate a > >>>>>> new connection. > >>>>> > >>>>> The Tomcat developers disagree. Connections are closed after these > >>>>> status codes to avoid various forms of request smuggling attacks. > >>>>> > >>>>>> Checking the Tomcat sources makes me believe that the behaviour is > >>>>>> hard-coded[1]. I'm reaching out here to re-evaluate the list of > >>>>>> status codes and to discuss the possibilities of making the > >>>>>> behaviour > >>>> configurable. > >>>>> > >>>>> Making this list of status codes configurable seems reasonable. The > >>>>> default can stay as current and if users want to change it then > >>>>> they have to accept the associated security risks. > >>>> > >>>> If it's insecure, then it would still be a valid CVE even if the > >>>> configuration is optional. We don't have an "allowSmuggling" > >>>> attribute on the connector to relax header or status line parsing, > >>>> even though many would have wanted it in the past ... > >>>> > >>>> Rémy > >>>> > >>>>> Mark > >>>>> > >>>>> > >>>>>> > >>>>>> A colleague of mine reported a bug for this issue: > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >>>>>> bz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D68901&data=05%7C02% > >>>>>> 7Charri.pesonen%40sinch.com%7C66e83fa3469b43288fe608dc6063a357%7C3 > >>>>>> b518aae89214a7b8497619d756ce20e%7C0%7C0%7C638491228268558870%7CUnk > >>>>>> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > >>>>>> haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l%2B6E%2BRgRxQmicXQ9ZOQpkIc > >>>>>> kaFzl70rI7O8ltNNvbSs%3D&reserved=0 > >>>>>> > >>>>>> Kind regards, > >>>>>> Stefan Ansing > >>>>>> > >>>>>> [1]: > >>>>>> > >>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > >>>> thub.com%2Fapache%2Ftomcat%2Fblame%2Fbc900e0100de9879604b93af4722c27 > >>>> 2ab3d1a24%2Fjava%2Forg%2Fapache%2Fcoyote%2Fhttp11%2FHttp11Processor. > >>>> java%23L604-L617&data=05%7C02%7Charri.pesonen%40sinch.com%7C66e83fa3 > >>>> 469b43288fe608dc6063a357%7C3b518aae89214a7b8497619d756ce20e%7C0%7C0% > >>>> 7C638491228268567937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > >>>> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fcgz% > >>>> 2Bw473MyShaMac3v9yN%2BEnNfnX39x919bajNtC1U%3D&reserved=0 > >>>>>> > >>>>> > >>>>> ------------------------------------------------------------------- > >>>>> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>> > >>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
