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 <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
>
>

Reply via email to