- From: HTML Issue Tracking Issue Tracker <sysbot+tracker@w3.org>
- Date: Sat, 10 Nov 2007 13:07:32 +0000 (GMT)
- To: public-html@w3.org
ISSUE-13 (handling-http-401-status): Handling HTTP status 401 responses / User Agent Authentication Forms [HTML 5 spec] http://www.w3.org/html/wg/tracker/issues/ Raised by: Julian Reschke On product: HTML 5 spec Handling of HTTP 401 (Unauthorized) responses HTTP authentication is in little use in the public web. Most web sites use an HTML form (returned with status 200) and Cookies instead. This causes quite some problems when the same HTTP resource is accessed both by interactive user agents (browsers) and other clients (web crawlers, download tools, non-HTML based applications using HTTP as application protocol, such as AtomPub or WebDAV). So, authentication should be decoupled from HTML forms so it can be used by non-HTML clients as well. There are multiple reasons that led to the current situation: 1) The two authentication mechanisms defined in RFC2617 (basic and digest) aren't considered sufficient. This is a problem that whoever updates RFC2617 will have to consider (for now, likely an IETF activity). 2) Browsers do not display the text/html response body of a HTTP 401 response, instead, they just pop up a modal authentication dialog (until "cancel" is pressed). 3) Servers do not send a meaningful response body with the 401 status as browsers do not display it anyway. HTML5 could help with issues 2) and 3) by defining a way for servers to indicate that the text/html content returned with the 401 status should be displayed to the user, allowing to use an embedded form to enter credentials, which then would be used by the browser for proper HTTP authentication. There's an old W3C note discussing this: <http://www.w3.org/TR/1999/NOTE-authentform-19990203>. Related discussion in the Mozilla Bugzilla: <https://bugzilla.mozilla.org/show_bug.cgi?id=271383>
Received on Saturday, 10 November 2007 13:08:01 UTC