You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DAV4Rack::Controller#lock raises a NotFound response when the resource doesn't exist. This isn't correct behavior, per RFP4918 sections 7.3 Write Locks and Unmapped URLs and 9.10.4 Locking Unmapped URLs: http://www.webdav.org/specs/rfc4918.html Finder on Mac OS X will not allow you to create files and will revert to treating the server as read-only when it doesn't properly implement this spec form of locking.
I believe the best course of action may be to allow the resource.lock(asked) call, as the resource should decide if it should create itself as a blank file (generally correct per the spec) or do something else.
Is there any reason we can't start by removing the raise NotFound unless resource.exist? line, as resource.exist? has no knowledge that this is an attempt at locking?
The text was updated successfully, but these errors were encountered:
DAV4Rack::Controller#lock
raises a NotFound response when the resource doesn't exist. This isn't correct behavior, per RFP4918 sections 7.3 Write Locks and Unmapped URLs and 9.10.4 Locking Unmapped URLs: http://www.webdav.org/specs/rfc4918.html Finder on Mac OS X will not allow you to create files and will revert to treating the server as read-only when it doesn't properly implement this spec form of locking.I believe the best course of action may be to allow the
resource.lock(asked)
call, as the resource should decide if it should create itself as a blank file (generally correct per the spec) or do something else.Is there any reason we can't start by removing the
raise NotFound unless resource.exist?
line, asresource.exist?
has no knowledge that this is an attempt at locking?The text was updated successfully, but these errors were encountered: