Hi Hector, The trouble you are experiencing is that chromium does not implement "pre-emptive authorization". Note that pre-emptive authorization is an optimization, and not stricly required by RFC 2617.
Basic/Digest authorization are request based schemes, which follow a request-challenge-retry format: 1. Browser makes a request for resource X 2. Server receives the request, but chooses to disallow it because there was no (valid) Authorization header. Server returns a 401 along with a challenge (WWW-Authenticate) 3. The browser sees that the request hit a snag, and gets a username password for the realm (either by prompting user, or pulling from auth cache). 4. The browser resends the request, this time attaching the credentials in the "Authorization" header. 5. This time the server is happy, so it returns the resource asked for (200). What pre-emptive authorization does, is in step (2) it would have gone ahead and attached the Authorization header for that protection space (this is just a guess, since it can't know ahead of time if the resource really does require authentication. The heuristic for protection spaces is defined in RFC 2617, and is essentially the containing directory where a challenge was received from). With this in mind, we can understand why chromium would not work on your site, due to this step: > http://domain --> redirection to http://domain/public/default.htm Semantically the request to http://domain should be returning a 401, not a 301 -- as it is trying to enforce authorization on that resource. Since chromium will not pre-emptively send the authorization for inferred protection space, it will keep entering that loop. To break out of the loop, and support clients which don't implement pre-auth, the solution is to: on unauthorized access to "/", return a 401 (unauthorized) -- include the login page in the body of the response This will look the same as before, with the exception that the url in the browser will read "/" for the login page, instead of /public/default.html Chromium is re-implementing its http network stack, and one goal is to support pre-emptive authorization for Basic (to cut down round trips). Support for Digest is likely, but a little sketchier, since the digest auth model is broken under pipelining (next nonce is controlled by previous server responses (Authorization-Info). I recommend first working around the problem on the server side, as the fix should be simple, and strictly speaking more correct. We hope to support this in chrome in the future. cheers. On Mon, Sep 22, 2008 at 3:02 PM, Hector <[EMAIL PROTECTED]> wrote: > > On Sep 22, 9:44 am, "Marc-Antoine Ruel" <[EMAIL PROTECTED]> wrote: > >> I can't confirm your analysis, but I just want to give you some background >> info; >> > I can't explain why you can't confirm. I think I provided enough info > and repeatability information, here and in the bug list, including a > http://beta.winserver.com test site. I can provide at least few > hundred more web site if I knew which ones had HTTP BASIC/DIGEST > enabled off hand. > > Also, googling the proper keywords you will find there other were > others encountering the problem. In fact, this one was very recent: > > http://www.gossamer-threads.com/lists/python/bugs/680623 > >> We are departing from WinHTTP. > > Ironically I was going to propose to replace the winhttp interface. > But that isn't the problem because Chrome takes control of redirection > (incorrectly) which is the root of the RFC 2617 "going against the > spec" A.K.A "violation" in Chrome (see below). So replacing the http > stack is not going to solve this if it does not address the > redirection logic. > >> New authentication digests will be implemented in the new stack. > > Although I can understand why Chrome wanted to use WinHTTP for these > features, keep in mind, it has really nothing to do with basic/digest > per se, It is the redirection logic that is flawed. > > You might want to take a look at TrollTech's QTWebKit implementation > of WebKit with its QtAuthenticator and Networking/caching logic. > > What Chrome needs here is to couple the following design points during > a redirection: > > By default and per RFC 2617 recommendations: > > - Passing Authorization header to the same domain relocation (not > cross domains). > > For security enhancements: > > - Utilize a "short time window" difference between the redirection > and original referer, > - Make sure referer is authorized before authorizing the > redirection. > >> This will take some time. > > I don't see why it has to take a long time to address the more > immediate issue of fixing the redirection. The WinHTTP stack or > rolling your own, isn't going to solve it unless it has the same > redirection solution. > > The solution for now is to add a HttpKeyByDomain() function lookup. > The current lookup HttpKey() is by domain/realm. > > Once you have the HttpKeyByDomain(), then its an easy solution. > > -- > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
