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: Receiving HTTP 505 on Expect: 100-continue
Date Mon, 08 Dec 2014 09:10:04 GMT
> 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
Mime
View raw message