-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Michael,
On 12/4/14 4:27 AM, Osipov, Michael wrote: > Hi folks, > > we are experiencing a popular issue with MS .NET clients sending > "Expect: 100-continue" and Tomcat failing with HTTP 505. We use > Apache Tomcat 6.0.41 with APR connector on a corporate network. > > The request look like this in Wireshark: > > 1. Client sends empty request with one TCP packet What do you mean empty? Is there a request line? Headers? Is there a \r\n\r\n indicating the end of the headers? Is the "Expect" header in this packet? > 2. Tomcat responds with 401 within 20 to 30 ms 3. Client sends > another TCP packet with the request body now (401 has been > ignored) So the client sends "Expect: 100" and then ignores the non-100 response? Sounds like the .NET client is braindead. > 4. While debugging the APR Connector I see that request.getProtocol > is invoked and the message bytes contain the chomped XML with a > trailing GET request. This leads to a 505. > > I read several resources as well as bug reports in HTTPd, Tomcat > and JBoss spread over the last couple of years. The RFC 7231 [1] > says: > > Requirements for clients: o A client that sends a 100-continue > expectation is not required to wait for any specific length of > time; such a client MAY proceed to send the message body even if it > has not yet received a response. Furthermore, since 100 (Continue) > responses cannot be sent through an HTTP/1.0 intermediary, such a > client SHOULD NOT wait for an indefinite period before sending the > message body. > > The statement sheds some light on the issue but does not fully > answer the question. As far as I understand the client has received > the final status (401) from the server but did not evaluate this. > In my opinion, the client seems to be broken. > > The resources suggested to disable the header which we did and it > did work indeed, the strange thing is that the client in .NET > should wait for 350 ms before it fires the body which it doesn't. > > Can somebody tell me who is misbehaving against the RFC? Is > disabling "Expect: 100-continue" the way to go? I am pretty fine > with that if Tomcat's behavior is RFC-compliant. Using "Expect:100" is appropriate if you have a large-bodied request and you only want to use the network resources to push that body if the server is going to accept it. So, you send the "100-continue" header along with things like the Content-Type and Content-Length and see if the server says "yeah, I'll accept that" or "no way, buddy". IF the server says "yes", then you can push the actual request, which may be GiBs in size. If the server says "no", you can avoid all that data transfer and tell the user "Sorry, computer says 'no'". > PS: If someone of the project members is interested in the Wirshark > pcap file, I'll be happy to send you that to your @apache.org email > address. Pastebin the hex/text dump? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUg090AAoJEBzwKT+lPKRYIOcQAJnXpQ8Y6lsbzr44ZsuyIDA8 2AnKRSPgwgsdE3qu5QvKP/A8V+ASJOxkYTlYEr/GlWj3KCUqhXvbDbH4oMuGiaq2 HowUwxr69HciISx5EEnls5UVNDd2bAusw/lvY01JmGGltTSNubiyofCSaSyb55F8 XLs6CXGdTR4nBiau37Y326K7X8dCS8BnWQEROtu1IJsh1Yzz7wTQyRfcJhsPixW1 xKJMMDlJTjmBOT3XStYJbFbwabkQWoBLwf1h9qTBGM+0IC7CzjcyvQbO4sUU6YqH nQ9mBw2KDW3tKy3T2iGYpsm/do5tJ03JsXsYS14BcTsFM7IKJddua13h9mnNKVzH tABP/tp2iTIW99V+CzFcFHAQXb6Sf4ovlk0Mea4fdypwVzXG9W0NvAMLRccNWm3L tv+xhVwTSsyM/inuNKhmaME+Y9Wv0j15d00FBmtbtX1sr9NbZjlx+RGlgWcvm31U VOp0CeRad3/CNDfZx3xCxIUoEfAffW0Z4NQMns7P8lEF0CUY7S9p6GLrdH0k019i ACiYmzQ/yUp5CGjtHc3fHZZVCpAZBohs/y9pZqE44TRLz02uogZLuzaqc05VQjjz X2GWjJRG4NCTeIqIsrmxlUdJhtbufIsrLf9kLNzFo5ioA4/l7DO0gUken5DKGuAV N+fxh4lt2DlEoqxBmvk0 =o6qk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
