Bug 6618 - proppatch and rfc2518
Summary: proppatch and rfc2518
Status: NEW
Alias: None
Product: Slide
Classification: Unclassified
Component: WebDAV Server (show other bugs)
Version: 1.0.16 Stable
Hardware: Sun Solaris
: P3 normal (vote)
Target Milestone: ---
Assignee: Slide Developer List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-21 17:45 UTC by Didier Berguerand
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Didier Berguerand 2002-02-21 17:45:38 UTC
In the rfc2518 document about PROPPATCH:
Instructions MUST either all be executed or none executed. Thus if any error
occurs during processing all executed instructions MUST be undone and a proper
error result returned.

If you send a proppatch to Slide for several properties and one fails, no
rollback is executed.
I get this response:

<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV">
 <d:response>
  <d:href>/lts/resource1.html</d:href>
  <d:propstat>
   <d:prop>
    <D:authors1 xmlns:D="DAV:"/>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
  <d:propstat>
   <d:prop>
    <D:authors2 xmlns:D="DAV:"/>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
  <d:propstat>
   <d:prop>
    <D:creationdate xmlns:D="DAV:"/>
   </d:prop>
   <d:status>HTTP/1.1 409 Conflict</d:status>
  </d:propstat>
 </d:response>
</d:multistatus>

and the two properties author1 and author2 remain in the descriptor store.
Comment 1 Martin Holz 2004-02-01 17:25:05 UTC
Is this still true? Which store was used? I would expect it to be 
a result of a faulty store, e.g slidestore.file.XMLFileDescriptorsStore,
which does not rollback a transaction.