On 10/06/2011, at 4:23 PM, Dave Kok wrote: >>> 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. > This is assuming the form's action targets the same domain. I see no reason > why it should. On top of that authentication is a protocol thing so it's best > to leave most of the details at that level and not expose those to a higher > level. As rational you can look at the XMLHttpRequest.open function. It only > allows an author to supply a username and password and not what method to use > or any additional parameters. >
But, it also allows for manually setting the Authorization header which takes precedence over the method arguments. What do you mean by "it's a protocol thing"? The idea is to provide a UI to enable a human to interact with the protocol, this must be present in some way, either by the UA as at present, or through forms as suggested. >> >>> 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. > Yes but browsers not supporting the new feature would simply post the > username > and password without using any authentication method. However those fields > are > suppressed if no the name attribute isn't used. Thus using a new attribute > has > my preference. Also to allow building a work around for non-conforming > browser > which will exists for many years to come even is this feature finds it way > into > the spec. But, the authorization would only be applied when instructed through the application of the specific header. This means that there can't be any conflict with existing pages\forms as form headers don't currently exist. There is a benefit to binding the parameters from input names - for old browsers which don't support the new headers they will at least send a request to the server which can be setup to handle legacy requests as form encoding, probably falling back to setting up a cookie session. As you noted, if new attributes are introduced, no data will be sent. The benefit i see in allowing binding from input name is that any of the input types can be used to collect the necessary data to form the request. For realms, this could be a multi-select. sorry, i didn't mean to pollute the thread...it seemed related to the issue but is probably going on a tangent. thanks, cameron jones
