RE: KeepAlive and IE, again...
How does this problem relate to IE 6.0? IE 6.0 is a dangerous advent to the list of browsers. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: [EMAIL PROTECTED] -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 09, 2001 1:08 PM To: [EMAIL PROTECTED] Subject: RE: KeepAlive and IE, again... On Fri, 8 Jun 2001, Cliff Woolley wrote: On Fri, 8 Jun 2001, Geoff Thorpe wrote: (If there's Apache developers listening, this is also why threading in 2.0 won't solve the problems of 1.3, it'll just scale them back a bit - threads aren't free, they're just a small linear factor cheaper than processes - please support non-blocking I/O too, please!). This has been discussed on new-httpd in the past. But this is not a simple prospect... it would require some pretty major changes. Nevertheless, several developers have expressed an interest in giving it a shot in future versions of Apache (though NOT 2.0)... For the immediate future at least, a process/thread module (I forget the acroynm that was coined in Apache2 for such things, MTM or something like that?) that uses GNU Pth would I guess achieve some of what's required. GNU Pth, IIRC, fakes threads by replacing basically all interruptable system calls with Pth equivalents so that processing can shift between contexts (eg. selects, reads, writes, sleeps, etc etc all hook back to the Pth scheduler). In this way, only one thread/process is actually in use, but code written to *think* it's running in multiple threads can (be made to) work in this scanario too. It'd still be bulkier than application code designed to work in a non-blocking manner, but probably less bulky than using distinct real (kernel) threads per-connection. Do you think Apache could be coerced to slot into such a model? Of course, the follow up question is then; could you run fake (GNU Pth) threads inside a single real (kernel) thread, and have multiple kernel threads running in each process, and of course run multiple processes. That'd be one hell of a hybrid. Then of course, we could ask if some IPC mechanism exists so certain processes could serve specific types of requests and be folded down to different user privileges than other processes (eg. to put volatile/leaky serving inside different processes with only a few threads each, and to put stable/lightweight serving in other processes with a lot of threads). So, has someone started an Apache 5.0 branch yet? :-) Cheers, Geoff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
On Fri, 8 Jun 2001, Cliff Woolley wrote: On Fri, 8 Jun 2001, Geoff Thorpe wrote: (If there's Apache developers listening, this is also why threading in 2.0 won't solve the problems of 1.3, it'll just scale them back a bit - threads aren't free, they're just a small linear factor cheaper than processes - please support non-blocking I/O too, please!). This has been discussed on new-httpd in the past. But this is not a simple prospect... it would require some pretty major changes. Nevertheless, several developers have expressed an interest in giving it a shot in future versions of Apache (though NOT 2.0)... For the immediate future at least, a process/thread module (I forget the acroynm that was coined in Apache2 for such things, MTM or something like that?) that uses GNU Pth would I guess achieve some of what's required. GNU Pth, IIRC, fakes threads by replacing basically all interruptable system calls with Pth equivalents so that processing can shift between contexts (eg. selects, reads, writes, sleeps, etc etc all hook back to the Pth scheduler). In this way, only one thread/process is actually in use, but code written to *think* it's running in multiple threads can (be made to) work in this scanario too. It'd still be bulkier than application code designed to work in a non-blocking manner, but probably less bulky than using distinct real (kernel) threads per-connection. Do you think Apache could be coerced to slot into such a model? Of course, the follow up question is then; could you run fake (GNU Pth) threads inside a single real (kernel) thread, and have multiple kernel threads running in each process, and of course run multiple processes. That'd be one hell of a hybrid. Then of course, we could ask if some IPC mechanism exists so certain processes could serve specific types of requests and be folded down to different user privileges than other processes (eg. to put volatile/leaky serving inside different processes with only a few threads each, and to put stable/lightweight serving in other processes with a lot of threads). So, has someone started an Apache 5.0 branch yet? :-) Cheers, Geoff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: KeepAlive and IE, again...
Typically these sites don't run SSL on the server. It's terminated at the switch hardware, many net gear vendors have SSL accelerators that emulate a connection to the server. The end user doesn't know the difference. And you bind the SSL cert to the net device. That doesn't change the fact that this hardware can get keepalives to work for MSIE, but we can't for mod_ssl. Has anyone had a chance to try the settings I posted earlier? As soon as I get a free minute I'm going to test it on a variety of browsers I've got here. I've been using these settings: SetEnvIf User-Agent MSIE [1-4] nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 SetEnvIf User-Agent MSIE [5-9] ssl-unclean-shutdown and it seems to do the trick (keeping the fingers crossed) The difference for my app is dramatic! My typical scenario is a fat pipe with a long roundtrip. You wouldn't believe how much of an impact keepalive makes! Igor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
I've been using these settings: SetEnvIf User-Agent MSIE [1-4] nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 SetEnvIf User-Agent MSIE [5-9] ssl-unclean-shutdown and it seems to do the trick (keeping the fingers crossed) The difference for my app is dramatic! My typical scenario is a fat pipe with a long roundtrip. You wouldn't believe how much of an impact keepalive makes! Cool, I'll give these settings a shot on my development machines and let the list know if there's any problems. -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
Hey there, On Fri, 8 Jun 2001, David Rees wrote: I've been using these settings: SetEnvIf User-Agent MSIE [1-4] nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 SetEnvIf User-Agent MSIE [5-9] ssl-unclean-shutdown and it seems to do the trick (keeping the fingers crossed) The difference for my app is dramatic! My typical scenario is a fat pipe with a long roundtrip. You wouldn't believe how much of an impact keepalive makes! Cool, I'll give these settings a shot on my development machines and let the list know if there's any problems. It probably goes without saying - but using KeepAlives on has some pretty evil consequences because of Apache's process model. As long as the connection is kept alive between browser and server, the httpd process that owns it is *dedicated* to that connection, even if nothing is happening with it, and thus can't serve anything else. If you start to make a mental picture of loads of browsers holding loads of keepalive connections open for say 30 seconds each, you'll start to realise where this can come unstuck. There's also the other angle too: any old x86 with a tcp/ip stack and a modem can open a few (hundred) connections to your server and keep reconnecting whenever they're disconnected, the result can be quite annoying. This is the same reason that the Timeout should be kept as low as acceptable, otherwise the same old x86 can trickle bytes through 1-by-1 to prevent getting timed out, and tie up a number of your server processes for as long as they see fit. (If there's Apache developers listening, this is also why threading in 2.0 won't solve the problems of 1.3, it'll just scale them back a bit - threads aren't free, they're just a small linear factor cheaper than processes - please support non-blocking I/O too, please!). Cheers, Geoff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geoff Thorpe There's also the other angle too: any old x86 with a tcp/ip stack and a modem can open a few (hundred) connections to your server and keep reconnecting whenever they're disconnected, the result can be quite annoying. This is the same reason that the Timeout should be kept as low as acceptable, otherwise the same old x86 can trickle bytes through 1-by-1 to prevent getting timed out, and tie up a number of your server processes for as long as they see fit. Yep, I thought of this, what do you consider an acceptable timeout for keep alives? The default KeepAliveTimeout is 15 seconds, the default Timeout is 300 seconds. It seems to me that even without keep alives turned on it's trivial for a client to flood the server with a few hundred connect requests to keep Apache processes busy, so turning on keep alives doesn't really do anything but tie up httpd processes for longer under normal loads. -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
On Fri, 8 Jun 2001, Geoff Thorpe wrote: (If there's Apache developers listening, this is also why threading in 2.0 won't solve the problems of 1.3, it'll just scale them back a bit - threads aren't free, they're just a small linear factor cheaper than processes - please support non-blocking I/O too, please!). This has been discussed on new-httpd in the past. But this is not a simple prospect... it would require some pretty major changes. Nevertheless, several developers have expressed an interest in giving it a shot in future versions of Apache (though NOT 2.0)... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
The problem with IE can occur if the server closes the idle connection first. In your sniffs which end closed the connection? -Original Message- From: Igor Plotnikov [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 07, 2001 4:07 PM To: [EMAIL PROTECTED] Subject: KeepAlive and IE, again... Folks, I know the issue of IE being unable to work with modssl has been brought up before. The conclusion expressed in the FAQ is - IE is buggy, disable keepalive for IE, and that's it. I've spent just a little time looking at https://www.microsoft.com which obviously runs on IIS5.0, and sniffing the traffic. On the surface it looks like both IE and Netscape keep the sockets open for a minute, and reuse them with no problem. I didn't dig too deep, but these observations raise the question again. Is it possible to have mod_ssl support keepalives with IE, even in a dirty way? Apparently IIS does it, to a great performance benefit! Thanks! Igor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
Typically these sites don't run SSL on the server. It's terminated at the switch hardware, many net gear vendors have SSL accelerators that emulate a connection to the server. The end user doesn't know the difference. And you bind the SSL cert to the net device. -Original Message- From: Igor Plotnikov [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 07, 2001 3:07 PM To: [EMAIL PROTECTED] Subject: KeepAlive and IE, again... Folks, I know the issue of IE being unable to work with modssl has been brought up before. The conclusion expressed in the FAQ is - IE is buggy, disable keepalive for IE, and that's it. I've spent just a little time looking at https://www.microsoft.com which obviously runs on IIS5.0, and sniffing the traffic. On the surface it looks like both IE and Netscape keep the sockets open for a minute, and reuse them with no problem. I didn't dig too deep, but these observations raise the question again. Is it possible to have mod_ssl support keepalives with IE, even in a dirty way? Apparently IIS does it, to a great performance benefit! Thanks! Igor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: KeepAlive and IE, again...
Wallace, William wrote: The problem with IE can occur if the server closes the idle connection first. In your sniffs which end closed the connection? The client sent RST, after a minute wait. igor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of McCaffity, Ray Typically these sites don't run SSL on the server. It's terminated at the switch hardware, many net gear vendors have SSL accelerators that emulate a connection to the server. The end user doesn't know the difference. And you bind the SSL cert to the net device. That doesn't change the fact that this hardware can get keepalives to work for MSIE, but we can't for mod_ssl. Has anyone had a chance to try the settings I posted earlier? As soon as I get a free minute I'm going to test it on a variety of browsers I've got here. -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: KeepAlive and IE, again...
Hi, I haven't had a chance to test it, but how about this? BrowserMatch MSIE [1-4] nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 This would allow all MSIE 5.X browsers to connect normally. But even those may need this: BrowserMatch MSIE 5 ssl-unclean-shutdown Of course, remove your existing SetEnvIf line. -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Igor Plotnikov Sent: Thursday, June 07, 2001 1:07 PM To: [EMAIL PROTECTED] Subject: KeepAlive and IE, again... Folks, I know the issue of IE being unable to work with modssl has been brought up before. The conclusion expressed in the FAQ is - IE is buggy, disable keepalive for IE, and that's it. I've spent just a little time looking at https://www.microsoft.com which obviously runs on IIS5.0, and sniffing the traffic. On the surface it looks like both IE and Netscape keep the sockets open for a minute, and reuse them with no problem. I didn't dig too deep, but these observations raise the question again. Is it possible to have mod_ssl support keepalives with IE, even in a dirty way? Apparently IIS does it, to a great performance benefit! Thanks! Igor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: KeepAlive and IE, again...
The problem with IE can occur if the server closes the idle connection first. In your sniffs which end closed the connection? Correction to my previous reply... IE sends RST in a minute, even though the server timeout is 2 min, and this ends the conversation. Both sides silently close the socket... Netscape honestly waits for the RST from the server, and this also ends the exchange - no shutdown, both sides close sockets. Igor __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
