W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1999

What's the mechanism for adding new error codes?

From: Kevin J. Dyer <kdyer@draper.com>
Date: Thu, 09 Dec 1999 18:08:50 -0500
To: IETF HTTP WG <http-wg@hplb.hpl.hp.com>
Message-id: <>
When Mike Spreitzer <spreitze@parc.xerox.com> asked about
standardized authorization and authentication in HTTP something
rang a bell.  I've been part of a group to implement authentication
and authorization using either static or one-time passwords
depending on the remote location and or resource requested for
an in-house system.  We've had to overload return codes (4XX and
5XX), use convoluted HTML hacks, or create out of band
connections in order to achieve the simple challenge response
mechanisms that most of us are use to everyday when a
password has expired or a token needs resynchronized.

With the world moving more toward a browser as their desktop
for large scale collaboration efforts.  How do we as developers
and content providers let a user know that his or her password
has expired or that they are required to change their password
because their temporary password was just that
"TEMPORARY"?  You can make the providers / developers
write workarounds that use HTML / Java, but it's not fixing the
problem.  The solution seems to be we add or enhance the
error returns that are in the protocol to allow for greater

What is the mechanism that will allow someone or group
to add new error codes to the HTTP protocol?  Are the
individual W3O working groups like WWW security or
WEBDAV tasked with adding each of their own codes
and how do we referee the conflicts?

Some examples:

	4XX   Password Change Required

		Self explanatory.

	4XX   Next Passcode or Token

		For use with one-time password smart
		cards like Axent or SecurID

	4XX   Reauthentication required

		Arguably can use a 401, but this should allow
		for more information to be displayed in the
		pop-up / applet.

and I know there have been others that have bounced through this
list as well.

			Just a thought before we close up shop!

					Kevin Dyer
Kevin J. Dyer				     Draper Laboratory  MS 35
Email: <kdyer@draper.com>		     555 Tech. Sq.
Phone: 617-258-4962			     Cambridge, MA 02139
FAX: 617-258-2061
	    _/_/_/_/    _/          _/  _/  _/        _/     _/_/_/_/
	   _/      _/   _/_/     _/_/  _/  _/_/     _/   _/
	  _/       _/  _/ _/   _/ _/  _/  _/  _/   _/    _/_/_/
	 _/      _/   _/  _/ _/  _/  _/  _/    _/ _/            _/
	_/_/_/_/   _/    _/    _/  _/  _/        _/  _/_/_/_/
        Data Management & Information Navigation Systems
Received on Thursday, 9 December 1999 23:13:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:34 UTC