 |
 |
I suppose I wasn't clear either. At the face of it, if the client asks for a single checksum and it isn't supported, I think he server is well in it's bounds to return an error. If the list of checksums is given and at least one of the checksums is supported then the server should return that checksum and I think it's plausible to interpret the RFC in that way -- don't return an error if you encounter an unsupported checksum in a list of checksums. However, if none are supported it would be legitimate to treat it as a single checksum failure. The only case I can see where the header could plausibly be ignored is when it is combined with a file transfer. So, we supply the bytes (if we can) but do not return a checksum. In each of these cases the client has to deal with the outcome whether it's an error or missing information, structurally it's the same thing. Note that this may be very inefficient if the client can't do anything with the bytes without a checksum. In that case, the transfer is a total waste of resources. As for supplying the default when none of the checksums are supported is rather odd. Generally, if someone wants the default checksum they would ask for it. -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1707#issuecomment-1126650038 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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