Print

Print

This should not be closed. This should be fixed so that the same behavior is observed when using either xrootd or http. At the moment one would need to regularly restart the xrootd daemon to have this working properly and for a service like EOS, for example, this would mean restarting the manager node regularly which is not an option.

Also the difference in behavior is confusing since any access over the xrootd protocol works fine but doing the same thing, with the same certificate over HTTP fails with "certificate expired" error.

The HTTP part should probably make use of the same mechanisms that XrdSecgsi uses to avoid such issues with expired CRLs. Given the upcoming R5 I think this is the perfect timing to properly address this ... since I assume 4.11.* branch will never see this fixed. Thanks!

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

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/750#issuecomment-607690763", "url": "https://github.com/xrootd/xrootd/issues/750#issuecomment-607690763", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

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