> Hi Ingo, > I wrote about the PROPPATCH problem on 05/07/2004 in the dev mailing > list (subject "Client library PROPPATCH on multiple properties"), but > this message remained unanswered. Do you know if there is something new > on this? > > Also, on the client library, if I issue a PROPFIND with 10 properties, > and just 5 are set, the server reports 5 404 errors, but if I just cycle > thru the enumeration on properties returned by the method, the 404 > properties are there with no obvious way to find out that the property > is NOT set. This is because the method simply returns all "prop" XML > elements, not caring if they are positive and valid answers or 404 or > other error answers. This leads an application to believe that the X > property is set with an empty value, rather that it's not set.
There are useful and not so useful methods in the API. If you use one of the propfindMethod() methods that take a depth parameter you get an Enumeration of ResponseEntity instances which contain the status code associated with them. IMHO the other propfindMethod() methods should not be used. > > I think returning false is a good idea for the proppatch, since if just > one property could not be set, then all properties are not set. Indeed, the specification requires this behaviour. So false can be returned if one property could not be set. > Anyway, > IMMO, there should be a way of returning, from the slide client library, > a list of faileds items. Let's say this list is an array of Strings, > then i would expect to find paths of not deleted files when i'm > performing a DELETE, a list of property namespace:name when a PROPPATCH > failed or a PROPFIND receives 404 .... but this is just the first idea, > but there must be a false return and a way, easier than fully examining > the response, to know what gone wrong. The DELETE for collections is really problematic. At the moment I don't see a better solution than your suggestion to return false and provide an additional method to get the response entities with the resources that could not be deleted. Ingo > > Ciao, > Simone Gianni > > Ingo Brunberg wrote: > > >This is the same problem as with a PROPPATCH with multiple > >properties. The methods in WebdavResource simplify things too much in > >returning only a boolean value for these methods that can be partially > >successful. Returning false would not be the right thing either. > > > >If you have a good idea how to tackle that problem, let us know. > > > >Ingo > > > > > > > >>Hi, > >> > >>can somebody please, clarify the following issue with > >>the WebdavResource.deleteMethod(String) in the client > >>library? > >> > >>If i want to delete a collection wich is not empty, > >>according to the rfc2518 section 8.6.2 "If an error > >>occurs with a resource other than the resource > >>identified in the Request-URI then the > >>response MUST be a 207 (Multi-Status).", and indeed > >>this is happening, but the problem is that the client > >>doesn't get notified about the failure of the delete > >>operation because in the deleteMethod(String) the > >>"return (statusCode >= 200 && statusCode < 300) ? true > >>: false;" is used and the 207 statusCode also will > >>return true. > >> > >>Is this a bug, or it is my missunderstanding? > >>Thank you. > >> > >>__________________________________________________ > >>Do You Yahoo!? > >>Tired of spam? Yahoo! Mail has the best spam protection around > >>http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
