Handle Nginx DAV PROPFIND responses correctly

[bradmcl]

Parse the d:status field for d:propstat sections within a d:multistatus response to a DAV PROPFIND because Nginx returns 404 statuses wrapped in an overall 207

Proposed fix for #523

[laurent22]

The WebDAV XML is often quite messy and changes from one server to the next, so I think this line might cause problem if something is not defined or defined differently:

propStat[0]['d:status'][0].split(' ')[1]

Is there any way to get it working with stringFromJson() or similar (as these functions have many checks to support various formats)?

[bradmcl]

Sure, here's a rewrite taking it that direction.

[laurent22]

Could you confirm it indeed works with your Nginx server (as I can't test myself)?

Also this line httpStatusLine.split(' ')[1] === '404' could be an issue if the http status text is non-standard and doesn't have spaces or if the 404 is not in the second position. So to be safe I think it'd be better to just check the presence of the string "404" anywhere in the status code.

[bradmcl]

I can definitely confirm that it works with Nginx for me; I've been using a local build and ignoring updates since I posted this PR, and I've had no issues.

On the split concern, I'd done a quick check ( I am not a Javascript native, this is a bit of a drive-by, and I'll be back to Python, C, and assembly as soon as I solve this itch), which caused me to think this was likely okay:

Bradleys-MacBook-Pro:joplin brad$ node

x = "blah 101";
'blah 101'
y = "";
''
z = 2;
2
x.split(' ')[1];
'101'
y.split(' ')[1];
undefined
z.split(' ')[1];
TypeError: z.split is not a function
x.split(' ')[1] === '404';
false
x.split(' ')[1] === '101';
true
y.split(' ')[1] === '101';
false
z.split(' ')[1] === '101';
TypeError: z.split is not a function

If that's not good, I'm happy with any other interpretation that works. I don't think the 404 can be anywhere else since that's a standard regulated string.

[laurent22]

I thought accessing an array out of bonds would throw an error, but it seems it indeed doesn't.

Just to be completely safe though I would prefer something like httpStatusLine.indexOf('404') >= 0. Since we are sure httpStatusLine is a string, we know it will have the indexOf function, and then we don't need to worry where the 404 is going to be in that string.

I agree there's a standard but many implementations do their own thing so it's better to be safe, since that class is used to access many different services.

[bradmcl]

Continues to work fine with that change.

[laurent22]

That's great, thank for the update.