On Wed, 2005-02-23 at 13:19 +0300, Riad Souissi wrote: > Hello, > > In case the HTTPClient is set up to preserve Cookies, I have the > following problem: > > - Sometimes, HTTPClient presents a cookie which is not valid anymore in > the target HTTP server (because it timed out, or the server cleaned up > some sessions or the server restarted, etc). > - The HTTP server returns HTTP 401 error code > - The HTTPClient re-attemps to authenticate, but still re-use the same > cookie id. > - All subsequent executes that involve the HTTPConnection which has this > cookie will fail, until the Cookies are expired in the HTTPClient. > - I thought about catching the 401 code on top of the HTTPClient and > cleanup the Cookie my self. The problem is that I do not know which > Cookie ID has a problem and from which HTTPConnection object. > > My guess/suggestions is that the HTTPClient could be made to re-set the > Cookie from the HTTPConnection object it is currently using when it > receives HTTP 401 code and it had already provided the correct > Authentication credentials before (which is my case since I use BASIC > and setAuthenticationPreemptive=true). >
Riad, For what it's worth, in my opinion this assumption is application specific. The stock version of HttpClient can't (and should not) know which cookie represents a session token, and should make no attempts to invalidate it. It should be trivial to implement a custom handler on top of HttpClient that clears HttpState upon receipt of 401 status code Oleg > Any idea/suggestions/comments ? > > Thanks > riad > > > DiscalimerThe information in this email and in any files transmitted with it, > is intended only for the addressee and may contain confidential and/or > privileged material. > Access to this email by anyone else is unauthorized. If you receive this in > error, > please contact the sender immediately and delete the material from any > computer. > If you are not the intended recipient, any disclosure, copying, distribution > or > any action taken or omitted to be taken in reliance on it, is strictly > prohibited. > Statement and opinions expressed in this e-mail are those of the sender, and > do not > necessarily reflect those of STC. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
