https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412023-01-20T16:48:22Zlighty labsLighttpd - Feature #3187: WebDAV and CORS wiki pagehttps://redmine.lighttpd.net/issues/3187?journal_id=134542023-01-20T16:48:22Zgstrauss
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Invalid</i></li><li><strong>Target version</strong> deleted (<del><i>1.4.xx</i></del>)</li></ul><blockquote>
<p>I spent a lot of time while configured and tested the WebDAV with CORS.<br />There is no any good documentation in internet so please add on a wiki a sample.</p>
</blockquote>
<p>There is documentation on this site which you have either failed to read, or failed to understand.<br />Since you did not reference the existing documentation in your post above, I can only assume that you did not read any of it.</p>
<p><a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_webdav">mod_webdav</a><br /><a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_setenv">mod_setenv</a></p>
<p>(I may add a link from <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_webdav">mod_webdav</a> to <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_setenv">mod_setenv</a> to point to the sample CORS policy there.)</p>
<hr />
<p>You've improved some since <a class="issue tracker-2 status-6 priority-3 priority-lowest closed" title="Feature: Load balancer friendly ETag (Invalid)" href="https://redmine.lighttpd.net/issues/3055">#3055</a>, but you are still are grossly derelict in providing references for every "must" you specify. Hint: you're wrong in many/all cases.</p>
<blockquote>
<p>I don't know ho to do that properly. Is it possible to have a dynamic header value?</p>
</blockquote>
<p><a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_magnet">mod_magnet</a></p>
<blockquote>
<p>so I confused if browser security settings changed</p>
</blockquote>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin" class="external">Access-Control-Allow-Origin</a></p>
<blockquote>
<p>Another problem is that a browser sends the OPTIONS preflight request without the Authorization: Basic header.</p>
</blockquote>
<p>Most likely issue is user-error (you) not configuring the client properly. It would be a problem with the client if the client is unable to handle authorization to access a site. If Authentication is configured, then you need access to the target resource <code>/dav/</code> for <code>OPTIONS /dav/ HTTP/1.1</code> to be permitted. That is how Authentication works. Authentication is working as designed.</p>
<blockquote>
<p>Ideally we just need to return a 204 code but it looks like this isn't possible with the lighttpd.</p>
</blockquote>
<p><a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_magnet">mod_magnet</a></p>
<p>There are soooooooooo many false statements in your post. Your post should have been questions -- not statements -- in the <a href="https://redmine.lighttpd.net/projects/lighttpd/boards/2" class="external">lighttpd Forums</a> given your demonstrated level of knowledge on this subject.</p> Lighttpd - Feature #3187: WebDAV and CORS wiki pagehttps://redmine.lighttpd.net/issues/3187?journal_id=134572023-01-20T19:06:03Zgstrauss
<ul></ul><p>If you're wondering why you get the type of response from me that you are getting, consider that your posts sound like this:</p>
<p>"Since <false statement> and <false statement>, I think ..."</p>
<p>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.</p> Lighttpd - Feature #3187: WebDAV and CORS wiki pagehttps://redmine.lighttpd.net/issues/3187?journal_id=134582023-01-20T20:36:38Zgstrauss
<ul></ul><p><strong>CORS is independent of WebDAV</strong></p>
<p>If your javascript app needs CORS headers sent from the server, then configure lighttpd <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_setenv">mod_setenv</a>, as you have done, or use <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_magnet">mod_magnet</a> to do so.</p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS" title="CORS" class="external">Cross-Origin Resource Sharing</a> (Mozilla Development Network)<br /><a href="https://diffuse.sh/about/cors/" class="external">diffuse.sh CORS requirements</a></p> Lighttpd - Feature #3187: WebDAV and CORS wiki pagehttps://redmine.lighttpd.net/issues/3187?journal_id=134612023-01-20T21:50:36Zstokito
<ul></ul><p>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.</p>
<p>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.</p>
<p>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.</p>
<p>The dynamic Allow Origin is also something that looks essential.<br />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.<br />The mod_magnet is great but as always with the unix way it gives a tool but not a ready to use solution.</p>
<p>Thank you</p> Lighttpd - Feature #3187: WebDAV and CORS wiki pagehttps://redmine.lighttpd.net/issues/3187?journal_id=134632023-01-21T02:55:26Zgstrauss
<ul></ul><blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>You have asked multiple times, and I have answered multiple times that lighttpd <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_magnet">mod_magnet</a> 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. <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_magnet">mod_magnet</a> 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)</p>
<blockquote>
<p>Please add a sample of the CORS requests to a Wiki</p>
</blockquote>
<p>As I said I would in my first post above, earlier today I added a short paragraph and link to <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_webdav#client-access">mod_webdav#client-access</a></p>
<p>As I already stated: <strong>CORS policy is independent of WebDAV</strong> 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 <a href="https://diffuse.sh/about/cors/" class="external">diffuse.sh CORS requirements</a> . 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 <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_setenv">mod_setenv</a>. Allow me to repeat that <strong>CORS policy is independent of WebDAV</strong>. 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 <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_setenv">mod_setenv</a> to accommodate, but, again note that is <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_setenv">mod_setenv</a>, not <a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_webdav">mod_webdav</a>.</p>
<blockquote>
<p>The problem with the OPTIONS method is that the basic auth must always allow it.</p>
</blockquote>
<p>That is not my understanding of the specification. <code>OPTIONS *</code> may be special, but <code>OPTIONS /target</code> should follow the authentication policy on <code>/target</code>.<br /><em>If <code>OPTIONS /target</code> did not follow the authentication policy</em>, then that might be an information exposure security bug revealing the existence of resources to unauthenticated users.</p>
<p><em><strong>If</strong> there are bugs in lighttpd not following the official specifications</em>, 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.</p>
<p>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.</p>