listPath generates: "this class is not key value coding-compliant for the key multistatus."

[jasconius]

First attempt using client

called listPath, appears to start chewing on the request and then quickly spits out:

*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<__NSCFData 0x6c81890> valueForUndefinedKey:]: this class is not key value coding-compliant for the key multistatus.'

on Line 101 of DZWebDavClient.m

[ignaciosegovia]

Same issue here when using any of the listing methods. It seems as if the NSData stream wasn't being processed as key-value compliant object.

[zwaldowski]

Hm. That's weird. I've never seen WebDAV not format its responses as anything but bog-standard XML. That means something is glitched out in DZXMLReader, which I'll look into.

[ignaciosegovia]

If it helps, the responseObject for the faulty call is being dumped as raw NSData bytes. Webdav response object: <3c21444f 43545950 45204854 4d4c2050 55424c49 4320222d 2f2f5733 432f2f44 54442048 544d4c20 332e3220 46696e61 6c2f2f45 4e223e0a 3c68746d 6c3e0a20 3c686561 643e0a20 203c7469 746c653e 496e6465 78206f66 202f7765 62646176 2d73616d 3c2f7469 746c653e...

[zwaldowski]

Would you mind doing [[NSString alloc] initWithData:encoding:] so I can see what it looks like?

[ignaciosegovia]

It's returning the html for the server...

2012-09-24 16:07:53.515 webdavApp [40294:c07] XML String:

Index of /webdav

• Parent Directory
• --/
• .DS_Store
• .TemporaryItems/
• ._.DS_Store
• ._.TemporaryItems

...

[silverbelt]

So I know this issue is old, but since no resolution is listed...

I managed to resolve this by forcing DZWebDAVClient to use DZDictionaryRequestOperation in mr_listPath:depth:success:failure:, and also removed the registerHTTPOperationClass: call in initWithBaseURL:. I haven't noticed any adverse effects from doing so, but my usage is very basic, so YMMV.

[tomasgatial]

I am experiencing same issue when using listPath method. Hopefully can be fixed soonish.

[JoHuang]

Add this to DZDictionaryRequestOperation.m +(BOOL)canProcessRequest:(NSURLRequest *)urlRequest{ return YES; }

then it can parse the data properly

Hope this helpful!

[Malaza]

Has this issue been fixed yet? I am struggling with it now, and the 'hacking' solutions offered here seem to not work very well for me..

[piersdavidson]

I had the same issue, I'll probably write a proper fix in time, but my 'hack' which is slightly better is to just process the list function:

• (BOOL)canProcessRequest:(NSURLRequest *)request {

return [[[request URL] pathExtension] isEqualToString:@""];

}

Therefore when it asks to process something else which is not within the acceptable content types it doesn't fail:

The ideal way is probably to set the acceptableContentTypes correctly, but will investigate that later...

/*

• (NSSet *)acceptableContentTypes {

  return [NSSet setWithObjects:@"application/xml", @"text/xml", nil];

} */