Prototype line 775 seems to be culprit. If you are authenticated to a basic realm and then use XMLHttpRequest through Prototype - it results in a request to http://undefined:undefined@hostname which in turn prevents you from being able to complete the request. Some chat transcript from bdash below: 20:13 < bdash> the prototype code calls transport.open(this.options.method.toUpperCase(), this.url, this.options.asynchronous, this.options.username, this.options.password); 20:14 < bdash> this.options is an object consisting of some default fields, merged with the configuration you pass to Ajax.Request 20:14 < bdash> there is no username or password key, so this.options.username and this.options.password are both undefined 20:15 < bdash> our behaviour obviously differs from Firefox in the case of undefined, though the work-in-progress XMLHttpRequest specification says that no username and password should be indicated by 'null' Extent of browser testing as follows: IE Windows - Request completes ok FF Windows - Request completes ok FF OSX - Request completes ok SF/WK OSX - Request fails
RoR bug report here (and patch): http://dev.rubyonrails.org/ticket/6638
Thanks for the bug report!
Created attachment 11562 [details] proposed fix We also have issues with null parameters (and the draft XHR spec also does), but this change seems straightforward and simple enough to be made right away.
Hi Alexey, (In reply to comment #3) > Created an attachment (id=11562) [edit] > proposed fix > > We also have issues with null parameters (and the draft XHR spec also does), > but this change seems straightforward and simple enough to be made right away. Comparing with the RoR patch, there seems to be a difference. That one passes user and password string only if both are defined, your patch passes both when user is defined but password is undefined. I am not too familiar with XHR (yet), but I can imagine this would not make sense? Cheers, Rob.
The patch makes open(..., "login", undefined) work like open(..., "login"), which I think is correct. How the latter should work is an open issue still; quoting the current XHR editor's draft: ----------------------------- Issue: Need to look at the password argument. What syntax does it need to match. Can it be UTF-8 on transmission? When it's omitted, do UAs still use the user argument? IE doesn't. -----------------------------
(In reply to comment #4) > Hi Alexey, > > (In reply to comment #3) > > Created an attachment (id=11562) [edit] > > proposed fix > > > > We also have issues with null parameters (and the draft XHR spec also does), > > but this change seems straightforward and simple enough to be made right away. > > Comparing with the RoR patch, there seems to be a difference. That one passes > user and > password string only if both are defined, your patch passes both when user is > defined but > password is undefined. I am not too familiar with XHR (yet), but I can imagine > this would not make sense? ap explained that above scenario behaves like providing a user without a password, which still is an open issue for the specification. For that same reason there are no tests for this in basic-realm.html yet. With that in mind, I am going to r+ it. Cheers, Rob.
Comment on attachment 11562 [details] proposed fix r=me
Committed revision 17842.