Lighttpd

Why would you file a bug about your own configuration issue?

It returns 404, cause it was told to.

Using fastcgi html => php is not a supported rewrite/redirect method, so it's doing exactly what it should.

As you commented on the other bug, that said all this also.

Because i did not configure it to do so?
And the documentation on html => php is not really well documented, the mapping function is barely mentioned considering all the other documentation.

All i want lighttpd to do, is treat html files as if it was a php file.
Hence i disabled static file transfer for html files and tell it to send it to php, or at least i thought i did until lighttpd gives me mixed results.

I get the content, why wouldn't i get the proper header?
I havn't explicitly configured lighttpd to do anything, i mainly run on a default config.

It's worth pointing out, even pure .php files get this error too!

I've also configured:

; if cgi.nph is enabled it will force cgi to always sent Status: 200 with
; every request. PHP's default behavior is to disable this feature.
cgi.nph = 1

This forces PHP to always return a 200 status code, which LIGHTTPD DOES NOT HONOR.. gha this is a real PITA..

And here's the detailed error log:

https://gist.github.com/Torxed/6028350

Also a screenshot of this shitty mess, Since i'm almost convinced PHP always returns 200 i'm flipping out here, there's no reason why lighttpd should respond with 404

# python fcgi_app.py

{'FCGI_MAX_CONNS': '1', 'FCGI_MPXS_CONNS': '0', 'FCGI_MAX_REQS': '1'}

Since i'm not to deep into the FastCGI protocol i can't make a proper request for a file, i can only get configured parameters and see what the servers allows me to do but the server works and treats me well enough to give me the configured parameters that it should.. So, lighttpd? Considering all evidence points towards that PHP works as it should IMO. If i'm wrong tell me why and don't give me some standard bullshit that "you configured it wrong", tell me where it's wrong and why it would matter so i can fix it, until then lighttpd is broken by design.

Given that we never received such report on linux and other systems, it should be obvious that everyone is blaming your platform (and you/your config, because windows users are usually not considered that qualified around here).
Also we have a test suite that would catch this error if it happened all the time.
But I agree that this looks like a bug, and quite possibly in lighttpd, so I won't close it as invalid.

So.

I just checked the current source and didn't see anything that might set 404 if the request gets handled by fastcgi. I'm not sure how you got your binary, so I have no idea whether you're using a modified source. (I also don't know what wlmp-project.net is patching - the site lists some 3rd party modules which I think require core changes.)

If you were on a sane system I'd ask you to get a strace of lighttpd, then we would see what it reads from the FastCGI backend, or use tcpdump/wireshark to capture traffic (but windows wireshark can't capture loopback traffic...). So your debug methods are limited, and no developer is interested to test on windows.

If you can tell us where the bug in lighttpd is, we ofc will try to fix it. But from the data we have there is not much we can do apart from reading the source (that might not even be the source you are using).

You also asked how you can fix it: use a sane platform. lighttpd won't perform well on windows anyway (due to using select() as fdevent backend), so just install some linux dist in a VM (or on dedicated hardware).

If you really think that because of this bug or peoples reaction to it "lighttpd is broken by design" I ask you to leave us alone, thx.

Oh, you failed to mention that you got a quite helpful answer on stackoverflow, which indicates the bug might be as well in php/your php config.

And sorry that i associated your problem with windows, but your first question was in a "windows" bug report.