https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412009-07-22T05:33:47Zlighty labsLighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62132009-07-22T05:33:47Zpeto
<ul></ul><p>(Left some debug cruft in the patch by accident, by the way.)</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62142009-07-22T08:23:13Zstbuehler
<ul></ul><p>Is there a really good reason why you don't just use proxy-core.rewrite-request for this?</p>
<p>And you assume that all FastCGI applications live in "/" if i understood that correctly.</p>
<p>The other code path is used when you put the proxy-core backend in a $PHYSICAL["existing-path"] =~ "\.php$" conditional.</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62152009-07-22T12:02:57Zstbuehler
<ul><li><strong>Target version</strong> changed from <i>6</i> to <i>1.5.0</i></li></ul> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62172009-07-22T18:52:09Zpeto
<ul><li><strong>File</strong> <a href="/attachments/971">lighttpd-1.5.x.-fcgi-scgi-2.diff</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/971/lighttpd-1.5.x.-fcgi-scgi-2.diff">lighttpd-1.5.x.-fcgi-scgi-2.diff</a> added</li></ul><blockquote>
<p>Is there a really good reason why you don't just use proxy-core.rewrite-request for this?</p>
</blockquote>
<p>Because this is a bug. Is there a really good reason you want to leave a bug in place and force every Django user (and probably others) to use rewriting hacks to work around it?</p>
<blockquote>
<p>The other code path is used when you put the proxy-core backend in a $PHYSICAL["existing-path"] =~ "\.php$" conditional.</p>
</blockquote>
<p>Here's a more consistent fix: choose based on whether con->physical refers to a file that actually exists or not. If it's a real file, that path clearly belongs in SCRIPT_NAME. If not, then leave SCRIPT_NAME blank as above.</p>
<p><a class="external" href="http://example.com/forum/index.php/1/2/3">http://example.com/forum/index.php/1/2/3</a><br />con->physical = /var/www/forum/index.php exists<br />SCRIPT_NAME = /forum/index.php<br />PATH_INFO = /1/2/3</p>
<p><a class="external" href="http://example.com/joe/blog/1/2/2">http://example.com/joe/blog/1/2/2</a><br />con->physical = /var/www/joe/blog/1/2/3, which does not actually exist<br />SCRIPT_NAME = "" <br />PATH_INFO = /joe/blog/1/2/2</p>
<p>This gives the same results for Django as the current patch, and gives a correct SCRIPT_NAME/PATH_INFO for PHP-like stuff.</p>
<p>(Maybe you have a Django app that doesn't live in "/" and you want SCRIPT_NAME set to its prefix, but that's a separate issue--that'd need a new configuration setting.)</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62182009-07-22T19:04:05Zstbuehler
<ul></ul><p>But maybe it isn't the job of the webserver to decide for itself if the file exists; the FastCGI application maybe remote (or the directories/files not readable).</p>
<p>And:</p>
<blockquote>
<p>(Maybe you have a Django app that doesn't live in "/" and you want SCRIPT_NAME set to its prefix, but that's a separate issue--that'd need a new configuration setting.)</p>
</blockquote>
<p>There is a configuration setting... proxy-core.rewrite-request.</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62192009-07-22T20:03:02Zpeto
<ul></ul><p>If the file is remote, or inaccessible to the frontend, or doesn't exist as a real file at all, that means it's entirely the FCGI app's job to interpret the path.</p>
<p>The part of the path that's the FCGI app's job to interpret is stored in PATH_NAME. (RFC 3875 4.1.5.)</p>
<p>The portion of the URL that goes in PATH_NAME must not go in SCRIPT_NAME. (RFC 3875 4.1.13.)</p>
<blockquote>
<p>There is a configuration setting... proxy-core.rewrite-request.</p>
</blockquote>
<p>Using this for the basic case to work around Lighttpd not doing the above correctly is a hack.</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62222009-07-23T22:18:46Zstbuehler
<ul></ul><p>RFC 3875 4.1.13.</p>
<blockquote>
<p>The SCRIPT_NAME string forms some leading part of the path component<br />of the Script-URI derived in some implementation-defined manner.</p>
</blockquote>
<p>So our implementation differs from what you would like to have implemented.<br />I don't say your way is wrong, i just don't think the current behaviour is buggy and i don't like doing unnecessary changes.</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62292009-07-24T02:16:18Zpeto
<ul></ul><p>I explain precisely why something is wrong, and why it causes real-world problems (breaking Django), and provide a patch, and you simply refuse to fix it with no explanation. You say how much you hate hacks, yet you have no hesitation in insisting that users use ugly hacks to work around bugs that you--inexplicably--refuse to fix.</p>
<p>I'm done. Reporting bugs here is a waste of my time and there are better places I can expend my energy and patience.</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=62352009-07-24T15:21:44Znitrox
<ul></ul><p>Hm..stupid situation, both are pissed. Though i can ensure you (peto) Jan and stbuehler discussed this bug behind the scene for quite some time. I´m no expert on this, so i can´t say who´s right or wrong :-)</p>
<p>"I'm done. Reporting bugs here is a waste of my time and there are better places I can expend my energy and patience." - That would be very sad. I hope you don´t. But that was kind of offending to stbuehler, because he <em>did</em> spent some time on this too.</p>
<p>You´re always welcome to discuss things like this on #lighttpd at irc.freenode.net, and we update this and other threads afterwards for documentation.</p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=99672016-07-06T18:27:45Zgstrauss
<ul><li><strong>Category</strong> set to <i>mod_fastcgi</i></li></ul> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=100252016-07-08T19:16:05Zgstrauss
<ul><li><strong>Missing in 1.5.x</strong> set to <i>Yes</i></li></ul><p>This is unequivocally a bug if SCRIPT_NAME duplicates PATH_INFO. As peto wrote:</p>
<blockquote>
<p>The portion of the URL that goes in PATH_NAME (sic) must not go in SCRIPT_NAME. (RFC 3875 4.1.13.)</p>
</blockquote>
<p>However, the 1.5.x branch has been abandoned. (See top commit by stbuehler in branch lighttpd-1.5.x)</p>
<p>On the other hand, there are indications that the issue raised in this ticket is not an issue in the lighttpd 1.4.x branch. The official documentation provides instructions how to set up Django with lighttpd: <a class="external" href="https://docs.djangoproject.com/en/1.8/howto/deployment/fastcgi/">https://docs.djangoproject.com/en/1.8/howto/deployment/fastcgi/</a></p>
<p>Note that the above page also warns:</p>
<blockquote>
<p>Deprecated since version 1.7: FastCGI support is deprecated and will be removed in Django 1.9.</p>
</blockquote>
<p><strong>If the issue raised in this ticket still affects the lighttpd 1.4.x branch, please note that here or in a new ticket, and I will evaluate and fix it. Thanks.</strong></p> Lighttpd - Bug #2039: Wrong handling of PATH_INFO for FCGI/SCGI (1.5.x)https://redmine.lighttpd.net/issues/2039?journal_id=102072016-07-16T12:39:38Zgstrauss
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Obsolete</i></li></ul>