Serendipity Forums

Hi there,

my hosting provider uses a FastCGI PHP configuration with suEXEC and now I have the problem that the static pages plugin always returns an error 404, although the page itself is shown correctly.
This problem is not caused by a Status header not being set (which is required for FastCGI), since that's in the code. And in fact, the problem is not that the server ignores the definition of the status code, but rather that only the else condition is evaluated.

Therefore the problem is in lines 2708 through 2711 which are:Actually, I don't know what these lines are good for. As far as I know, the static pages plugin works in a way that it catches any 404 redirect and checks whether the entered path is an existing static page. Therefore this condition will always apply resulting in $this->error_404 always being set to true.
Maybe you can enlighten me on the avail of these lines. For the time being, I have commented them out.

Hi

Are you sure you did not define the mentioned staticpage as an 404 error page in the entry pages options box?
Does the page itself exist?
Did this problem come first with adding this STATUS 404 possibility to the staticpages plugin?
Do you really use staticpages version 3.85, which corrected the header having a typo?

No, both static pages are not set as 404 error pages.
What do you mean with "exists"? I have added them using the backend. There is no file on disk for it or so. Both pages have content, which is shown properly. Only the HTTP status code is not correct.
I don't know when this problem occurred the first time, I only know that it's there now.
Yes, I'm using the latest version of the plugin. As I wrote: everything WOULD work if there weren't this if condition, which I don't understand. This condition should ever be true, so it's no surprise that the error code is 404.

Ok not defined as 404 and page exists in backend, thats what I meant.

If you mean your "about" page, your Status Code is "HTTP/1.1 200 OK", which is done via serendipity_header($_SERVER['SERVER_PROTOCOL'].' 200 OK');
I dont really know why the STATUS: 200 OK header isnt working in your case.

No the 'genpage' $_SERVER['REDIRECT_STATUS'] is working as expected, at least here in my enviroment.
I had an old version before here, which was actually not the 3.84 with the typo, which did give me the same 404 header, but the correct page too. Then I updated to 3.85 and now it is "Status: 200 OK".

In your case gzip is active and connection close. mine is: Maybe it has to do with the gzip, and I darkly 'remember' having read about some 'Status bug' with gzip running.

Hi!

Sadly I didn't really grok the 404 error page mechanism myself, so I can't really tell what's happening. But Ian, I believe Manko mentioned that not the header itself is the problem, but rather that the error-404 page variable is set in his case, which would emit the 404 header in that case...

Manko, do you maybe run postgresql? In that case, some boolean yes/no logic could be the root of the problem...

Regards,
Garvin

Yes thats what I tried to say the other way round ....
remembering darkly some CGI probs with $_SERVER['REDIRECT_STATUS'] and STATUS: 200 OK and possible gzip encoding activated.

@Timbalu It's my about and my privacy page (linked in the footer). Currently, both are returning 200 because I have commented out line 2709 which is I still don't understand what this code should do exactly. I mean, REDIRECT_STATUS is set if this document is called as a 404 handler. This is always the case since the static pages plugin catches any error 404 and checks if there is a static page with that URL. Therefore this environment variable is always set and that is the reason for my static pages returning 404. Or am I wrong?

@garvinhicking No, I'm using MySQL. But anyway, this shouldn't be important since REDIRECT_STATUS is set by Apache, not by my DBMS.

BTW I don't understand why you use REDIRECT_STATUS at all. It's highly unpredictable, depends on how PHP is executed (mod_php, FastCGI, CGI), Lighttpd and Apache handle it somehow differently and so on.
Normally it should be always 404 when the script is called as 404 handler/ErrorDocument So in my case it seems to be the correct behavior.
Why don't you just check if there is a static page with the specified URL and if yes, set status to 200, if not (or if the found static page is marked as 404 handler) leave it as is. Why depend on REDIRECT_STATUS?

I think it has to do something with $view = 404.
I can understand its confusing, but If it always would be a 404 not found header, I would not get a 200 OK here, would I?! It must be some special case sending a 404 in your enviroment case. http://www.php-faq.de/q-konfiguration-cgi.html
You could try and debug to find out why $_SERVER['REDIRECT_STATUS'] has a 404 and/or why serendipity_header('Status: 200 OK'); isn't set.

