WebDAV XML parsing error due to ampersand in file names #1263
Comments
|
Frankly, the documentation here is the source file. Just look into the
src/xrdhttp directory. Any issues posted against this plugin should be
searchable; though you may miss some if they were not explicitly tagged
that way (some are not). That's seems to be a limitation of github issues.
…On Fri, 24 Jul 2020, InfinityTotality wrote:
I apologize if this is already addressed somewhere, but I'm not having any luck searching the issues or for documentation on the http protocol plugin. I'm attempting to use the XrdHttp protocol as a WebDAV server, but every client I use reports an XML parsing error. WinSCP in particular reports line numbers of the error, and I was able to track the issue down to file names that include an ampersand being returned verbatim between the <D:href></D:href> tags. Is it possibly a configurable option to escape these somewhere?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1263
|
|
I've looked through the code a bit, and the only reference to any sort of URL encoding I can find is the quote function in XrdHttpUtils.cc, but that doesn't handle ampersands, and it doesn't seem to be applied to the directory names in the XML responses as none of the other replacements are done either. This seems to match what I see in the code that builds the responses. I can't say I fully understand how iovP or resource are built, but the paths seem to be copied directly out of them into the XML response without any further processing. |
|
@ffurano - can you take a look at this? I haven't had the time to look into the details here but missing some escaping in filenames sounds plausible. Thanks! |
|
Hi, having a look. However in general the compatibility with "popular" clients is pretty limited, as these |
|
Is there a recommendation regarding what client should be used? Or is the intent here not to be a general purpose WebDAV server? I'm looking for a solution for high performance bulk file transfer over WAN a la GridFTP or bbcp. It seemed like this project was the correct solution with what's going on with GridFTP, but I'm having difficulty finding any good client utilities with support for simple file browsing and easy multi-file transfers. Particularly for Windows clients. That is understandable, of course; neither of the other two have Windows support, but standards like WebDAV are generally well supported across platforms. On a different note, I decided to test what would happen if I named a file "<D:href", and the text returned in the XML replaced the "<" with ef 80 a3 and the ":" with ef 80 a2. WinSCP simply ignores that file with no error. Windows explorer displays it as "Dhref". There is apparently some code attempting to ensure the response is valid XML, but it does not touch the ampersands. |
Personally, I haven't tested this much. I use various command-line clients (e.g., That said, providing invalid XML seems, erm, a pretty simple fix. @InfinityTotality - if you avoid filenames with metacharacters in them, does everything else work (I live in a special environment where no one does such a thing)? As Fabrizio notes, if they don't support 30x-style codes (redirects), it may not be super-useful for your use case. |
|
Hi, I tried quoting the filenames in the listing response, and the browser (and davix-ls) clearly does not expect them to be quoted, so I revert. Maybe it just needs the XML quoting, with &, this is going to be my next try. To answer to the question about clients, we built davix to have a client with just the right bits into it, including the redirection and TPC support, so I suggest davix too for simplicity. Of course everything can be done with curl and more complexity. About popular clients or mounting with davfs... they work only if the xrootd service is a single server (i.e. no redirections), so their usefulness is pretty limited. More news later... |
|
I think it's OK now. For the records, here's a significative response: $ davix-ls -l 'http://littlexrdhttp.cern.ch:1094/tmp/stupid&dir/' --trace body DAVIX(body): Read block (1102 bytes): -rwxrwxrwx 0 0 2020-07-28 10:12:40 double>stuupid&file |
|
Fixed by #1264 ... please let me know |
|
Just for the records... I realized I have pasted the wrong example. Here it's how it behaves now, and it seems to be correct to me $ davix-ls 'http://littlexrdhttp.cern.ch:1094/tmp/stupid&dir' --trace body DAVIX(body): Read block (1101 bytes): double>stuupid&file |
|
ouch now I see.... Github removes the XML escaping when pasting... |
|
`$ davix-ls 'http://littlexrdhttp.cern.ch:1094/tmp/stupid&dir' --trace body DAVIX(body): Read block (1101 bytes): double>stuupid&file` |
|
Well... apparently there's no way to paste verbatim on Github. Please trust me that the response is properly escaped now :-P |
|
Haha. I will take your word for it. I'll have to sit down and see if I can build from source at some point to test. Thanks for addressing this so quickly! @bbockelm It does seem to work well on directories with no problematic filenames using either Windows Explorer or WinSCP |
I apologize if this is already addressed somewhere, but I'm not having any luck searching the issues or for documentation on the http protocol plugin. I'm attempting to use the XrdHttp protocol as a WebDAV server, but every client I use reports an XML parsing error. WinSCP in particular reports line numbers of the error, and I was able to track the issue down to file names that include an ampersand being returned verbatim between the <D:href></D:href> tags. Is it possibly a configurable option to escape these somewhere? I am using the xrootd package on CentOS 8.1, version 4.12.2
The text was updated successfully, but these errors were encountered: