Re: [users@httpd] Browser differences

2017-05-05 Thread Robert Inder
Thanks for the prompt response.

On 3 May 2017 at 13:55, Ramsey, Robert L <robert-ram...@uiowa.edu> wrote:

> This is just my non-apache two cents.
>

​Yes, I realise ​it might not be an Apache problem.
But it did start appearing around the time yum gave us a new version of
Apache...

> -  Is your js loaded after all of the libraries?  Are you sure?
>
​Yes.  ​ I thought it was, and I just thecked.
Following a bunch of CSS files, we have
 JQUery,
 Several other third party libraries, including OpenLayers and Backbone
 JQuery Mobile.
 Our main (1.7MByte minified) JS file
 A 500kByte minified compiled templates file.
 A couple of tiny JS (configuration) files​
 A40KByte "top level" JS file.

And THIS, last, file is the one that Chrome says times out!

However, I will try re-ordering things, and see if that makes a
difference...

> -  Is your js file one huge file or many little ones?  It sounds
> like one big file.
>
​Mostly ​one big one.  But that isn't the file that times out!
​However, I'll try splitting it, too...​

​And it is straight JS.​


>
> You’ve probably already looked at those, but sometimes it helps to have
> another person chime in.
>

​  | ​
A js/chrome list might be more appropriate too.

​Maybe.  I had two vague ideas, and I wanted to see whether anyone else
would suggest them:
 * The problem is related to a limit on the number of (simultaneous)
fetches from a single client, and the new version of Apache has changed
that limit, or
 * Chrome is picking up an ISP's a proxy configuration that FFox is
not, and it is the ISP's proxy that is/was causing the problem.

​Robert.​

​​

>
>
>
>
> *From:* robertin...@gmail.com [mailto:robertin...@gmail.com] *On Behalf
> Of *Robert Inder
> *Sent:* Wednesday, May 3, 2017 4:34 AM
> *To:* users@httpd.apache.org
> *Subject:* [users@httpd] Browser differences
>
>
>
> We have developed a complex javascript application
>
> There are "a few megabytes" of our own code, plus OpenLayers map handling
> and jQuery.
>
>
>
> We're serving it through Apache 2.2.15-59, which arrived on CentOS 6.9 in
> mid April.
> And everything works well and reliably for us.
>
>
>
> But for the last couple of weeks, our client has been experiencing
> problems starting the application.
>
> The Javascript console reports that some Javascript files are not loading
> because "Connection Timed Out" on one of the JS files.
>
> Apache is not logging any errors.
>
>
> The obvious explanation would be in terms of network connection between
> him and the hosting company.
> But his connection is actually faster than ours
> AND he only has problems when he uses Google Chrome: Firefox is fine.
>
>
> So I'm struggling to think what this can be.  Any suggestions?
>
>
> Our client started having problems at ABOUT the time that yum installed
> 2.2.15-59.
>
> Has something changed?
>
>
>
> Robert
>
>
> --
>
> Robert Inder,0131 229 1052 / 07808
> 492 213 <07808%20492213>
> Interactive Information Ltd,   3, Lauriston Gardens, Edinburgh EH3 9HH
> Registered in Scotland, Company no. SC 150689
>Interactions speak louder than
> words
>



-- 
Robert Inder,0131 229 1052 / 07808 492
213 <07808%20492213>
Interactive Information Ltd,   3, Lauriston Gardens, Edinburgh EH3 9HH
Registered in Scotland, Company no. SC 150689
   Interactions speak louder than
words


[users@httpd] Browser differences

2017-05-03 Thread Robert Inder
We have developed a complex javascript application
There are "a few megabytes" of our own code, plus OpenLayers map handling
and jQuery.

We're serving it through Apache 2.2.15-59, which arrived on CentOS 6.9 in
mid April.
And everything works well and reliably for us.

But for the last couple of weeks, our client has been experiencing problems
starting the application.
The Javascript console reports that some Javascript files are not loading
because "Connection Timed Out" on one of the JS files.
Apache is not logging any errors.

The obvious explanation would be in terms of network connection between him
and the hosting company.
But his connection is actually faster than ours
AND he only has problems when he uses Google Chrome: Firefox is fine.

So I'm struggling to think what this can be.  Any suggestions?

Our client started having problems at ABOUT the time that yum installed
2.2.15-59.
Has something changed?

Robert

-- 
Robert Inder,0131 229 1052 / 07808 492
213
Interactive Information Ltd,   3, Lauriston Gardens, Edinburgh EH3 9HH
Registered in Scotland, Company no. SC 150689
   Interactions speak louder than
words


[users@httpd] Incorrect error logging

2014-07-04 Thread Robert Inder
I've spent a couple hours tracking down the cause unexpected and (I believe)
spurious log messages.

If I'm right that the messages ARE spurious, I'll file a bug report.  But before
I do that, can anyone see something I'm doing wrong?

Here is the relevant section of my httpd configuration file

   VirtualHost *:80
ServerName internal.mydomain

DocumentRoot /var/www/internal/html
Directory /var/www/internal/html
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
/Directory

ScriptAlias /cgi-bin/ /var/www/internal/cgi-bin/
Directory /var/www/internal/cgi-bin
AuthType Basic
AuthName Internal
Options FollowSymLinks
AuthUserFile /var/www/internal/access/htpasswd
AuthGroupFile /var/www/internal/access/htgroups
Require group internaluser
/Directory


This mostly does what I would expect: attempts to access
  http://internal.mydomain/cgi-bin/foo
are met with a password prompt.  And if the right password is
given, the scrips
  /var/www/internal/cgi-bin/foo
is invoked.

The same thing happens for
  http://internal.mydomain/cgi-bin/foo/arguments-here
Everything works, and no errors are logged.

EXCEPT when access to the document root is protected by a .htaccess
file that refers to a AuthUserFile that requires different passwords.

When that is the case, everything still works BUT the error log for
the virtual hosts gets a line of the form...
   user someuser: authentication failure for /arguments-here:
Password Mismatch

The error line only appears when the requested URL extends beyond the
script name (i.e. when there are arguments-here).  The script is
invoked as it should be, and sees arguments-here, but IN ADDITION to
the intended processing, something attempts to authenticate access to
arguments-here in the document tree.  Nothing appears in the access
log (apart from the successful access to the script), only the error log.

If the password for the cgi-bin directory works for the document tree,
no error is logged.  Which suggests that the spurious/unintended
access may be succeeding...

Have I misunderstood something?  Am I doing something wrong?

Or is there a bug?

Robert.

-- 
Robert Inder,0131 229 1052 / 07808 492 213
Interactive Information Ltd,   3, Lauriston Gardens, Edinburgh EH3 9HH
Registered in Scotland, Company no. SC 150689
   Interactions speak louder than words

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org