A limitation of XHR is that it's not possible to control whether the browser's HTTP auth dialog is shown when invalid credentials are sent with the XHR request. This limits its usefulness in providing an alternative interface to the browser's dialog for HTTP auth. This issue has been discussed in the Mozilla community and alternatives suggested but so far not implemented, see: https://bugzilla.mozilla.org/show_bug.cgi?id=282547 https://bugzilla.mozilla.org/show_bug.cgi?id=221943 A simple solution would be for the open() method to accept a callback for handling an authentication failure. If open() was called without a reference to a callback function, or the callback function returned FALSE the HTTP auth dialog could be displayed.
Additionally, I think that our current implementation is inconsistent and/or broken (only shows the dialog for async requests, but doesn't seem to actually use the typed in credentials).
(In reply to comment #1) > Additionally, I think that our current implementation is inconsistent and/or > broken (only shows the dialog for async requests, This is bug 8342. > but doesn't seem to actually use the typed in credentials). Looks like an NSURLConnection bug, rdar://4581439. It is probably possible to work around it in WebKit (by removing credentials from the URL passed to Foundation and handling them manually) , but I'm not sure if it's worth it.
(In reply to Alexey Proskuryakov from comment #2) > (In reply to comment #1) > > Additionally, I think that our current implementation is inconsistent and/or > > broken (only shows the dialog for async requests, > > This is bug 8342. > > > but doesn't seem to actually use the typed in credentials). > > Looks like an NSURLConnection bug, rdar://4581439. It is probably possible > to work around it in WebKit (by removing credentials from the URL passed to > Foundation and handling them manually) , but I'm not sure if it's worth it. The NSURLConnection bug was fixed in OS X 10.5.3 (and newer)