In the xroot protocol specification v4.0.0, §2.4.7 ("kXR_redirect Response Format") describes the login token as:
> _token_ is an optional ASCII token that, when present, should be delivered to the new host during the login phase, if one is needed (i.e. established connections to the specified host may be re-used without a login). The token, if present, is separated from the host by a two question marks. The first question mark may be followed by opaque information. If none is present, another question mark immediately follows the first one. The token does not end with a null (\0) byte.
This description provides no details on how the login token value itself is to be structured. This suggests the client will process the "login token" as an opaque token, and simply include it in the subsequent `kXR_login` request.
However, §4.11 ("kXR_login Request") describes the token as:
> _token_ is the token supplied by the previous redirection response that has
initiated this login request plus other optional elements.
This ability to merge optional elements means that the client is _not_ treating the token as opaque. It also means the token must have some kind of structure, otherwise the client would be unable to merge additional elements safely.
Could the protocol specification be updated to document the expected format for the login token?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/1534
########################################################################
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
