Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug, critical: PROPFIND requires for Depth header #123

Open
stokito opened this issue Mar 1, 2023 · 8 comments
Open

Bug, critical: PROPFIND requires for Depth header #123

stokito opened this issue Mar 1, 2023 · 8 comments

Comments

@stokito
Copy link

stokito commented Mar 1, 2023

The Lighttpd 1.4.61 now blocks PROPFIND without the Depth: 0 or Depth: 1. So when I trying to click on a folder I get the error:

HEAD https://192.168.1.1/dav/photos/ net::ERR_ABORTED 403
Line HTTP.ts:45

Please add the Depth: 1 for requests.

See https://redmine.lighttpd.net/boards/2/topics/10081 for details

@stokito
Copy link
Author

stokito commented Mar 1, 2023

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.

@stokito
Copy link
Author

stokito commented Mar 1, 2023

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.

@gstrauss
Copy link

gstrauss commented Mar 2, 2023

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.

@stokito
Copy link
Author

stokito commented Mar 3, 2023

@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.

@gstrauss
Copy link

gstrauss commented Mar 4, 2023

@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.

@stokito
Copy link
Author

stokito commented Mar 4, 2023

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

@gstrauss
Copy link

gstrauss commented Mar 4, 2023

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

@stokito
Copy link
Author

stokito commented Mar 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants