Tried logging in using the username "chrisc" and the password "test" to the above test URL. Basic Authentication appears to fail and the user is prompted for login details again.
The authorization header we're sending is identical to the one sent in 4.x; except that the 'a' is not capitalized (it is in 4.x) per the 1.1 HTTP RFC. Assuming IIS isn't case sensitive WRT headers, it can only be one of two other differences: mozilla's "accept" header is sent as "*/*" rather than outlining various MIME types it can handle, and it is not sending the "connection" header. I suspect that IIS is choking on one of these latter issues (note: that both are legal). You might want to try turing connection keep-alive (caching) off on the IIS server. If that doesn't do it then the problem is most likely a bug in IIS (that we may need to work around) handling of authentication and accept header handling.
of course the user agent differs as well, but let's hope IIS isn't choking on that :/.
I've tried disabling connection keep-alive on a different server (can't play with the example one too much) It may well be an IIS thing, but the site uses an activex control for authentication from a database. Maybe the control is at fault (maybe not) the control can be donwloaded as an eval from http://www.flicks.com/flicks/authx.htm
ahhh. That control is most likely the problem. I doubt it can handle the new user agent, and/or the lowercase 'a'. I would be suprised if IIS was having this problem.
I'm contacting the control company.
I'm adding Kevin (w/ AuthentiX) to this bug. Kevin if you do not want to receive this traffic, click the bugzilla url, remove yourself from the "cc:" list and hit submit. AuthentiX is doing a case sensitive compare of the "authentication" header, thus it never authenticates.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 20814 ***
[bugday]marking verified. same bug indeed. and currently worksforme on my own webserver - although the chrisc site doesn't appear to like that user/pass combo anymore.
You need to log in before you can comment on or make changes to this bug.