gfal2 behaves differently between "https" and "davs" about gfal2 HOT 5 CLOSED

Hi all,

could you kindly give us the reasons of the difference between the two workflows mentioned above?

Thanks,
Andrea

from gfal2.

Hi all,

do you have any feedback about this issue?

Thank you,
Andrea

from gfal2.

Hello Andrea,

I'd like to reproduce this issue.
Could I have a test location where I can try to upload a file?

Cheers,
Mihai

from gfal2.

Hello,

Trying on the endpoint you've sent me, I don't get the same behavior. Upload via both the davs:// and https:// schema works.

Can you reproduce the problem and send me your log files?
Before running the test:

1. Make sure to have LOG_SENSITIVE=false in /etc/gfal2.d/http_plugin.conf
2. Do you use macaroons? Default value is yes. Option is configured via RETRIEVE_BEARER_TOKEN=true in /etc/gfal2.d/http_plugin.conf

Example command:

$ gfal-copy -vvv --log-file=gfal2-issue16-davs.log check.sh davs://xs-606.cr.cnaf.infn.it:8443/muone-tape/test-andrea-2607
$ gfal-copy -vvv --log-file=gfal2-issue16-https.log check.sh https://xs-606.cr.cnaf.infn.it:8443/muone-tape/test-andrea-2608

Can you send me the log files from the above commands?

I see in your output that the PROPFIND command receives back an HTTP 404 (expected, as file doesn't exist), but the HEAD command receives an HTTP 403 Forbidden response. I wouldn't be surprised if Gfal2 stops the upload here. However, on the test endpoint you've sent, I can't reproduce this behavior.

As a side note, PROPFIND should only be exercised over davs:// protocol. Gfal2 exercises it as a courtesy also over https:// in case it gets a positive answer. If it doesn't, it fallbacks to the HEAD request, where it receives HTTP 403.

Cheers,
Mihai

from gfal2.

Hi Mihai,

thanks a lot for your clarifications.
To briefly summarise, I report here the reasons of the different workflows:

• When trying to upload via "https://" schema, Gfal2 does a PROPFIND looking for a positive result
• The server responds with 404 Not Found (expected behavior for a new file)
• Gfal2 falls back to HEAD request (if the schema were "davs://" this fallback wouldn't happen. On "https://" schema, there's no certainty the request was understood by the server)
• At this point, it should also receive 404 Not Found, but instead it receives HTTP 403
• A "Permission refused" error is non-retryable. Gfal2 will stop the operation as the credentials are not accepted

Also StoRM WebDAV developers confirmed that the HEAD methos is forbidden for write-only storage elements.

I close the ticket,
Andrea

from gfal2.