Thanks for taking the time to read through it.
Cool, there are some great UI ideas there. I particularly like the
examples that eliminate favicons. ;-)
I would think that moving toward HTTP authentication schemes, such as
digest, would make it much easier to automate a good identity manager.
Would you agree?
I appologize if this comes out wrong. I do realize that Firefox had
started implementing this some time back, and I didn't intend to call
out Firefox specifically. Firefox clearly has done better than other
browsers with newer XHR impacts. I'll update the wording on that.
> Your proposal to reinterpret 401 headers is clever and if the IETF HTTP
> working group agreed with this interpretation Firefox would follow. The
> IETF is currently working on (finishing up) an HTTP revision to clarify
> things and you should bring this up with them. In practice, though, I
> can't see sites adopting it because of the mass of old browsers who will
> behave badly for some time. Your new header proposal would be easier to
> get adopted since old browsers are no worse off by ignoring it.
I do see your point with adoption. I think a change in newer browsers
to 401s won't badly break existing applications using HTTP auth, but
new applications won't adopt it until the old browser behavior goes
Fortunately, the biggest backward compatibility problem is mostly with
IE. I think most users of other browsers upgrade pretty quickly to
later versions. If Microsoft could be convinced to make this change
and push out a service pack for IE7 & IE8 (yes, I know this is a
stretch), then perhaps developers would be in the clear in 1-2 years.
I have tried to contact the MSRC and submit a newsgroups bug report
against IE8 with this information, but I really don't know what the
best way is to get a hold of standards-oriented IE developers. Do you
know of a good way to contact them?
Another thought I had on performing logouts, which is not presented in
the paper, is that if the XMLHttpRequest W3C standard is finalized and
fully adopted by browsers as is, then one might be able to use
that cute race condition in Firefox currently. (Recall the reference
in my paper how one can initiate an asynchronous call with bogus
credentials, then cancel it before the user is prompted.) If users
aren't prompted at all when the open() method is provided credentials,
then a log out page could just seed it with bogus ones on most (all?)
browsers. This could act as a stop-gap measure to provide log out in
the short term while 401 behavior is changed.
> You must be the Tim who started the "Past proposals for HTTP Auth
> Logout" thread and if so you're already involved in the right place for
Heh, you did your homework. Yes, I did start that thread.
If you read through the discussion , you'll see that some folks
champion the idea of an explicit log out, while others say
"there's nothing stopping browsers from doing this already"
I proposed the idea of using the 401 processing change and no one
seemed to have a problem with it, but perhaps the thread was dying at
Let me also highlight a sentence from RFC 2616 related to the 401
"If the 401 response contains the same challenge as the prior
response, and the user agent has already attempted authentication at
least once, then the user SHOULD be presented the entity that was
given in the response, since that entity might include relevant
So I actually am thinking my interpretation is the pretty close. If a
user was already logged in and they receive a 401 response, then of
course they had "already attempted authentication" on that request.
So they "SHOULD be presented with the entity given in the response".
Entities of course include, in part, the entity-body. This sentence
also implies that if a user messes up the login once, they should stop
being prompted, but perhaps that doesn't make sense.
Would you be interested in helping me make the case to the HTTP
working group? I think many more IETF folks might get involved in the
discussion if a representative from a major browser kicked things off.
Of course this working group cannot make any real changes to HTTP,
they can only clarify things. But maybe more explicit "MAY" and/or
"SHOULD" language could make it clear what flexibility user agents
have in processing 401s.
Thanks for your feedback,