BTW, the protocol document I believe has a typo:
4.20.2.1 Additional Query Checksum CGI Tokens
The kXR_Qcksum request allows a client to pass CGI information to select a particular checksum should the server support multiple checksums. The information may or may not be acted upon, depending on the server's capabilities. CGI information is passed by suffixing the path with a question mark (?) and then coding the cgi information as shown below:
path?cks.cktype=arg
I believe that should be:
path?cks.type=arg
-Al
________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023
________________________________
From: [log in to unmask] <[log in to unmask]> on behalf of Albert Rossi <[log in to unmask]>
Sent: Friday, June 28, 2019 12:08:07 PM
To: xrootd-dev; [log in to unmask]
Cc: Dmitry O Litvintsev
Subject: checksum query in 4.0
Hello everyone,
I just realized that our server has not been modified to support the new cgi element for checksum type in kXR_query, as announced in Protocol 4.0 (which I take is no longer tentative).
I have just implemented this and also deployed it to our testbed site.
However, I noticed something rather peculiar. With the same dCache rpm deployed to both testbeds (fndcatemp1, stkendca06a = wlcg), and using the same 4.9.1 xrdcp client on my desktop machine, I am seeing different behavior in this regard.
When I do:
xrdcp491 -d 3 -C adler32 /etc/fstab root://fndcatemp1.fnal.gov:1094//pnfs/fs/usr/test/arossi/volatile/checksum-test
The server sees a request where the path is
/pnfs/fs/usr/test/arossi/volatile/checksum-test.
Doing
xrdcp491 -d 3 -C adler32 /etc/fstab root://stkendca06a.fnal.gov:1095//pnfs/fnal.gov/VOs/dteam/checksum-test
The server sees a request where the path is
/pnfs/fnal.gov/VOs/dteam/checksum-test?cks.type=adler32.
In other words, it seems the client decides in one case to add the cgi type specification, but in the other it does not.
I am curious to know exactly what would trigger such a difference in the client behavior, given that the server implementations are identical.
Thanks again, Al
________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023
________________________________
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DL-26A-3D1&d=DwMFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=z-rfqlJZ1wXy243bIR4gsbxBDoZVHMrPlgNJrJIgCCA&s=bEJFv6ozpK8D9O6aZUDJGF4_b87UcSPTt2kj-CUbYck&e=>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
