This is a discussion on Apache and Safari strange Digest Behavior within the Apache Web Server forums, part of the Web Server and Related Forums category; Hi, Setup: - Apache 2.2.4 on Windows 2000 - Safari 3.1 for Windows XP I'm new to Apache ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Hi,
Setup: - Apache 2.2.4 on Windows 2000 - Safari 3.1 for Windows XP I'm new to Apache so I am still learning. I prepared it so use AuthType Digest using the example provided in the docs but for entire site, not just a private folder: <Location /> AuthType Digest AuthName "SSI Research" AuthDigestDomain / AuthDigestProvider file AuthUserFile /auth/.digest_pw Require valid-user </Location> Under Firefox 2.0, Internet Explorer 6.0 it is working as expected. Under Safari 3.1 for Windows, it APPEARS to work until you look at the access.log logs and what I am seeing after the login is a DOUBLE REQUEST for each private resource. In other words, when a private request is made, Safari will first send it as an unauthorized request by not sending the Authorization header. Apache sees this and issues a 401 with a new WWW-Authenticate: response header and Safari will resent the quest with the authorization header. So appearance way, it all looks ok, except for this double request behavior. Is this normal DIGEST behavior? I don't think so. Its a problem when you are in a public page which you might initiate the login but requesting a private resource which would direct to the private home page. However under Safari, it sees the redirection and makes the request in non-authorized mode, which the web server sees and redisplays the PUBLIC home page instead again. For example, using a C: client/user, S: server notation: 1 C: http://domain.com << user visits site 2 S: server requires authentication and redirects to: /public/default.htm with there is a login "/LOGIN" button 3 C: /LOGIN is issued 4 S: Server sees /LOGIN as a private alias resource request and issues a 401 with WWW-AUTHENTICATE digest response header. It will also output cancelation html code if the user clicks cancel. 5 C: Safari sees the DIGEST challenge and prompts the user to login. The original /LOGIN request is reissued with the authorization header. 6 S: Server sees /LOGIN as a private alias resource request and also sees the authorization header. It is validated and it now wants to redirect to /DEFAULT.HTM. 7 C: Sarafi sees the redirection but it will request it without the DIGEST authorization header. 8 S: Servers sees the /LOGIN without any authorization header and repeat step 4 again. All other browsers will always send the authorization header with all requests, including redirection responses by the server. Whats the skinny here? Thanks! --- |