Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Hi Cedric
Happy New Year!
Your posts are certainly very interesting.
My particular examples of this issue (500 Internal Server Error response) were using the Vanderbilt endpoint: that's where I discovered this problem.
I'm speculating here, but the problem could be somehow related to the underlying xrootd "plugin" (sorry if that's the wrong term) for accessing the underlying storage. I believe they (Vanderbilt) are running something a little out of the ordinary, but I don't remember the details. I discovered this problem while we were investigating the cause of data corruption, which was also the result of the interface to their storage.
Did you try exercising the Vanderbilt endpoint?
However, you reply is still interesting, surprising and rather concerning. I'd say it is worthy of opening a separate issue!
When faced with a request, asking for an unknown algorithm (algorithm DOES_NOT_EXIST), the xrootd server is somehow still able to come up with a checksum value. The reply says it knows the checksum for the file using the algorithm unknown.
I'm also rather suspicious that the file (apparently) has the same value (dias4A==) for the SHA-512, unknown and SHA-1 algorithms. The values should be distinct for each algorithm, particular as the different algorithms produce values with different bit-lengths.
Just to labour the point, this returned value is also way too short for those algorithms: thvDyvhfIqlvFe+A9MYgxAfm1q5= is a valid SHA-1 value, in base-64.
If it helps any, dias4A== decodes to the four byte sequence 76 26 ac e0 (in hex) .
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this 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