OK, I now see what the issue is. Here is the scenario:

1. User gets authentication error. This is an error during the handshake phase so it's marked as fatal and the socket is disconnected but the stream persists because, hey, it might need to be reconnected at some future time.
2. Indeed, at some later time the user attempts another request.
3. The request gets routed to the stream and the stream eventually calls Stream::EnableLink.
4. EnableLink notices the socket for he main stream is not connected. It check if there was a fatal error at the time of disconnection (there was, auth error) and whether enough time has passed since he last connection attempt. It hasn't because by default 1800 seconds must have passed (i.e. 30 minutes) so it simply returns the last error (auth failed).

We can see that this logic has many undesirable effect among which the default retry window is far too long. Essentially, all requests that started with a bad certificate during login are prohibited by the user who got that error for 30 minutes., even if this was a transient error. OK, we don't know how transient it really is.

While this may be OK for a regular client it wreaks havoc with a proxy server which essentially unusable for a very long time if a) a certificate is not renewed on time, or b) a transient authentication error occurs.

I suppose the expedient thing here is to reduce the time window but that really is not a good solution in the long run. I suppose I'm looking for alternative suggestions here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1