Print

---

Hi,

  I checked the stuff and I am fixing it.
  You are right in both comments. Thank you for reporting the troubles!

  One issue was something like a typo committed in the recent 
pre-porting changes.

  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).

> 
> After receiving a redirect message from the redirector, the client
> doesn't seem to handle the response data correctly. To be more precise,
> the client is parsing the newHost-string in order to find the optional
> token (separated by a question mark). But what about the second
> parameter (opaque data) as specified in the Xrootd protocol
> (kxr_redirect response)? Why is it not parsed as well?
> 
> Another thing is, that whenever one of this two parameters (or both) are
> passed along with the redirect response, the client (and therefore
> TXNetFile) fails extracting the correct new host
> (XrdClientConn::ParseRedir()). If I'm not mistaken, this is caused by
> "host.EraseFromStart(pos);" instead of "host.EraseFromEnd(pos);". 
> 
> BTW, if the client is redirected, how is the opaque data (if present)
> encoded in the request message when re-opening the file on the data
> server?
> 

  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.


> Thanks,
> Martin
> 

Thanks to you!
Fabrizio