As I said: serendipity_header('Status: 200 OK') is not set because REDIRECT_STATUS is always 404.
The reason being that the static page is not redirected by any rewrite rule in my .htaccess (it would be quite cumbersome if I always had to manipulate my .htaccess in order to get my static pages working properly). Instead Apache uses the ErrorDocument directive and thus issues the index.php. The static_pages plugin now analyzes the request URL and tries to find a static page with that name.
This means, REDIRECT_STATUS (which is not a standardized variable, BTW) is always set to 404 and cannot be 200. Never ever, unless I write a specific RewriteRule into my .htaccess. It would be highly surprising if it were 200 (but that's what some versions of Lighttpd deliver, another reason not to rely on this variable).
That's just the way it works and therefore it doesn't make any sense to check if REDIRECT_STATUS is 200 as it will always be 404. I do not wonder why it doesn't work for me, I rather wonder why it actually works for you.
Again, tell me if I misunderstood something.

Sounds highly reasonable, yes, .... ... .. . BUT I think Serendipity does work a little bit different.
Example using mod_rewrite: Searching a page which does not exist outputs .htaccess = ErrorDocument 404 /serendipity/index.php as fallback.

As you can see, the truly 404 not found is in $view and $viewtype and my REDIRECT_STATUS is 200 OK, since index is found OK by system. This is the normal behaviour, I assume.

An existing static page produces This 200 OK header generates from serendipity_header('Status: 200 OK'); in staticpages, I think. Dito for other plugins.

I don't quite grasp what you mean. For me REDIRECT_STATUS is always 404 except for those pages which either have a RewriteRule in my .htacess or exist as files. Therefore your debugging code returns something like thison all static pages (the last 404 is the output of print $_SERVER['REDIRECT_STATUS']).
And again, this is exactly what I expect s9y to output. Everything else would be illogical. Why should REDIRECT_STATUS be 200 here? There is no RewriteRule for any static page nor is there a file on disk. The static pages are only reachable because there is the ErrorDocument directive in my .htaccess. If I remove it, static pages won't work at all. Therefore it is the correct behavior that REDIRECT_STATUS is 404. If it were 200 (as it seems to be in your case) that would be a wrong behavior.

Sorry for pushing, but is there in progress or any enlightenment about this issue?

Hi!

Sadly I myself mostly work with Apache+mod_php, so the current redirect_status implementation seems to work for me...

Are you able to utilize RewriteRule in your .htaccess? If so, setting s9y to use mod_rewrite in the config, there is a generic RewriteRule that matches all *.html pages (so applies to static pages) that would trigger a redirect, apart from the ErrorDocument 404 fallback...?

(Sorry for my half-witted comment, I wanted to not let this thread die but am not really much into this specific part of the code)

Regards,
Garvin

My static pages don't end with .html. They are named /about/ and /privacy/.
As said above: currently I have commented out the line causing the problem instead of using my .htaccess. This prevents me from forgetting to add a new rule if I add a new static page.
And again, I don't understand the purpose of using REDIRECT_STATUS. Why is it used? Why doesn't the plugin just check if there is a static page with a proper name? That's much more reliable. I think, the current implementation is a wrong implementation, which can't work reliably.
I even wonder why it works on your system. This shouldn't even work with mod_php. Maybe your static pages are named *.html so they're caught by a specific RewriteRule in your .htaccess before?

Hi!

Maybe that's the problem! Currently static pages are meant to end with .html, I believe the configuration also explicitly states that. Have you tried using .html as your permalink and how that changes things? I do think that you could be subject to other problems and edge scenarios where static pages do not properly work when they are not caught as a "real" page through rewrite rules that are applied internally with mandatory .html patterns...

As to why REDIRECT-Status is used, I did not implement it myself, which is the main problem why I can't do much more than rub my magic orb currently, because I don't have the time to investigate that specific scenario...

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...

Regards,
Garvin