browse: implement OPTIONS and PROPFIND

[mark-kubacki]

I'd like to extend the built-in plugin browse by HTTP methods OPTIONS and (trivial) PROPFIND. Both are read-only. PROPFIND will add a third view to browse, which currently renders for text/html and application/json. Would you entertain a corresponding PR?

The changes will enable users of some Windows versions to enter the URL of an endpoint (representing a directory; browse displays directories) in Windows Explorer and see its contents as if it were a local folder.

[mholt]

Propfind is a WebDAV method, right? I'm not sure if we want the browse middleware to get into webdav space (do we?). Check this out: https://forum.caddyserver.com/t/webdav-server-support/1629/3?u=matt - similar?

[mark-kubacki]

browse does currently not emit listings in XML. Before inventing one from scratch I like to reuse an existing one.

PROPFIND would work like a GET, only that the parameters are in a different place and extensions get ignored. Low hanging fruit, the added benefit of becoming a convenient way for, say, developers in a LAN to get to static files (like build artifacts) without a browser.

A full WebDAV implementation would go before browse, and needs quite more than a rendering a third format.

[mholt]

only that the parameters are in a different place and extensions get ignored

What do you mean by extensions? Like HTTP extensions?

I suppose if it's just a few lines of code and not very invasive, this would be okay. Sounds like all it requires is adding a third view (XML, yuck, but whatever) and a PROPFIND and OPTIONS method check.

Although I thought OPTIONS was an attack vector for some class of HTTP attacks.

[mark-kubacki]

Re OPTIONS: The response would be:

HTTP/1.1 200 OK
Allow: OPTIONS, PROPFIND, GET, HEAD
DAV: 1, 2

… two fields, the bare minimum to get most clients to use PROPFIND. Setting this is the low hanging fruit. :-)

Re extensions: The client can set them when sending PROPFIND in the body – which would otherwise be empty on GET. Something like this, excerpt:

<prop>
  <supported-live-property-set />
  <getlastmodified />
</prop>

… can and will be ignored.

In a nutshell, the above is kind of an alias to curl -X GET -H "accept: text/xml".

The response code will be 200 with GET, and 207 with PROPFIND. The difference here is that for every file a key DAV:status is set with content HTTP/1.1 200 OK substituting the global 200 we'd return with GET. 207 tells the client to get its return code from the body, for every entry.

Bottom line, not complex and two birds one stone.

[mholt]

@wmark This sounds fine to me -- not too invasive, only the Allow and DAV headers for an OPTIONS request -- I think we could accept a PR for it.

[mark-kubacki]

Work commenced. Testing with a few WebDAV (read-only), and XML libraries to maximize impact. PR follows this week.

[mark-kubacki]

Closing this for now. I won't have the time to support this after the PR landed.