Print

---

This issue was discovered while debugging the CMS SAM tests which run against the eoscms.cern.ch instance using scitokens over HTTP. Basically the symptom was that the first PROPFIND request would succeed while the second one would fail. For subsequent requests this pattern would repeat itself.

The requests were submitted using gfal python bindings in the same context (TCP connection). Basically the problem came from the way the bearer token was formatted in the sense that it contained an extra new line character at the end \n (0xA in hex).

This completely messes up the parsing of the HTTP headers in the XrdHttp layer and causes predictable failures. Thanks to Joao from the FTS team, I attach a simple python reproducer using the gfal client to trigger this issue and the corresponding client logs. The important thing in this script is the reading of the token from the file which appends a 0xA char at the end of it.

The original issue is now being fixed in the CMS SAM tests but still, I think the XrdHttp parsing of the headers should be more robust and handle such cases better by for example, failing the initial request which has "malformed" headers rather then cascading the error to subsequent requests.

gfal_log.txt
gfal_test.py.txt

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/1964@github.com>

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1