On 01/02/2019 20:33, Bhavesh Mistry wrote: > Hi Mark, > > *Correction!* > > Thank you very much for your answer. The server should **reject** the > wrong request which PUT with Wrong Content-Length and not GET request. > > We have been using Jetty for our server --> Apache Camel Proxy --> Spring > boot. Jetty handle this gracefully. Spring boot (embedded tomcat does > not). > > Is this correct behavior as expected?
Please take this to the users list. Note the mailing lists drop most attachments. Mark > > Thanks, > Bhavesh > > On Fri, Feb 1, 2019 at 12:30 PM Bhavesh Mistry <mistry.p.bhav...@gmail.com> > wrote: > >> Hi Mark, >> >> Thank you very much for your answer. The server should reset the wrong >> request which PUT with Wrong Content-Length and not GET. >> >> We have been using Jetty for our server --> Apache Camel Proxy --> Spring >> boot. Jetty handle this gracefully. Spring boot (embedded tomcat does >> not). >> >> Is this correct behavior as expected? >> >> Thanks, >> Bhavesh >> >> On Fri, Feb 1, 2019 at 12:20 PM Mark Thomas <ma...@apache.org> wrote: >> >>> On 01/02/2019 20:10, Bhavesh Mistry wrote: >>>> Hello Tomcat Developers, >>>> >>>> I have a unique situation about HTTP Protocol PAYLOAD parsing and >>>> Content-Length Header. 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. >>> >>> That is expected behaviour when you have a broken client. >>> >>> Mark >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
