W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 1995

Re: HTTP status code for "Password Expired"?

From: Rick Troth <TROTH@ua1vm.ua.edu>
Date: Wed, 10 May 95 23:35:34 CDT
Message-Id: <9505110452.AA02793@hplb.hpl.hp.com>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>, matthew noell <matt@caladan.sps.mot.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 10 May 1995 19:49:26 -0700 you said:
>> After reviewing the HTTP/1.0 draft I was unable to find in the status
>> codes section anything which I could use to report access authorization
>> has been denied because the password given has expired.
>
>There is not a separate status code for every possible error condition;

        It's worth considering.   Unique numeric codes with positional
tokens  (if needed)  map very nicely on the client end  with or without
an HTML processor.

        It's just a thought;  nothing worth starting a debate over.
(certianly not without changing the subject line)   I think unique
response codes (more unique than FTP's) would be a win.

>instead, there are codes for classes of problems and the content of the
>message is used to explain the exact reason.   ...

>and include an explanation in the message body.

        Which would be in the language of the server.   Language
negotiation might not have yet taken effect.   (what about a mal-formed
request?  what if it's output from a CGI script?)   Server could say
"403 PASSWORD",  where  "PASSWORD"  were a unique indicator as to
*why*  the request was denied.   But I'd prefer a different number for
"403 PASSWORD"  and  "403 PERMISSION"  or  "403 FORBIDDEN"  and leave
the positional parameters for other things.

> ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
>                                       <fielding@ics.uci.edu>
>                      <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

--
Rick Troth <troth@ua1vm.ua.edu>, Houston, Texas, USA
http://ua1vm.ua.edu/~troth/
Received on Wednesday, 10 May 1995 21:59:32 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:55 UTC