re: http://httpd.apache.org/docs/2.2/howto/auth.html#possibleproblems
I just wanted to point the following:
Because of the way that Basic authentication is specified, your
username and password must be verified every time you request a
document from the server. This is even if you're reloading the same
page, and for every image on the page
It's a good thought but this documentation points to a performance
issue. What I am detailing is better described as broken functionality
than a performance issue.
So I think it is more the matter of how the particular browser handles
this and I would say FF and IE have different ways. Have you tried the
.htaccess approach with Opera, Chrome and Safari?
I haven't. As of yet, I haven't worked to fix the issue as much as
confirm the issue exists. My posting today shows over a year of
anecdotal evidence combined to create a report on a now reproducible
problem on multiple servers.
As we are starting to get cases where it works and doesn't work, (IE vs
Firefox and .htaccess vs <directory>), once I feel comfortable it's a
bug, I'll open a bug and support how I can fixing the bug.
Also the way you had originally set your protection makes it logical
that it will be applied to EVERY item in the directory right? So when
you load the page with 10 photos lets say, you get prompt for password
for each of them. Where is with the Directory tag approach you are
prompt for credentials only when you access the directory.
My understanding doesn't agree. Isn't the browser STILL negotiating a
username/password for every resource in that directory? However, the
switch from .htaccess to httpd.conf has changed something in the
behavior that was triggering the bug in my tests so perhaps you are correct.
You might also check the headers that the browsers send and see the
difference, at least in FF there is http headers plugin for that not
sure for IE though.
Sadly, I know how to manually check httpd headers and I use Chris
Pederick's amazing WebDev toolbar in FF. Beyond that, haven't got a
clue how to check in IE, though, and it would be off to google likely
using wireshark or something else that deviates from my core expertise.
Regards,
KAM
