Any chance someone took a look at the PR? Do you guys think this is a viable solution?
On Sun, Apr 21, 2024 at 12:54 PM Adwait Kumar Singh <adwsi...@gmail.com> wrote: > 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 >> >>
