W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #78: Relationship between 401, Authorization and WWW-Authenticate

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 27 Jul 2011 11:56:51 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <8dbb84a5569f3d0a6c1fc22907ae74ee@treenet.co.nz>
 On Tue, 26 Jul 2011 16:18:04 -0400, Mark Nottingham wrote:
> On 26/07/2011, at 4:11 PM, Adrien de Croy wrote:
>> apologies, but I'm still not convinced overloading a new function 
>> onto WWW-Authenticate is the best way to advertise the availability of 
>> optional authentication.
>> It creates an immediate dilemma for any UA that receives such a 
>> message.
>> What are the options for the UA, and how will they affect user 
>> experience?
>> If the UA always elects to proceed to auth, then it's the same as 
>> sending back a 401
>> if the UA tries to give the choice to the user, that's (IMO) asking 
>> for pain
>> otherwise the UA can ignore it, and it's just more bloat.

 The server also does not know which of those two behaviours the client 
 UA will choose.

 This opens the door for the form-base auth currently being proposed in 
 other WG. Websites placing login forms on, for example, their front 
 page. User agents with credentials available already can login silently. 
 Those without can choose to happily display the non-authed page without 
 annoying the user overly much. If the user does fill out the form 
 credentials become available and the page view can change without 
 caching problems.

 With some extra UA support this is all possible now. Just requires a 
 few things outside the HTTP spec to happen. Which means when this is 
 implemented compatibility will be a problem.

>> Also I just see it breaking a whole heap of agents who switch 
>> behaviour on the presence of that header (rather than the status).
>> Finally, we see UAs starting auth without this header in the first 
>> place.  So does this really need advertising anyway?
>> If this is to be new behaviour, shouldn't we use a new header or 
>> status? That way we can keep it out of the way.
> All we're doing is leaving the door open for the possibility in the
> future, explicitly; we're not requiring anything, and a future effort
> can figure out what the best thing to do is.

 +1 to foresight.

Received on Tuesday, 26 July 2011 23:57:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC