XHR bugfix 21013

[hallvors]

Proposed fix for https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013

(And next time I'll remember to do the git squashy things before pushing..promise)

[annevk]

I think we should fix this by using Fetch.

[hallvors]

Sure, add it to Fetch if you wish to.. in that case perhaps add a note saying sites can opt-in to HTTP auth by sending Access-Control-Allow-Header: Authorization to XHR? The modularization of these specs (by which I mean XHR, CORS and Fetch) can make it a bit hard to figure out how it all fits together.

[annevk]

Suggested places where that would go? Maybe file a bug on Fetch?

[hallvors]

Anne, I'm getting a bit confused here ;). You recently said [1] CORS explicitly decided not to support HTTP Auth - and now you tell me to report a bug on Fetch for supporting "Access-Control-Allow-Header: Authorization" which basically enables HTTP Auth. So do you plan to add it or not? I'm happy to file a bug, of course.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15418#c22

[annevk]

There is a difference between setting Authorization yourself as an "author header" and having the user agent set it. The latter is not supported via CORS and I don't think there is much interest in adding that at the moment. Clarifying how the former works is something we could be doing. If you meant supporting the latter rather than clarifying the former I do think we should not be doing this, though you'd still be welcome to file a bug and get browsers interested (and figure out the delta in Fetch as that increases the myriad of options even more).

[hallvors]

So using the API the obvious way - open(... user, pass) - doesn't give the expected results if it's a CORS request, doing something slightly different but less obvious gives you the same functionality. IMO the difference is theoretical - you end up with the same functionality, just introduce a gotcha where authors who set user and pass in XHR.open() will be disappointed because things don't work, or ship buggy code because they didn't test the CORS scenario. That seems author-unfriendly and inconsistent to me.

But well, if you want more weird coding gotchas in the web platform I guess editing specs gives you the power to add them - and adding new gotchas is entirely consistent with the state of the platform so far...

[annevk]

If it was as simple as you put it, we'd just support it of course. However it is not.

[hallvors]

IANAI - not an implementer. It seems like just re-using existing HTTP auth logic with an extra initial CORS check should work, though - like https://www.w3.org/Bugs/Public/show_bug.cgi?id=15418#c17 suggests. However, I accept that it will complicate the spec and that the payoff may appear small. I still think exposing authors to less inconsistencies is worthwhile - but you're the one doing the actual editing.

[annevk]

This is not about editing or cost to the editor. This is about cost in implementations vs actual adoption. I'm not convinced people use username/password in XMLHttpRequest a lot to begin with. Mostly people use cookie-based authentication. Given that, it does not seem worth the cost, even though it would be more consistent.