tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Receiving HTTP 505 on Expect: 100-continue
Date Sat, 06 Dec 2014 18:48:21 GMT
Hash: SHA256


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 email
> address.

Pastebin the hex/text dump?

- -chris
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message