On 10/06/2011, at 2:12 PM, Dave Kok wrote: > I very much like the header type as a generic feature but would suggest not > using it for HTTP authorization. As for user-agents to support it through > forms have to use special processing anyways. So I would suggest simply > declaring it on the form element itself as an attribute. When using > XMLHttpRequest one already has the ability to supply credentials with the > open > function. So when using a input elements without a form element there is no > need for an authorization feature. Also I would suggest that the attribute > does not have a value or that it is at least optional and when supplied is > only a hint to the user-agent.
I most definitely concur the usefulness of header fields :) The problem with authentication is it's pre-existing complexity and getting existing technologies to converge in a unified way. The attraction to this is that with the base extensions to forms it seems like the ability to declare authentication is only a short step away, and it's complexity provides a thorough use case for identifying the necessary specification edge cases. > Ultimately a user-agent must use whatever > method required by the server not the method defined by the author. A user- > agent can transparently find out which method to use with a HEAD request. Or > if > transport layer security is used simply guess one and see if it works and try > again if it doesn't. I'm not sure i agree. The server has served up the page so ultimately it is in control. If the author specifies something which the server can not handle, that's just an authoring bug is it not? I also don't think an agent should be making any guesses...this would definitely seem to violate the authority to define the modus operandi. > > Also binding the username and password input fields to the authorization > header > should properly not be done by reserving names in the name attribute of the > input field. I would suggest using a special purpose attribute like > authorization to declare their binding. Otherwise authors have to cope with > reserved names which is properly unacceptable backwards-compatible wise. > > <form method="get" action="/resource" authorize> > > <!-- use custom http header--> > <input type="header" name="Language" value="en_US"> > > <input type="text" authorization="username"> > > <input type="password" authorization="password"> > > <input type="submit" value="load"> > > </form> > > -- > Dave Kok > But, in reference to backwards compatibility, the authorization must be explicitly declared so this wouldn't be applied universally. I'm more thinking of a way to initiate the http authentication in html instead of as a browser popup. This allows for the author to define the user experience in the same way they do for cookie-based authentication which people have come to expect and trust. I was thinking the authentication would not be applied to all forms, but just as a replacement for the login form. After successful login the UA would continue to apply the Authorization headers to each subsequent request, until shutdown or logout. thanks, cameron jones > Op vrijdag 10 juni 2011 14:25:07 schreef u: >> i'd like to reference a proposal i put forward in relation to expanding the >> functionality of forms which displays how http authentication could be >> implemented declaratively by html authors: >> >> http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html >> >> thanks, >> cameron jones
