Should the response to a kXR_prepare request always be a null terminated string?

[murrayc3]

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?

[abh3]

Thanks for bringing this up. This is not the only place we have this ambiguity. Our general take is if we do not explicitly say x then you cannot assume x. Here, we normally say "One should neither assume the response is printable nor that it is null terminate; as the response is implementation dependent."

[murrayc3]

Many thanks for the clarification. A test version of the XRootD client plugin for GFAL2 has been created that does not assume the value is null terminated.

[murrayc3]

This ticket can be closed.