RE: REAUTHENTICATION REQUIRED

On Mon, 24 Nov 1997, Paul Leach wrote:

> Two comments:
> 
> Certain popular web servers have a builtin "session" mechanism, so that what
> the server needs to do has already been implemented.

True, but the session mechanism I am intimately familiar with on one
popular web server doesn't apply for all cases where basic authentication
can be used. To activate that session management would require the
addition of additional logic.  Furthermore, there is quite a bit of
server overhead associated with session management AND there is 
some degree of end user and developer resistance to use of cookies and
sessions when there isn't an obvious need.


> The guys who want this want to trust the browser as little as possible. A
> browser that doesn't understand the timeout directive would ignore it. A
> browser that doesn't understand "4xx reauth required" will consider it a
> fatal error. They like that default.

As far as I'm concerned, that still represents a degree of trust.

As far as 'the guys' who want this is concerned, I believe you are
describing a specific set of guys. I can assure you that there would
also be quite a bit of interest in the timeout and 2xx logoff additions
I've suggested based on several months of following the 2500 subscriber
mailing list associated with a common server.

In any case, I'm not objecting to the original "4xx reauth required"
proposal except that I believe it is quite incomplete in terms of the
needs/desires of the HTTP based application community.

> 
> 
> > ----------
> > From: 	David W. Morris[SMTP:dwm@xpasc.com]
> > Sent: 	Monday, November 24, 1997 10:34 AM
> > To: 	Paul Leach
> > Cc: 	'http-wg'; 'Jim Gettys'; 'http-wg'
> > Subject: 	RE: REAUTHENTICATION REQUIRED
> > 
> > 
> > 
> > On Mon, 24 Nov 1997, Paul Leach wrote:
> > 
> > > How about cookies? I've heard they are useful for tracking state... :-)
> > > 
> > > As I understand it:  cookie has a magic number in it. Magic number is
> > index
> > > into a table at the server. Table has timeout information.
> > 
> > Cookies are one way to maintain state, munged URLs are another. Both
> > are more complex than needed if the client is simply given a timeout.
> > 
> > Servers which want more precision or actually require a stateful
> > interaction will of course maintain their own timeouts. But for basic
> > access to a secured set of WEB resources, having the client provide
> > the timing keeps everything simpler.
> > 
> > 
>

Received on Monday, 24 November 1997 11:15:24 UTC