You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
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, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
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