Hi Christopher, > -----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?
By empty I mean no request body but with Content-Length provided. Expect: 100-continue is provided. > > 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. Yes, that is what happens. I found the same statement over and over again. I was never happy with Microsoft quirks. > > 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'". That is my understanding of expect continue but the client is allowed for a certain amount of time for the 100 Continue and send the body right away. > > 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? I'll send you that separately via email. Please keep it private. Michael
