Closed ghost closed 4 years ago
Oh, yeah, hmm is there a way we can discern the error from the library and handle it appropriately?
Did a quick test and it seems to return 404 for me or do i misunderstand? about the log message, the error passed to the Logger callback is a &os.PathError{Op:"stat", Path:"root/asdsad", Err:0x2}
, maybe we can filter out based on that?
Did a little more digging. It looks like this is either an issue of the webdav library not conforming strictly to the spec, or my WebDAV client interpreting the spec too narrowly. Either way not a caddy plugin issue so closing.
Like @wader says it is returning a 404. Looks like the issue is either that it should be responding with an XML body along the lines of the below, or the client is wrongly expecting it to.
<?xml version="1.0" encoding="utf-8"?><d:error xmlns:d="DAV:"></d:error>
Thanks for looking into it more! If that's the case, then I agree the issue is either in the upstream lib or the downstream client. But I don't know the WebDAV protocol enough to know the answer without more research.
After trying to read the RFC tonight, I don't think it knows either. Who's idea was it to write a protocol spec in unstructured natural language? 😋
When receiving a PROPFIND request for a file that does not exist, the plugin is logging an internal handler error, instead of responding appropriately, which I imagine would be with a 404.