Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pawel, On 2/7/19 19:41, Pawel Veselov wrote: > Sorry for a rather rude intrusion. If you think it's rude, why did you do it? > On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz > wrote: > >> Chunked encoding is like sending a bunch of small HTTP >> message-pieces (I have to be careful about my wording here, since >> "part" actually means something in multipart messages > > May be just "chunks"? :) Defining a word using the word itself is circular-reasoning. If you looked-up "chunk" in the dictionary and it said: "Chunk: (n) chunk", you'd be kind of lost, wouldn't you? >> Then, you send each chunk with a chunk size (in decimal bytes), a >> CRLF pair, then your content, and another CRLF pair. The final >> chunk has a length of 0 (zero): >> >> 32 [32 bytes of data] 128 [128 bytes of data] 0 > > Chunk sizes are expressed in hexadecimal notation, though, not > decimal. Yes, thank you for the correction. Those numbers should have been: 20 [32 bytes of data] 80 [128 bytes of data] 0 - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxdkOAACgkQHPApP6U8 pFgxQBAAk8GXkkc4bXp0Uf4JmaBtxthDrRIqs6eUx6wqjQdeJgTCAGUIF4274j9k bmfaYWx0d4/ZZ4yibrD/7RjSn3ezSaE69x1beYs7UaFZTdooA8azspMCgh0iDmx1 OcbYFpo2qjrsA0GIoxmP8qBbSCXV/guw/OmCRmj4LFBV3hc5+ADu4ioxcko6jWSa hNxmBNcpH8nlUqeNeb3bSK/fh1FKBHQFEVe46KI0dXkYVoTNfoTqKohxyzRpMh/h xhMb0MWyad04F6k0gBuoaCnzsuq5ZKdnKRXuslpidhFT3Jc2/NdGBpQcYhjYoGgT 2PHVgrlshu+CTl5Gn/6KvFUGE2O0yyRuirpv6iQZ9kQ/3Gn3FlrgT5ZxhHbRZ1B7 7a98TegGyRn5KQ4YvJkpjGljtkfxBjjRfvA1NBhdHRplUuaxB4U/mROccDCVXVr9 YybUVGNwP1Zd4no8B4NKtDyAGXFtgkJz/SCCmZ4F5EYkCAXLRnNZ27nXfrA6XYYO QxOe7XaAy9PMKiaW7L+wIevHeXPhrPlgus4usS/F1ZelDxY6nY1oekJmpCTX4gnm HlgrLIA35YGPjQGVhqtvQhJGSg+JQGIX5Azj98fjJ0hypy1obHXOtvCe+/O93i/q OsRj9gcxXybTTp24G1U8J03p0s+o3q7gb9Tf9La/AqrB4hvpZLA= =1Oqx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Sorry for a rather rude intrusion. On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz wrote: > Chunked encoding is like sending a bunch of small HTTP message-pieces > (I have to be careful about my wording here, since "part" actually > means something in multipart messages May be just "chunks"? :) > Then, you send each chunk with a chunk size (in decimal bytes), a CRLF > pair, then your content, and another CRLF pair. The final chunk has a > length of 0 (zero): > > 32 > [32 bytes of data] > 128 > [128 bytes of data] > 0 Chunk sizes are expressed in hexadecimal notation, though, not decimal. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Hi Chuck, Thank for your answer and details explanation. We have requested our customer to fix the wrong client. Are there any logs we can see if the content length does not match? Once again thanks for your help! Thanks, Bhavesh On Thu, Feb 7, 2019 at 4:03 PM Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] > > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length > Corrupting > > Parsing logic for Subsequent Request > > > I am stating following when you have request/response on the same TCP > > connection. for example, > > > My understanding (please correct me if my wrong): > > It's wrong. All TCP traffic, including HTTP requests, is a stream of > bytes. > There are no indications where one request ends and another starts other > than the content length in each request. If the malformed request > specifies > a length smaller than the actual content size, the next request will appear > to start somewhere in the content stream. Similarly, if the > request-specified content length is larger than the sent size, the > connector > consumes part of the next request as the content of the prior. There is no > way for a server to correct this client misbehavior, other than by the > server administrator disabling keep-alive - with serious performance > impacts > for well-mannered clients. Fix your broken client. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bhavesh, On 2/7/19 19:11, Christopher Schultz wrote: > The Content-Length of the PUT request says "I'm going to send 128 > bytes". The server is required to accept exactly 128 bytes, no more > no less. There is another option, here, but also requires that the client still not be broken. Instead of guessing at the Content-Length and then being wrong about it, you can use "chunked" encoding. Chunked encoding is like sending a bunch of small HTTP message-pieces (I have to be careful about my wording here, since "part" actually means something in multipart messages), each with its own Content-Length . First, you send the request like this: PUT /foo/bar HTTP/1.1 Host: example.com Connection: keep-alive Transfer-Encoding: chunked Then, you send each chunk with a chunk size (in decimal bytes), a CRLF pair, then your content, and another CRLF pair. The final chunk has a length of 0 (zero): 32 [32 bytes of data] 128 [128 bytes of data] 0 (this is the end of the message) This is great for streaming, because you might not know the size of the content before you have generated it all. Buffering the whole message might be impractical. If the client's problem is that it's not sure what the Content-Length should be until the message is sent, then you can use chunked encoding to solve that problem. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcyu8ACgkQHPApP6U8 pFhTqg/+Jepl5JnlqViLSh15wyFBYwnBWEiR+d+12B6+21XtJP14yIaw6pnCp0FW cc/SkLeUl4qywcqRp0f3af8Ub3hb9tE7VB8kMwGiNinUvWp0oDe6kRh8fBBXpHPo Q/0Sk0OtZS1cHZt2zmzFe5ml8iWn86YPOUVBKuFRCt9yo8630HG/EVD8TZ181FyJ JbySM+dfkQkhGhow6T59YMR0MxH0FembPnXQ3PQu8NSpmJ+r/7cAbnI0emmNjbNj xne956Wfb9gIINZI7ch7dmpJcwC4yX7jAibt2f/OFwQ1hrp8XFUPBZpvEjEH2JDp Y0+wxJ2pAaedqaLwtkob4xo+R6ZGYuyNEn43jM56CqIZV1qfUhVquUTaWkLi6uKy lwyHTaHxwKQPhdu6y7qQ+aZfoOp6/TLz5Os6OkjTEbixY120jrTPx1FTvq8rSI07 K3V4FvvCQz7cmfv2ya0aUBKnvCT+LytWKDfdLye8TRX0y8QFVC1n+8mGOEdL1vcl SPa/tCXtmhpJ/LS+n+fQPsqhV+niLc2fFhgUeVZGDv/uFo3BH/8rOCLJLo7N5jg3 GXRoLql0NQX2amdkbzPniY4+mvw/8lRwZeH+4JPfJeBeAIfhY4hIb1taNreTcEN7 sPZAl29SogZuARJG8ch9ZJkV8gfpGjZebfgzJLSMh3g7aIOHA9I= =ZG7h -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bhavesh, On 2/7/19 18:40, Bhavesh Mistry wrote: > Hi Mark, > > I understand what you are stating the root of issue originated with > the client (wrong client). I am stating following when you have > request/response on the same TCP connection. for example, > > My understanding (please correct me if my wrong): > > Client ---SAME TCP > SOCKET--Server 1)PUT API > Content-Lenght: 419 2)server reads header and content body > > Response 2XX > > 3)Client Read response. > > 4)Client SEND GET Request > > GET API HTTP1/1.1 > > 5) Server reads it (now tomcat reads request GET request due to > the position of previous wrong content) CAN reset position of > reading here? No, Tomcat cannot do this. How does Tomcat know that the previous request has actually NOT ended? What happens if the request looks like this: PUT /foo/bar Host: example.com Connection: keep-alive Content-Length: 128 [64 bytes of whatever] GET /goo/bar Host: example.com Connection: keep-alive Content-Length: [...] That looks like two requests, but it's only one. Why? Because the Content-Length is (in this case, intentionally) wrong. The Content-Length of the PUT request says "I'm going to send 128 bytes". The server is required to accept exactly 128 bytes, no more no less. (Most servers will fail due to a timeout if the content is too *short* and the end of the message never arrives.) That 128 bytes extends beyond the 64 bytes actually sent and into the "next" request. There is no magic "end of file" byte that the client can send to say "yes, I know I said I was going to send you 128 bytes but I changed my mind at the last second and well, sorry". That just doesn't exist in HTTP. The same is true with a pair of requests like this: PUT /foo/bar Host: example.com Connection: keep-alive Content-Length: 32 0123456789abcde 0123456789abcde 0123456789abcde 0123456789abcde GET /goo/bar Host: example.com Connection: keep-alive Content-Length: [...] That's two requests, but the second request starts with the text "0123456789abcde" and not "GET /foo/bar", because the first request sent too much data. The server is *required* to stop after Content-Length bytes, full stop. It is NOT in the spec that the server should ignore text in a request that looks like garbage until it sees something like "GET "... > 6) The server sends 400 with a close connection. 7) Client Read > response. > > So, if you look request/response model, how can tomcat read ahead > on PUT call on a socket the data is not there? It's not reading "ahead". The data is already there, and it looks like a pipelined request from the client. Your problem is that you are thinking that the software is smarter than it is. Just because it's obvious to YOU what is going on doesn't mean that the HTTP specification agrees with your opinion about how things should work. I often call this type of thing "do-what-I-mean semantics". It generally means that the person who wants a job done can't articulate exactly how to do it with instructions for all the edge cases and so they just say "I want it to do the right thing all the time" -- usually by reading the mind of the user. It's tough to implement requirements like that. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcyTMACgkQHPApP6U8 pFiiOg/+LYfuwLdumv9JKCmSU2cSCOt4sAOivGwI3YS+XLX2RUy04GIpYEHQm6kb xHEOmo2krIhnSGqjnZnWJtsJdqlSHxLNtBu53pXxKa72fq6GtsGweCzDqxZUmvS5 iZxKIfSBMqdN8urg8zBTp7WlrP2Gu97F/5XvN9jTX5cgA6FbgHkfhkq0m34rM43K iQ7KetqMzgwVX4kVG9VEt3jJv/1cNNfHIZlhDU2RRlFh3ZV0S0eXnbjDE80jcsfI OkWQDKhqnRKMTunvzYaZ6aCsweQl7VVcw+QQRu8n/LMtvt85p/WVI6sMR//Kjl+T ij+l9v8GVbEFfmAK034hbQCfb+7x/0HH6uEA4U0nAoa090fIQLFk8aScy2gTRnaW 25dJ3kEnqGiD90mGsEpuyTD+kWjW6VtRk0XYxaPmCCXODAiPHPsvTNRYa40V6IJh h3lAVpE3/LGpWgGnjNTcw/yXpRYC33xg0B8HPWdJWB+1EK2IpKcfrIp159vPt5YJ V2ZABGVkd3kQ8qgpCCi7ibM4mIoI6RJrRJddXb2h2U8mhDn7ZaMFFGnaNJZi+rej JGdc0or9av/tZLKQLGYZlYSyU2yw8b3yCXApxjH4uC61mIl6pXjNmI4r1EMHd+58 SmH8dWU5vfXmFwRYr727Zp6NMioqldEM8ET2V1xi8UWPYVM1A0s= =jEde -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
> From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting > Parsing logic for Subsequent Request > I am stating following when you have request/response on the same TCP > connection. for example, > My understanding (please correct me if my wrong): It's wrong. All TCP traffic, including HTTP requests, is a stream of bytes. There are no indications where one request ends and another starts other than the content length in each request. If the malformed request specifies a length smaller than the actual content size, the next request will appear to start somewhere in the content stream. Similarly, if the request-specified content length is larger than the sent size, the connector consumes part of the next request as the content of the prior. There is no way for a server to correct this client misbehavior, other than by the server administrator disabling keep-alive - with serious performance impacts for well-mannered clients. Fix your broken client. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Hi Mark, I understand what you are stating the root of issue originated with the client (wrong client). I am stating following when you have request/response on the same TCP connection. for example, My understanding (please correct me if my wrong): Client ---SAME TCP SOCKET--Server 1)PUT API Content-Lenght: 419 2)server reads header and content body Response 2XX 3)Client Read response. 4)Client SEND GET Request GET API HTTP1/1.1 5) Server reads it (now tomcat reads request GET request due to the position of previous wrong content ) CAN reset position of reading here? 6) The server sends 400 with a close connection. 7) Client Read response. So, if you look request/response model, how can tomcat read ahead on PUT call on a socket the data is not there? Thanks, Bhavesh On Thu, Feb 7, 2019 at 1:51 PM Mark Thomas wrote: > 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 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 > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
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 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
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
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. If content length does match then reject PUT request, 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? It request/response model so PUT request processed with wrong content length should not impact the next request. Another server like Jetty has no issue. 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 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 > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
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
