On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen <hallvord@opera.com> 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? / JonasReceived on Monday, 6 May 2013 17:55:45 UTC
This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC