 |
 |
Dear XRootD experts, The following web page documents the `kXR_prepare` request: * https://xrootd.slac.stanford.edu/doc/dev55/XRdv511.htm#_Toc116591755 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: * Should the response to a `kXR_prepare` request **ALWAYS** be a `null` terminated string? -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1888 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