-----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 <url>"... > 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
