On 07/02/2019 20:05, Bhavesh Mistry wrote: > Hi Mark, > > There is no way to validate the END of a request for PUT call and if > Content-Lenght does not match what client had sent payload body then > rejected it and reset position.
You can't do that. The only way to determine how much data to expect is from the content-length header. The server has no way to determine (with any certainty) that the client has stopped sending the previous request body (or hasn't sent any body at all) and is starting to send a new request. > > If content length does match then reject PUT request, Not possible. > and then close the > connection for PUT call not for subsequent request. How can you read > ahead from TCP socket that does not have data yet for the next request? The server is going to do a blocking read (this is Servlet I/O so it is blocking) for more data. Again, the server has no way of knowing that the data that arrives is for a new request rather than the request body it was expecting. > It > request/response model so PUT request processed with wrong content length > should not impact the next request. HTTP doesn't work like that. > Another server like Jetty has no issue. The only way to guarantee that is to disable HTTP keep-alive. And I would be amazed if the Jetty folks did that by default. I suspect what you are seeing are the effects of different read timeouts. If the connection times out waiting for the client to send the data *before* the client tries to send the next request you'll get the behaviour you describe. The problem is that the server can't differentiate between slow clients and misbehaving clients so by lowering the timeout to work-around the broken clients you may end up breaking slower clients unintentionally. As I said, your best solution is to fix the broken client. Mark > > Our use case: > Client ------> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring boot). > > The failure on the SAME TCP occurs at tomcat, not at Jetty for the same TCP > connection. > > > Thanks, > Bhavesh > > > On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas <ma...@apache.org> wrote: > >> On 07/02/2019 18:48, Bhavesh Mistry wrote: >>> Hello Tomcat Developers, >>> >>> I have a unique situation about HTTP Protocol PAYLOAD parsing and >>> Content-Length Header. >> >> There is nothing unique here. >> >>> When PUT/POST Content-Length is NOT correct >>> (client send wrong Content-Lenght), the tomcat is able to parse the >>> request and respond to request with 2xx but subsequent on SAME TCP >>> connection fails with corrupted HTTP HEADER. >> >> As expected. >> >> Tomcat can't read minds. If the content length header is not correct, >> Tomcat can't correctly identify the end of the request so it is going to >> read too much / too little and - on a keep-alive connection - the next >> request is going to fail. >> >> There is nothing unusual about this. >> >> There is no Tomcat bug here. >> >> You need to fix the broken client so the content-length is correctly set. >> >> You could disable keep-alive connections. That would limit the failures >> to the faulty requests but at the cost of reduced performance. >> >> Mark >> >> --------------------------------------------------------------------- >> 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
