Re: [MacPerl] MacPerl and [A]CGI startup time

[Clay Kasow <ckasow@reed.edu>]

>Clay, please confirm this and fix.  Everyone who downloaded it, please run
>a virus program.  I am checking the rest of my drive as we speak, but I
>don't think it is on anywhere else, as I did this just a few weeks ago and
>found no viruses.  I took a fresh copy of the .sit and unstuffed it and
>disinfected it, and found the virus again.

I've fixed everything (famous last words).  I have released a new and CLEAN
version of the MacPerl WebServer (1.0b2.8) in which Eric Hsu's bug is
fixed.  Here's the rundown:

I scanned my hard drive for viruses only to find that (whew!) it was
completely clean.  However, I too observed that the
"MacPerlWebServer1.0b2.7.sit.hqx" archive at my web site was infected.  For
about seven minutes I was completely mystified.

I then remembered that I had uploaded the "MacPerlWebServer1.0b2.7.sit.hqx"
file to my web site from a Macintosh down in the Reed College computer
labs.  That slimy computer down there must have been infected with that
darn MBDF virus.  And probably a dozen others as well.

I am really, really sorry about this.  I should never have been so careless
as to upload from a computer I did not know was clean from viruses.  I hope
that no serious harm has come from this...

I've now put a CLEAN and VIRUS FREE (I checked each file three times.  I
promise!) release of version b2.8 at my site.

Version b2.8 also contains a fix of the bug reported by Eric Hsu:

>(1) Early versions of Netscape on the Mac and PC (i.e. before 3) report
>an odd broken pipe error sporadically. I can't tell what causes this,
>but MSIE doesn't seem to care. It doesn't seem to correlate with server
>activity.

The cause for this bug was simple.  In previous versions of the server, all
output from CGIs went directly to the socket filehandle without any error
checking, and without checking to see if the socket filehandle was ready
for writing by using a "select" call.

The only reason for this was laziness on my part.  I was foolishly hoping
it would all just work out.

Now, output from a CGI goes to a temp file which is then uploaded to the
client just like any other requested file - i.e. the upload is multitasked
with all other uploads to all other clients and there is error checking and
the whole works.  The temp file is then deleted.

Persistant connections are now maintained through CGI requests.  In
previous versions, the server disconnected from the client after CGI
execution.

On the user side, there is no change in the way you need to configure the
server and your CGIs.

The server still processes CGIs at the same blazing speed minus a few
milliseconds of hard drive access time.

Good luck, and let me know how it works for you!

Clay Kasow
ckasow@reed.edu
http://www.reed.edu/~ckasow



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch