tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Osipov, Michael" <michael.osi...@siemens.com>
Subject Re: Re: Receiving HTTP 505 on Expect: 100-continue
Date Mon, 08 Dec 2014 08:21:00 GMT
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
Mime
View raw message