On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen <[email protected]> wrote: >> I had a discussion with Hallvord on IRC about the exact semantics we >> want for HTTP authentication in the context of CORS (and in particular >> for XMLHttpRequest, though it would also affect e.g. <img >> crossorigin>). > > So me and Anne have been going a bit back and forth on IRC, we agree on some > stuff and disagree on other points - and we fundamentally agree that some > implementor review and input would be valuable to really settle a conclusion > on how this murky little intersection of specs should work.. > > So the basic issue is HTTP authentication (cached and/or supplied by JS) with > XHR, and its interaction with CORS and other stuff like the anonymous flag > and withCredentials. > >> Username/password can be passed via open() or the URL. In that case we >> first check if the server challenges us (do a request without > >> Authorization that results in a response with status 401). > > > So far I agree :) > > >> For CORS, we'd return to the caller right there. > > Here I don't agree anymore. If I want to retrieve a HTTP auth-protected > resource with XHR from a CORS-enabled server, the natural thing to do seems > to try to pass in the user name and password in the XHR open() call. If the > script author supplied user/pass and the server says 401 on a request without > Authorization: surely the natural next step is to re-try with Authorization:?
If the caller to the XHR.open() call provided a username and password, then shouldn't the implementation send that information in the *first* request rather than waiting for a 401? Well.. first request after having done a preflight which checks that the server is ok with an Authorization header being specified? / Jonas
