Lighttpd

If you're wondering why you get the type of response from me that you are getting, consider that your posts sound like this:

"Since <false statement> and <false statement>, I think ..."

If you do not understand the specifications, you should not make statements. Instead, you should ask questions in the forums. Ask well-reasoned questions that demonstrate that you have read the specifications and the lighttpd official documentation. In your questions, provide references to the specifications and to lighttpd official documentation for any statements that you make, or provide factual observations of your testing. Omit your ungrounded judgements/presumptions/assumptions.

CORS is independent of WebDAV

If your javascript app needs CORS headers sent from the server, then configure lighttpd mod_setenv, as you have done, or use mod_magnet to do so.

Cross-Origin Resource Sharing (Mozilla Development Network)
diffuse.sh CORS requirements

Please add a sample of the CORS requests to a Wiki because the Google search doesn't helps. And additionally we need a sample of CORS requests for WebDAV that allows additional methods. My sample file works and hope it helps to people but I'm not confident in it. So that's why I asking you to fill the gap in documentation.

The problem with the OPTIONS method is that the basic auth must always allow it. Because in my case I have it configured in place but the auth may be configured somewhere else for entire www root.

The Nginx has the `return 204` and it's simple and natural. For me it looks like the Lighttpd may benefit from it too. When I googled I found a solution to create a CGI script. Likely for my case this wasn't required and the default 200 works fine.

The dynamic Allow Origin is also something that looks essential.
Using the mod_magnet makes a lot of problems. It must be installed additionally and scripts should be uploaded or created on SSH and probably `chmod +x` is needed. This increase difficulty for a regular users. I have a friend who is a regular Java Dev like me and explaining to him how to configure it's own server may make him too lazy.
The mod_magnet is great but as always with the unix way it gives a tool but not a ready to use solution.

Thank you

Using the mod_magnet makes a lot of problems. It must be installed additionally and scripts should be uploaded or created on SSH and probably `chmod +x` is needed.

lua is small, about < 300k on a 64-bit system, and smaller on a 32-bit system. And no, you are wrong (again): lua scripts run in lighttpd do not need +x permission. You're already asking people to edit a file for lighttpd.conf additions to configure mod_webdav, and that ought to be a new file in /etc/lighttpd/conf.d/. Yes, adding an additional file for a lua script is one additional step, but the user already has to do some basic file editing. Then again, if you provide your lua script as part of an installable package, then there is no additional step besides installing your package, and installing lighttpd-mod-magnet, which has a dependency on lua.

You have asked multiple times, and I have answered multiple times that lighttpd mod_magnet provides a way for you to return an arbitrary status code and to dynamically set response headers in lighttpd. lua is a programming language and can do many, many, many more things than the specific nginx syntax you mentioned. mod_magnet is generally the answer for "I need to do something arbitrary or dynamic" within lighttpd. (Dynamic content generation or complex, blocking behavior should be performed in a dynamic backend, be it CGI, FastCGI, SCGI, AJP13, reverse proxy, or something else)

Please add a sample of the CORS requests to a Wiki

As I said I would in my first post above, earlier today I added a short paragraph and link to mod_webdav#client-access

As I already stated: CORS policy is independent of WebDAV There is no generic one-size-fits-all CORS policy. CORS includes a set of configurable headers for a configurable policy depending on site and app requirements. If an app needs a certain CORS policy, then the app might document it, like diffuse.sh CORS requirements . The sample CORS config you provided is clearly excessive for diffuse.sh requirements. If you have a working sample config which is not throwing the kitchen sink into the headers, I may consider adding another example to mod_setenv. Allow me to repeat that CORS policy is independent of WebDAV. lighttpd mod_webdav works with numerous WebDAV clients without any CORS policy. If a random client app (e.g. in javascript) requires CORS, then you can configure lighttpd mod_setenv to accommodate, but, again note that is mod_setenv, not mod_webdav.

The problem with the OPTIONS method is that the basic auth must always allow it.

That is not my understanding of the specification. OPTIONS * may be special, but OPTIONS /target should follow the authentication policy on /target.
If OPTIONS /target did not follow the authentication policy, then that might be an information exposure security bug revealing the existence of resources to unauthenticated users.

If there are bugs in lighttpd not following the official specifications, then I will try to fix such bugs (should they exist) in lighttpd. Please point me to the official specifications if you think lighttpd is doing something incorrectly.

I will not respond further until you provide a link to the RFC specification to support your statement. I have asked too many times for you to support your (often misinformed or false) declarative statements.