You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Osipov, Michael" <mi...@siemens.com> on 2014/12/04 10:27:12 UTC
Receiving HTTP 505 on Expect: 100-continue
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
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)
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.
These are my resources:
https://social.msdn.microsoft.com/Forums/en-US/5c576a2d-2f13-485c-8ada-b4c3ee127d3c/http-protocol-errors-when-combining-webclient-uploads-and-digest-authentication?forum=ncl
https://issues.apache.org/bugzilla/show_bug.cgi?id=47087
http://blogs.msdn.com/b/fiddler/archive/2011/11/05/http-expect-continue-delays-transmitting-post-bodies-by-up-to-350-milliseconds.aspx
Regards,
Michael
[1] http://tools.ietf.org/html/rfc7231#section-5.1.1
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Receiving HTTP 505 on Expect: 100-continue
Posted by "Osipov, Michael" <mi...@siemens.com>.
> On 08/12/2014 08:35, Osipov, Michael wrote:
> > Hi Mark,
> >
> >> On 06/12/2014 18:48, Christopher Schultz wrote:
> >>> 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.
> >>
> >> To be fair, it could be a timing issue. The client has to guess how
> long
> >> to wait before sending the body if it doesn't get a response.
> >
> > I don't think so because request take only a few tens of milliseconds
> and
> > by default the .NET client waits for upto 350 ms according to MS'
> documentation.
> >
> >> Given the timing issues, the only thing the server can safely do for
> >> non-200 responses is send the response, close the connection and
> >> optionally swallow any request body (some clients don't even try to
> read
> >> the response until the body has been sent).
> >
> > Who should close the connection? The connector or my authenticator by
> > "Connection: close"?
>
> Tomcat will do this for you in the connector. At least it will in 7.0.x
> - see else thread for the patch that was applied.
>
> In 6.0.x your best bet would probably be a Valve to do a similar thing
> until the fix is back-ported.
I can wait for that patch to the next release. Meanwhile we will actively
disable that header in the .NET clients.
How would you recommend the valve to look like? I would need to hook in at
The end of the filter chain, check for the header and for anything above
299 and issue a "Connection: close"?
Michael
Re: Receiving HTTP 505 on Expect: 100-continue
Posted by Mark Thomas <ma...@apache.org>.
On 08/12/2014 08:35, Osipov, Michael wrote:
> Hi Mark,
>
>> On 06/12/2014 18:48, Christopher Schultz wrote:
>>> 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.
>>
>> To be fair, it could be a timing issue. The client has to guess how long
>> to wait before sending the body if it doesn't get a response.
>
> I don't think so because request take only a few tens of milliseconds and
> by default the .NET client waits for upto 350 ms according to MS' documentation.
>
>> Given the timing issues, the only thing the server can safely do for
>> non-200 responses is send the response, close the connection and
>> optionally swallow any request body (some clients don't even try to read
>> the response until the body has been sent).
>
> Who should close the connection? The connector or my authenticator by
> "Connection: close"?
Tomcat will do this for you in the connector. At least it will in 7.0.x
- see else thread for the patch that was applied.
In 6.0.x your best bet would probably be a Valve to do a similar thing
until the fix is back-ported.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Receiving HTTP 505 on Expect: 100-continue
Posted by "Osipov, Michael" <mi...@siemens.com>.
Hi Mark,
> On 06/12/2014 18:48, Christopher Schultz wrote:
> > 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.
>
> To be fair, it could be a timing issue. The client has to guess how long
> to wait before sending the body if it doesn't get a response.
I don't think so because request take only a few tens of milliseconds and
by default the .NET client waits for upto 350 ms according to MS' documentation.
> Given the timing issues, the only thing the server can safely do for
> non-200 responses is send the response, close the connection and
> optionally swallow any request body (some clients don't even try to read
> the response until the body has been sent).
Who should close the connection? The connector or my authenticator by
"Connection: close"?
Michael
RE: Receiving HTTP 505 on Expect: 100-continue
Posted by "Osipov, Michael" <mi...@siemens.com>.
> 2014-12-06 21:53 GMT+03:00 Mark Thomas <ma...@apache.org>:
> > On 06/12/2014 18:48, Christopher Schultz wrote:
> >> 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.
> >
> > To be fair, it could be a timing issue. The client has to guess how long
> > to wait before sending the body if it doesn't get a response.
> >
> > Given the timing issues, the only thing the server can safely do for
> > non-200 responses is send the response, close the connection and
> > optionally swallow any request body (some clients don't even try to read
> > the response until the body has been sent).
>
> +1.
>
> The fix for Tomcat 7 was a year ago (7.0.48) in
> http://svn.apache.org/r1540689
>
> I think that it can be backported to Tomcat 6.
Highly appreciated! Unfortunately, I cannot compile this myself at work, at least
when it is not Maven-based :-(
Should I file another issue with BZ or do we already have an existing one?
Michael
Re: Receiving HTTP 505 on Expect: 100-continue
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-12-06 21:53 GMT+03:00 Mark Thomas <ma...@apache.org>:
> On 06/12/2014 18:48, Christopher Schultz wrote:
>> 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.
>
> To be fair, it could be a timing issue. The client has to guess how long
> to wait before sending the body if it doesn't get a response.
>
> Given the timing issues, the only thing the server can safely do for
> non-200 responses is send the response, close the connection and
> optionally swallow any request body (some clients don't even try to read
> the response until the body has been sent).
+1.
The fix for Tomcat 7 was a year ago (7.0.48) in
http://svn.apache.org/r1540689
I think that it can be backported to Tomcat 6.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Receiving HTTP 505 on Expect: 100-continue
Posted by Mark Thomas <ma...@apache.org>.
On 06/12/2014 18:48, Christopher Schultz wrote:
> 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.
To be fair, it could be a timing issue. The client has to guess how long
to wait before sending the body if it doesn't get a response.
Given the timing issues, the only thing the server can safely do for
non-200 responses is send the response, close the connection and
optionally swallow any request body (some clients don't even try to read
the response until the body has been sent).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Receiving HTTP 505 on Expect: 100-continue
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org