Re: REAUTHENTICATION REQUIRED

>>>>> "RTF" == Roy T Fielding <fielding@kiwi.ics.uci.edu> writes:

RTF> As a general rule, do not use a status code to indicate something which
RTF> is not status -- doing so breaks orthogonal design issues.
RTF> If the same functionality can be accomplished with a header field
RTF> (new or existing), then do that instead.

  You make an excellent point.  We could add this to the
  Authentication-Info header as follows:

       3.2.3 The Authentication-Info Header

       When authentication succeeds, the server may optionally provide
       an Authentication-Info header indicating that the server wants
       to communicate some information regarding the successful
       authentication.

            AuthenticationInfo = "Authentication-Info" ":"
                                ( discard | 1#( digest | nextnonce ) )

            discard            = "discard"
            nextnonce          = "nextnonce" "=" nonce-value
            digest             = "digest" "=" entity-digest

       If the 'discard' indication is sent in a response, the client
       MUST discard any user credentials which were used to
       authenticate the corresponding request.  The client MAY retain
       the realm value associated with the request so that it can
       prompt the user for new credentials before transmitting a
       subsequent request (note that this only saves a round trip for
       authentication schemes which do not utilize a nonce from the
       server).

       [... and a corresponding addition to the description of Proxy
        authentication]

  Note that this makes the Authentication-Info header field applicable
  to Basic authentication as well as Digest (but only the 'discard'
  value would be meaningfull in Basic).

  As Roy points out, this has the advantage that it can be combined
  with any status value.  I believe that it is backward compatible IFF
  deployed client parsers for the Authentication-Info header have been
  written such that they can tolerate and ignore an unexpected value
  (the robustness principle would suggest that they should have been).
  Since I am aware of only a couple of clients that have implemented
  Digest this is easy to check.  If this turns out to be the case then
  the backward compatibility is no worse than when using status
  values; that is, it will be ignored by existing implementations,
  leaving credentials lying around, which is the only alternative
  today anyway.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Tuesday, 25 November 1997 06:55:18 UTC