Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Dear XRootD experts,
The following web page documents the kXR_prepare request:
The documentation does not specify if the binary resp buffer returned by a normal response should contain a pure binary response or if it should always be a null terminated C-string.
The GFAL project and indirectly the FTS project have been effected by this ambiguity. When GFAL sends an kXR_prepare request to an EOSCTA storage end point it receives back a binary buffer of 45 bytes which consists of 44 printable characters followed by a null terminator. In other words EOSCTA returns a null terminated string. However when GFAL sends an kXR_prepare request to the dtn20.nese.rc.fas.harvard.edu:1094 storage end point it receives back a binary buffer of 36 bytes that contains 36 printable characters and NO null terminator.
If the response should always be a null terminated string then the GFAL project's code should be modified to fail the kXR_prepare request sent to dtn20.nese.rc.fas.harvard.edu:1094 due to an invalid response. Before this modification can be made we need the XRootD experts to answer the following question:
kXR_prepare request ALWAYS be a null terminated string?—
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