1 / 15

WebDAV – IETF 56

WebDAV – IETF 56. Agenda. Interim WG meeting and Interop Testing - Jim RFC2518bis: Lisa Dusseault GULP = Grand Unified Lock Proposal Other issues Quota: Brian Korver Bindings: Geoff Clemm Ordered Collections: Geoff Clemm ACL: Geoff Clemm DASL: volunteer??. Interop/Interim results.

graiden-guerrero
Télécharger la présentation

WebDAV – IETF 56

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WebDAV – IETF 56

  2. Agenda • Interim WG meeting and Interop Testing - Jim • RFC2518bis: Lisa Dusseault • GULP = Grand Unified Lock Proposal • Other issues • Quota: Brian Korver • Bindings: Geoff Clemm • Ordered Collections: Geoff Clemm • ACL: Geoff Clemm • DASL: volunteer??

  3. Interop/Interim results • Held face-to-face interoperability testing event in Sept, 2002 • 37 people attended, tested 13 clients, 16 servers • much improvement in interoperability • Progress underway to develop improved compliance test suite • Improved version of Litmus • "Harry" a database-driven compliance tester • Both currently held up by Adobe IP release process • Work underway to address this • Continuous online interoperability testing

  4. GULP • Do UNLOCK requests to an indirectly locked resource work? • Or does the client have to address lockroot? • Change/clarify what “submitted” means • W.r.t. lock tokens submitted in the If header • Keep in mind goals of RFC2518bis and GULP • Clarify without changing spec • Improve interoperability

  5. Agreed text so far • A lock either directly or indirectly locks a resource. • A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request.

  6. Agreed text continued • If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a internal member is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing an internal member URL identifying that resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock.

  7. First problem • “An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock.” • Confirm indirect?

  8. Second problem: “submitted” • “A lock token is "submitted" in a request when it appears in an If header.“ • Julian asked for this to say that the token must be tagged with the lockroot URL • That is inconsistent with RFC2518 untagged syntax • Breaks clients • Harder to get right

  9. What is locked • The following operations must fail unless the lock-token for the lock is submitted in the request: 1. modify the content for a locked resource 2. modify a dead property of a locked resource, 3. modify a lockable live property be for a locked resource 4. modify an internal member URL in a locked collection, 5. modify any content, properties or URLs of any descendent of a depth-infinity locked collection.

  10. Last piece • If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail.

  11. Allprop replacement proposal <propfind xmlns=“DAV:”> <prop> <resourcetype/> <getlastmodified/> <quota xmlns=“http://www.xythos.com/ns/”/> </prop> <dead-props/> </propfind>

  12. 207 Replacement • Proposal A • Define “partial success” response • New 400-level error code • Multi-status body • Proposal B • Do nothing • Not an interoperability problem

  13. Are ETags required • Current consensus appears to be • Servers SHOULD implement • Standard will explain why this is a really good idea

  14. Response bodies with extensible error codes • Some text in latest version of rfc2518bis • To do a complete job, need to define more codes and exactly what they mean • Guidance from WG?

  15. Small changes • Changed domains to “example.com” or “example.org” • Clarification how live property copy works differently than live property move • More If header parsing/handling clarity • Require servers supporting ‘bis’ to handle commas in If header

More Related