In response to my posting:
>
> I am running the cern httpd server (ver 3.0) on a Dec Alpha 2100 (OSF/1 ver=
> 3.0). It appeared to work just fine and we have been using it a a=
> proxy/caching server. I ran into problems when I tried to use forms and CGI=
> scripts (the POSTs don't work but there is no error logged). Another site=
> ran into the same problem when they upgraded from OSF/1 2.0 to 3.0.=20
>
> It is mentioned in the Bug list for the cern httpd that there are some=
> strange problems when running on OSF/1 3.0 but they aren't specific and=
> they have no platform to test on.
>
> If anyone has successfully used forms on a cern_httpd_3.0 server on the =
> OSF/1 3.0 platform could they reply.
>
The replies indicated that others had experienced the same problem, had rep[orted it to CERN and no solution had been forthcoming as CERN had no OSF/1 3.0 platform to test on. This is a serious problem for us as we purchased our Dec Alpha 2100 server primarily to be a large Web server and also act as a proxy server for our campus (thus we have to run the CERN server).
Has anyone from DEC pursued this matter with CERN and what is the current situation?
------------------
Some replies:
-------------------
ian_at_persimmon.com (Ian Jones) wrote:
We experienced similar problems, we reported it to CERN (see below)
but so far no fix has been forthcoming. We no longer
use the CERN server because of this problem.
> There seems to be a problem with the CERN httpd 3.0 running over
> OSF/1 3.0 to do with sensitive images: sometimes clicking on a
> sensitive image fails to return a sensible URL.
>
> Looking at the code, the problem seems to occur when the fread from
> the pipe associated with the htimage child process does not return before
> the SIGCHILD signal is delivered to the parent. In these cases the
> fread returns an EPIPE error and no data.
>
> The order in which the signal delivery and return from fread occur
> seems random, hence the intermittent nature of the problem.
>
> Adding the following two lines to the end of HTImage.c:
>
> fclose(stdout);
> sleep(1);
>
> - just above the 'return(0)' statement seems to make the problem go
> away, at the expense of adding a second's latency to each sensitive
> image access. I suspect this is also only working probabilistically
> due to the timing of events - it is hardly a satisfactory solution in
> the long term.
>
> -- Timothy Roscoe, Persimmon I.T. Inc.
>
---------------------------------------
"Chandra R. Chegireddy" <chandra_at_phys.ufl.edu> wrote:
We ran into exactly the same problem on our machine when we upgraded to
osf/1 3.0. Clickable Image Mapping broke first and investigating it lead
to the more general cgi script problem. We reported it to CERN and they
mentioned that it is a bug and they did not have osf/1 3.0 yet to
investigate. We have since moved to NCSA server here.
----------------------------------------
senetza_at_ultrix.uleth.ca (Len Senetza) wrote:
And I thought that it was only me...
I found the same thing. I could run the script to the point when it was
doing anything which wrote to the disk, then it would stop and seem to
hang. I upgraded perl to 5.00 and tried a lot of other things as well; all
to no avail.
--------------------------------------------------
johnk_at_water.ca.gov wrote:
I decided to try a cern httpd server on one of my HP machines, couldn't
get it to run, so I went back to NCSA...
good luck!
--------------------------------------------------
-----------------------------
Monica Berko Email:Monica.Berko_at_anu.edu.au
Centre for Networked Information and Publishing Phone: (06) 279 8114
Australian National University Fax: (06) 279 8120
Received on Tue Feb 07 1995 - 00:50:42 NZDT