Static pages plugin always returning 404

[Manko10]

IIRC the redirect status is there to allow to define a custom staticpage to be handled in case of a 404 error, and that 404 error needs to be distincted form the usual Apache ErrorHandler 404 status code that applies when a usual s9y URL is called...

This doesn't make sense.
The static pages plugin is able to handle 404 pages, that's clear. But it shouldn't use REDIRECT_STATUS to decide which status code to answer because it knows all the names of existing static pages. Actually, static_pages is already able to handle pages not being in the .htaccess well and delivers the correct page. So there is no general problem.
However, when it comes to setting the HTTP status, static_pages suddenly relies on REDIRECT_STATUS and that doesn't make any sense.
Either it has to rely on that completely, then the whole plugin wouldn't work if there isn't a specific RewriteRule or it does not. The former is a clear but not ideal implementation. But doing both is just silly.
Why does static_pages deliver the page depending on whether there is a static page in the database for the current URL but then depends on REDIRECT_STATUS for choosing the HTTP response code? If a static page is found for the current URL which is not marked as 404 handler then the response code must be 200. Checking REDIRECT_STATUS instead is the wrong way of doing things. I consider this a misimplementation.

[Manko10]

So, finally I've created a patch, which works around this issue. See the attachment.
One problem still persists (and that, of course, was also the case in the old implementation): you must not set a static page as a 404 handler if another plugin (such as the contactform plugin) also creates static pages which have no explicit RewriteRule. Otherwise this page won't show up. Instead you would see the 404 static page.
This is something I can't work around until s9y provides a centralized URL registry where all plugins have to request URLs they want to use instead of catching 404 by semselves (or is something like that already implemented?).
But this patch at least fixes 404 handling within the staticpage extension itself. And as long as you don't set any static page as 404 handler there should also be no conflicts with other plugins anymore (that's the reason why I don't use the staticpage plugin for 404 pages). But if you do, you have to write specific RewriteRules as before.

EDIT:
Well, seems like the file upload doesn't work. So I have uploaded the patch here: http://nopaste.info/6b2558f040.html

[garvinhicking]

Hi!

Did you check to use permalinks that end on .html?

Unrelated to that, your patch definitely improves the situation so I'll commit it now! Thanks a lot for your ongoing inspection and ambition to get this improved!

Regards,
Garvin

[Manko10]

.html should work as expect as there is a generic RewriteRule for that. But for consistency reasons I don't want to use a different URL scheme for the static pages, nor do I want to add extra RewriteRules.
With this patch the problem I created this thread for is solved. Only those users who use the staticpage plugin for their 404 handler still have a problem with other plugins creating static pages which do not have a specific RewriteRule.