https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412007-01-27T15:46:28Zlighty labsLighttpd - Feature #965: New conditional: Physical pathhttps://redmine.lighttpd.net/issues/965?journal_id=22802007-01-27T15:46:28Zhoffie
<ul></ul><p>This was implemented (for 1.5) in r1528.</p> Lighttpd - Feature #965: New conditional: Physical pathhttps://redmine.lighttpd.net/issues/965?journal_id=100782016-07-13T23:44:13Zgstrauss
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/10078/diff?detail_id=8561">diff</a>)</li><li><strong>Status</strong> changed from <i>New</i> to <i>Need Feedback</i></li><li><strong>Assignee</strong> deleted (<del><i>jan</i></del>)</li></ul><p><a class="user active user-mention" href="https://redmine.lighttpd.net/users/5">@hoffie</a>, not sure if you're still watching this.</p>
<p>While it would be possible to add a conditional to lighttpd 1.4.x branch, doing so would increase complexity and, more importantly, increase potential confusion for users attempting to properly configure their systems. I have seen many times where Apache admins had trouble grasping that physical path conditionals occur much later in request processing (i.e. after URL-to-physical path mapping, and after other processing has occurred).</p>
<p>Can you be more specific about what you are (were) trying to protect and in what ways you are (were) trying to protect it? Between CGI, FastCGI, SCGI, path aliases, symlinks, and more, it can be difficult to protect assets which are accessible to the web server, but which you wish to handle differently for multiple internal users who all have access to modify server content and processing. Best practices suggest better isolation into different processes running under different user accounts or VMs, accessed via HTTP proxying or other mechanisms.</p> Lighttpd - Feature #965: New conditional: Physical pathhttps://redmine.lighttpd.net/issues/965?journal_id=103612016-07-24T19:38:42Zhoffie
<ul></ul><p>Yes, I am still watching this. ;)<br />I agree that there is a chance that this feature may end up confusing users.</p>
<p>Personally, I do not have any interest in this feature any longer since I am currently not maintaining any environments where this would be relevant. Unless there are other users requesting this feature, we could close this one as WONTFIX, I guess.</p>
<p>Regarding the use case: I was trying to map a specific Apache configuration to lighty syntax. The semantics had been dictated by the generating tool (<a class="external" href="http://syscp.org">http://syscp.org</a>). Sadly, I do not remember any more details after 9 years ;)</p> Lighttpd - Feature #965: New conditional: Physical pathhttps://redmine.lighttpd.net/issues/965?journal_id=103622016-07-25T04:54:45Zgstrauss
<ul><li><strong>Status</strong> changed from <i>Need Feedback</i> to <i>Wontfix</i></li></ul><p>As you suggest, I am going to mark this WontFix. Also, syscp itself does not appear to have been updated in 6+ years.</p>
<p>Regarding lighttpd and physical paths: while it would not be difficult to add a hook to call modules once the physical path was determined, the brunt of making it useful requires evaluating each module to determine whether or not it should be called from this hook, and then modifying the module to potentially be called more than once at different phases of the request. For example, mod_access is called early in the request and operates on the URL. mod_access would need to be called again, once that physical path is determined, perhaps with new directives path.access-allow and path.access-deny in addition to the existing url.access-allow and url.access-deny.</p>
<p>For this reason, I am going to mark this WontFix. If someone has a must-have use case which must operate on physical paths, please explain it here in detail and we may reconsider this feature request.</p>