I didn't get why the webdav-js makes a HEAD requests for a folder. This looks like a bug for me.
Even if the HEAD is failed then we should try to make a PROPFIND because the folder is in fact may be browsable.

Ok, I get it. The HEAD against a directory will return 403 if there is no any HTML e.g. not index.html or directory listing enabled. Exactly the same behavior from IIS.

IIS With directory browsing enabled:
curl --head -u user:pass http://localhost/folder/
HTTP/1.1 200 OK

IISWith directory browsing enabled or index.html in the /folder/:
curl --head -u user:pass http://localhost/folder/
HTTP/1.1 403 Forbidden

Same for the Lighttpd. Looks like it was made compatible with IIS because it should be 404 instead.

Looks like the issue never occurred before because I had a directory listing previously. But I just had a plain index as a fallback. Instead I always opened the root folder that had the index.html with the webdav-js an then opened a needed subfolder.

The webdav-js is usually configured with DirectoryIndex disabled and instead Options +Indexes where the script is included to a header. This makes it possible to see webdav folder even if you opened a subfolder but also this should discard result of the generated directory index.

This is not a bug in lighttpd. The RFC clearly states:
https://www.rfc-editor.org/rfc/rfc4918#section-9.1

A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request.

In https://redmine.lighttpd.net/boards/2/topics/10081 lighttpd choose not to reject Depth: 1 on non-collections.

@stokito please do not be sloppy.
Read the RFCs before jumping to the conclusion that there is a bug because you did not understand something.

Also, please do not reference lighttpd and IIS together. lighttpd does not care one whit about IIS.

@gstrauss I saw the 403 error and googled it and found the ticket but it's about PROPFIND and not about the HEAD.
Sorry, I made I mistake. Still this is a bug in the webdav-js but also in the lighttpd because instead it should return 400 or maybe 405 because HEAD on a folder doesn't make any sense in terms of webdav. Golang webdav server returns 405 in this case.

@stokito wrote

Still this is a bug in the webdav-js but also in the lighttpd because instead it should return 400 or maybe 405 because HEAD on a folder doesn't make any sense in terms of webdav.

I repeat:

@stokito please do not be sloppy.
Read the RFCs before jumping to the conclusion that there is a bug because you did not understand something.

9.4. GET, HEAD for Collections
https://www.rfc-editor.org/rfc/rfc4918#section-9.4

@stokito you continue to demonstrate that you have no idea what you are talking about, and that you should be ignored. If that is not your intention, then please read the RFCs before jumping to the conclusion that there is a bug because you did not understand something.

thank you. the spec also says:

403 Forbidden - A server MAY reject PROPFIND requests on collections
with depth header of "Infinity", in which case it SHOULD use this
error with the precondition code 'propfind-finite-depth' inside the
error body.

So that's not a bug in the lighttpd

So that's not a bug in the lighttpd

That is a backhanded way of saying that you were wrong -- and wrong multiple times because you had not read the spec.

I think a more proper statement is "lighttpd strives to be compliant with the WebDAV specification".

I already linked to RFC 4918 section 9.1 above. Here it is again with a larger quote for those who do not read carefully:

9.1. PROPFIND Method
https://www.rfc-editor.org/rfc/rfc4918#section-9.1

A client MUST submit a Depth header with a value of "0", "1", or
"infinity" with a PROPFIND request. Servers MUST support "0" and "1"
depth requests on WebDAV-compliant resources and SHOULD support
"infinity" requests. In practice, support for infinite-depth
requests MAY be disabled, due to the performance and security
concerns associated with this behavior. Servers SHOULD treat a
request without a Depth header as if a "Depth: infinity" header was
included.

lighttpd can be configured to allow Depth: infinity with webdav.opts += ("propfind-depth-infinity" => "enable") as documented in https://wiki.lighttpd.net/mod_webdav

Thank you, once I'll have more time I'll read the spec.
The propfind-depth-infinity looks like makes a little sense in practice because the infinity scans will fail in a client and it will show the 403 error. If a client smart enough it may retry with a Depth: 1 scans of each subfolder. But I'm really not sure how smart most dav clients, especially default in Windows.

This is something that should be described in a spec (I hope it is). Because there may be some corner cases like what if the folder has too many files (e.g. rotated logs dir) and the server just can't finish the scanning.

Meanwhile the Golang's net/webdav package behaves differently https://github.com/golang/net/blob/master/webdav/webdav.go#L527
Maybe we should report a bug. Or send a PR, it should be trivial.