You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Dana C. Chandler III" <dc...@bellatlantic.net> on 2000/10/19 14:35:55 UTC

A question on Macs

Hi,

Earlier I posted a message on finding the value of 'keepalive' (defined
in httpd.conf), for an individual request.  Since I did not get a
response I'm trying from a different angle.  I am lead developer for a
web application running on Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412
(Unix) mod_perl/1.21.

Does anyone know or can anyone rule out a bug in the way Apache
processes requests for Macs?  Several of our sites have had tremendous
problems with Macs accessing our webs.  I want to rule out Apache,
because turning off the keepalive directive seems to clear up some but
not all of our problems.  We're using:

BrowserMatchNoCase mac nokeepalive

I'm at a loss.  Any help, information, links and/or help in ruling out
Apache, would be greatly appreciated.

Dana C. Chandler III
e-Applications Developer

Re: A question on Macs

Posted by "Dana C. Chandler III" <dc...@bellatlantic.net>.
Hi John,

The MAC OS's range from 8.1 - 8.6.  The main problem before we turned
keepalive off was that the applications took much longer to load than
the PC, in many cases we're talking minutes not seconds.  And then
depending on the Browser there are numerous other problems.

For instance, we use onMouseDown handlers to simulate the pressing of a
button using images.  For the MAC on Netscape Communicator/Navigator
4.xx, for each of these "buttons" to work, it needs to be 'pre clicked'
before its action is performed.  I think the onMouseDown image needs to
loaded before the button will work correctly.  

In I.E. 5.0 (2022), it seems like our Javascript files are not being
loaded fully.  We get a lot of 'Foo is not an object' type errors.  It
makes I.E. unusable.  Sometimes it just returns a blank screen.

A couple of the application use Object Oriented Javascript in hidden
frames, a convenient way to store data on the client.  Because of this,
there is a price to pay when one of these applications first loads. 
Part of the problem for both applications is when the 'state' of the
application is does not change correctly causing a myriad of other
problems. 

When the user selects something, in this case a radio button, to change
the behavior of the application, either the underlying object is changed
and the display is incorrect, or vice versa.  So if you've removed the
checkboxes off of a page, as a result of the user selecting the entire
search results, the application still thinks there are checkboxes and it
causes what amounts to a fatal error and the need to reload the
application.  Imagine if this happens in the middle of a huge
transaction.

Because of the type of issues, I used to think that it was the
JavaScript(alone) causing the problems, but then there are at least two
sites that rely heavily on Apache and sessions to store data, using very
little and for one no JavaScript, that are having problems also. 
Limited to the MAC.

I'm sorry I'm not allowed to give access to the applications.  They're
owned but our client, and secured, therefore I can't grant access to the
applications or code.  Sorry.

Although both types of sites are password protected only the HTTPS webs
seem to have abundant issues. I can't see any reason for an application
to act differently under HTTPS, but change the web to HTTP and the
applications work much better!? 

I hopes this provides enough additional information.  My hands are tied
as far as how much information I can divulge, but I will try to answer
more questions to help determine the cause.  Apache is only suspicious
to me because turning off keepalive makes such a vast improvement.

Thanks for your help,

Dana C. Chandler III
e-Applications Developer


W John Burns wrote:
> 
> What version of the OS do they use ? I've a Mac (several versions of 7.x,
> no reason to use 8.x or 9.x), and could peek at your site if you provided a
> url...
> Also, are you sure it is the Mac OS that's the key variable ? Could it be
> browser (like using an old AOL browser, and getting stranded with HTML
> redirects, etc?
> 
> Also, is this a CGI-style form application? Is the server issuing HTTP
> headers that reflect form-urlencoded
> as the correct MIME type? What happens when it doesn't work? Do people get
> prompts to download?
> 
> John Burns
> Web Developer
> NY, NY
> 
> "Dana C. Chandler III" wrote:
> 
> > Hi,
> >
> > Earlier I posted a message on finding the value of 'keepalive' (defined
> > in httpd.conf), for an individual request.  Since I did not get a
> > response I'm trying from a different angle.  I am lead developer for a
> > web application running on Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412
> > (Unix) mod_perl/1.21.
> >
> > Does anyone know or can anyone rule out a bug in the way Apache
> > processes requests for Macs?  Several of our sites have had tremendous
> > problems with Macs accessing our webs.  I want to rule out Apache,
> > because turning off the keepalive directive seems to clear up some but
> > not all of our problems.  We're using:
> >
> > BrowserMatchNoCase mac nokeepalive
> >
> > I'm at a loss.  Any help, information, links and/or help in ruling out
> > Apache, would be greatly appreciated.
> >
> > Dana C. Chandler III
> > e-Applications Developer