Hi,
below some more feedback about the initial proposal.
This addresses the "forms served with status 200 status are bad for
non-interactive/non-HTML-based clients" (partly). That is good.
It does not try to address the "standard HTTP authentication doesn't
work well in HTML-based UAs", which we discussed in Mandelieu. That's
ok; it's useful to think about these as separate issues.
Ian Hickson wrote:
...
As can be seen in the feedback below, there is interest in improving the
So when you get to a page that expects you to be logged in, it return a
401 with:
WWW-Authenticate: HTML form="login"
...and there must be a <form> element with name="login", which represents
the form that must be submitted to log in.
...
For security reasons, I'd prefer that to be "the <form> element",
instead of "a <form> element" -- having multiple copies of the name in
the same document should be considered a fatal error.
We could also make HTTP login work better, but frankly I'm not convinced
there's much point. The form login cowpath is so commonly frequented that
not only has someone already gone and paved it but it has also been
tree-lined, has garbage collection scheduled for Tuesdays and Thursdays,
and will be electing a representative at the next general election.
Which doesn't mean that it's not a good idea to think about it
nevertheless, but let's just keep that in a separate discussion.
Yes, that's a simpler option. :-) (Provided that current browsers still
ask for authentication even when given a 200 OK.)
I don't think they do now, but it's something we can move towards.
I think asking for credentials when the status is 200 would be a bug.
...
BR, Julian
