Tested gfal2 2.19.1 & FTS (still require additional OSG package x509-scitokens-issuer-client)

• dCache (FZK) TAPE endpoint works fine with SRM+HTTP macaroons
• StoRM (INFN-T1) TAPE endpoint still fails to provide SRM+HTTP support

$ gfal-copy srm://storm-fe.cr.cnaf.infn.it:8444/srm/managerv2?SFN=/atlas/atlasdatatape/data16_13TeV/DAOD_RPVLL/r9264_r10573_p3578/data16_13TeV.00302831.physics_Main.merge.DAOD_RPVLL.r9264_r10573_p3578_tid14401125_00/DAOD_RPVLL.14401125._000062.pool.root.1 davs://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/test/x.srm.storm
gfal-copy error: 5 (Input/output error) - SOURCE SRM_GET_TURL error on the turl  request : [SE][StatusOfGetRequest][SRM_FAILURE] Unable to decide TURL!

Should we try GGUS to INFN-T1 or is there better way to pass this new requirement to the INFN-T1 storage ops team? ... Enabling SRM+HTTP needs official ATLAS request.

Unable to test with fts3-next-devel, because it prefers just gsiftp as TURL_3RD_PARTY_PROTOCOLS (still use gridsite X.509 delegation with my old FTS 3.9.5).

UPDATE: fts3-next-devel now use https as preferred protocol while SRM asks for TURL and I can confirm that FZK tape now works fine with SRM+HTTP(macaroon) using this FTS instance. We can start to think about TAPE endpoint tests SRM+HTTP tests.

UPDATE2: GGUS:149954 SRM+HTTP can be used to upload file to StoRM disk, but upload to INFN-T1 tape works just partially, because uploaded file can't be accessed with SRM+GridFTP (empty file).