 |
 |
On Tue, 7 Feb 2006, Fabrizio Furano wrote: > For the other one, related to the opaque info parsing, you are right > too. The client implemented an older protocol version, which did not > contain an opaque field by only the token field. I ignore the reasons > behind that new opaque info (Andy?), but I am implementing its support > in the newer client version (with protocol level 2). The idea for opaque information is to provide additional redirection context to the target server. This was needed largely for Castor, though I'm sure we'll find reasons to use it outside that context. > The redir opaque data will be added to the filename with a "?" in > front of it. The redir opaque data will not be forgiven by the client, > so every future open will have it, unless it is overwritten by another > kxr_redirect. That's an interesting statement. I assume you mean that the token will be passed on future opens to the same server for the same file (i.e., when doing a recovery reconnect). Opens directed to the redirector for new files or even the same file should not pass opaque token supplied by the redirector (not that it would hurt). Now, the redirector does not supply an opaque token the will that be taken as "no token" to pass? Andy