No, opening another browser window, or one on another machine, is not successful either as long as the first one is still open. I ran HTTP::Daemon in the debugger and it became immediately obvious that the problem is opening the first IE window in the backticks: When cmd.exe runs the first instance of IE, i.e. the first window to open, IE never "returns" or completes the process of opening the window, so the web server code blocks at that point and never drops into the connect loop, until that first window is closed. By contrast, if another IE instance is already open, opening all later ones does get a "return", so no blocking and everything runs fine. So it's really not an HTTP::Daemon issue at all, but strictly a Windows/cmd.exe/IE question. It's possible that any browser would do this. I haven't tested Firefox yet.
Why things have to work this way I'm not sure. Perhaps some Windows/IE guru on this list can elucidate this behavior for us. Jim Eshelman www.nepm.net Network Monitoring with a difference ----- Original Message ----- From: "Tom Metro" <[EMAIL PROTECTED]> To: "James Eshelman" <[EMAIL PROTECTED]> Cc: "L-boston-pm" <[email protected]> Sent: 05/09/2005 1:16 AM Subject: Re: [Boston.pm] Bizare HTTP::Daemon <=> IE problem on Windows James Eshelman wrote: > I have a special purpose http server made from HTTP::Daemon... [...] > > Failure scenario: > -No IE window open on the server host: > -create the server; > -open the startup window for the process in IE (i.e. open an html > startup file on the local file system) to GET the config file from the > server ; > -loop the server waiting for a connection and request; > -send the http GET request (i.e. SUBMIT the form with the desired > filename filled in); > = NOTHING, no request is ever received by the server! If you open another browser window and issue another request to your HTTP::Daemon server, will the earlier request then get processed? If so, then I've observed the same problem with HTTP::Daemon on Win32 and Mozilla family browsers. In my observation the problem is intermittent, and I never did track down the cause. It appeared to be a low-level problem with the socket I/O, such as the accept() call not returning when it should or something buggy in the listen queue. I remember playing around with the Listen attribute to the IO::Socket::INET constructor, but without luck. Though maybe the problem is specific to HTTP::Daemon, as I have an SMTP proxy that uses IO::Socket::INET on Win32 and doesn't seem to suffer from this. -Tom _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
