- From: Dave Kok <updates@davekok.net>
- Date: Fri, 10 Jun 2011 15:12:34 +0200
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. 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. 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 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
Received on Friday, 10 June 2011 06:12:34 UTC