RE: Reauthentication Requested Revisited

From: Josh Cohen (joshco@microsoft.com)
Date: Mon, Feb 02 1998


Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D0994@red-86-msg.dns.microsoft.com>
From: Josh Cohen <joshco@microsoft.com>
To: "'koen@win.tue.nl'" <koen@win.tue.nl>
Cc: ietf-http-ext@w3.org
Date: Mon, 2 Feb 1998 13:57:36 -0800 
Subject: RE: Reauthentication Requested Revisited



-> -----Original Message-----
-> From: koen@win.tue.nl [mailto:koen@win.tue.nl]
-> Sent: Monday, January 26, 1998 9:55 AM
-> To: Josh Cohen
-> Cc: ietf-http-ext@w3.org
-> Subject: Re: Reauthentication Requested Revisited
-> 
-> 
-> Josh Cohen:
-> >
-> [....]
-> >Essentially this is a server to client request acknowledgement
-> >system.  
-> 
-> I find myself wondering why we need the extra headers you proposed.
-> Can't your needs for server to client request acknowledgement be
-> satisfied already by a system in which the server sends a 
-> html response
-> with an embedded script, which then contacts the server?
-> 
Yes, that works 90% of the time.  What this covers (and that didnt ) is:

1) Verify that the client acknowledged the "retry request"
2) works with POST.  Current when you repost POST data,
   clients show a dialog asking yes or no.  This ties back
   to the idempotent or safe issues.  In this case we want to
   declare that you may retry this request (post or not) without
   interrupting the user since the request has not been processed
   and the controller of the transaction ( the NSAPI/ISAPI/CGI) is
   requesting the retry..

-> I tend to agree with Scott that server to client request
-> acknowledgement has little to do with the original `reauthentication
-> requested' problem.
-> 
This provides a general mechanism for a "retry request" from the server
to the client along with a way to acknowledge receipt of the retry 
request.
 
-> Koen.
->