On Mon, May 31, 1999 at 09:13:43AM -0400, David Harris wrote:
[...]
> I want to know if I can solve the problem with just the ssl-unclean-shutdown
> flag. I hate to disable the keepalive functionality because of the
> performance hit it would create.
It could work (unless the user tries to follow a link in a certain
time-frame after the server closed the connection), provided that the
server OS allows Apache to do a shutdown(..., SHUT_WR).
Here's what I managed to find out about the MSIE behaviour:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Fri, 21 May 1999 19:47:00 +0200
From: Bodo Moeller <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: MSIE and ssl-unclean-shutdown
Message-ID: <[EMAIL PROTECTED]>
Lines: 43
On Fri, May 21, 1999 at 01:00:02PM +0200, Bodo Moeller wrote:
>> When I
>> understand you correctly, the problem can be those platforms where Apache
>> doesn't do the lingering close, right?
> Could be, yes. Netscape does not recognize the shutdown until the TCP
> connection is closed (i.e. a FIN arrives -- I think the actual
> close_notify is just ignored), and it checks for this only when it
> wants to reuse the open connection -- if IE behaves like that, but
> additionally tries to send its own close_notify when this happens,
> then it cannot work, because it will get a RST if the server has
> totally closesd the connection by then. So there's the I/O error.
I've done some tests now ... IE sends its request and ignores both the
server's shutdown *and* the TCP FIN (while Netscape finally gets the
idea of closing a connection when the FIN arrives). Finally the
server sends a RST, and IE prints its error message. And for the
record, the SSL/TLS server at www.microsoft.com does not send any
closure alerts at all -- after having sent its application data it
resets (!) the connection. So neither TLS nor TCP are handled
correctly by it. (At the HTTP port, it closes the connection
cleanly.) IE doesn't mind if the connection has disappeared by the
time it wants to launch its next request, but it complains if this
happens *after* the new request has been started.
This behaviour does not cause noticeable problems if the server resets
the connection before the browser starts its next request. But it
obviously cannot work reliably, only heuristically: The server cannot
know when the peer's TCP has delivered all data to the browser, and if
the RST arrives too early, it kills the active connection; similarly,
if the server's reset is sent concurrently with the brower's next
request, an error message is inevitable. Another example of Microsoft
quality :-)
I've also looked at a connection between a Netscape client and server:
At the end, the server sends its close_notify, then a FIN, and finally
a RST -- the latter probably helps to cope with IE browsers.
> What those browsers should do, of course, is select() for readability
> on all their open connections even while they are not used, so that
> they can detect a FIN and, in the SSL/TLS case, incoming alerts and
> the like at once.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Sat, 22 May 1999 14:16:24 +0200
From: [EMAIL PROTECTED] (Bodo Moeller)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: MSIE and ssl-unclean-shutdown
Message-ID: <19990522141623.A13002@epsilon>
Lines: 19
On Fri, May 21, 1999 at 07:47:00PM +0200, Bodo Moeller wrote:
> I've done some tests now ... IE sends its request and ignores both the
> server's shutdown *and* the TCP FIN (while Netscape finally gets the
> idea of closing a connection when the FIN arrives). Finally the
> server sends a RST, and IE prints its error message. And for the
> record, the SSL/TLS server at www.microsoft.com does not send any
> closure alerts at all -- after having sent its application data it
> resets (!) the connection. So neither TLS nor TCP are handled
> correctly by it. (At the HTTP port, it closes the connection
> cleanly.) IE doesn't mind if the connection has disappeared by the
> time it wants to launch its next request, but it complains if this
> happens *after* the new request has been started.
I'd guess (but have not tested myself) that just sending a FIN and not
resetting the connection should also work, *as long as you don't send
a SSL/TLS close_notify*. What IE cannot handle is when after it has
sent its request there are still bytes available to recv(), namely the
close_notify alert.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
