W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] New HTML5 Form type

From: Robin Aaberg Garen <robin.garen@gmail.com>
Date: Thu, 27 Oct 2011 10:45:23 +0200
Message-ID: <CAAbVo5FL9xmSA5dGkUqdd+w04U5=JBXta6RPCCJD0g_P853f7A@mail.gmail.com>
I very much encourage this idea.

I fret frequently when I see the unsupported features of the HTTP protocol
not being used because of missing support in browsers and servers. Like the
PUT and DELETE.  And this enchancement of the AUTH.

A more seamless integration of the HTTP AUTH to the client side of the HTTP
protocol as suggested in the letter in which I'm replying to would be great.
This is my humble oppinion as a young web-developer.

Best regards

Robin G. Aaberg
Last year student in Communication technology @ Bergen University College
Proud member of Communica.


On Sun, Oct 23, 2011 at 3:47 AM, Michael Herold
<herold at physik.fu-berlin.de>wrote:

> Hello,
>
> i want to discuss some thoughts on the html <form> element (see below).
> If somebody thinks this idea might be useful I would continue to check
> how a implementation of this feature would be possible and what the
> technical difficulties would be.
>
> I have no idea if there is a way to bring this to HTML5 or commit this
> in any other way to the W3C.
>
> Best wishes, Michael
>
>  **Suggestion**
> Add a new possible value "auth" to the HTML <form> //method// attribute.
> If input elements named username/password are present they are used to
> authenticate. Otherwise the first input element is used as username and
> the first input[type=password] element is used as password.
>
> It may be useful to interact with the http-status as the browser needs a
> //nonce// for digest auth.
>
> The aim would be to create custom login and logout dialogs without
> JavaScript.
>
>  **Thoughts regarding authentication**
> Today there are three common ways to authenticate using HTTP: GET,
> cookies, HTTP-Auth.
>
> **GET**
> Putting a session (+user) in the get.
> - copy+paste and visual access can steal login
> - have to depend on users ip to add a bit of security
> - supported by every browser
> - the website has to adjust every link for every user
> - the url gets unreadable
>
> **cookies**
> Putting a session (+user) in a cookie.
> - can be implemented with sufficient security
> - broken by standard (none standard SLD fix in every browser)
> - disabled or not supported by many clients for various reasons
> - leaves footsteps on hdd per definition
>
> **HTTP-Auth**
> Basic or Digest Access Auth
> - can be implemented with sufficient security
> - the "right" way to authenticate
> - the browser may give the user the full controle/overview over page
> logins
> - very simple to set up
>
>  **Thoughts regarding HTML**
> By now the HTML(5) <form> element only supports two different values for
> the method attribute, namely "get" and "post". As the abstract meaning
> of the method attribute -as far as i know- is not defined, one may
> suppose that this attribute defines the way how the form data are used
> for a HTTP request.
>
> If we take this definition, one may enhance the method element to other
> features of the HTTP protocol. These are some of the features that are
> used to shared data:
> - GET
> - POST
> - Auth
> - Cookies
> As cookies are working in the other direction, we may exclude them from
> our list for this purpose.
>
>
Received on Thursday, 27 October 2011 01:45:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC