Technically, that's quite a problem. s9y relies on the serendipityBaseURL on quite a few plugins and instances, which is where the autodetect kicks in and modifies it accordingly, when autodetection is on. I know. My suggestion would be to leave serendipityBaseURL as is, but implement a second vari...

HTTPS handling of Serendipity is not optimal. To use both, HTTP and HTTPS, "Autodetect used HTTP-Host" has to be set. This causes "URL to blog" to change depending on the domain name or protocol. The first thing that should be optimized is the port. When calling Serendipity over ...

Hi, the pluginfreetag is not compatible with HTTPS connections and causes mixed content in the backend. In line 897 of the file seredenipty_event_freetag the following script tag is hardcoded: <script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascr...

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

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

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

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

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

If you change your configuration or installed plugins on a daily basis, you should use ETag, indeed. But normally style sheets shouldn't change too often, therefore ETag headers generate a huge overhead due to lots of useless HTTP requests. With a far future Expires, the browser doesn't issue any re...

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 this Array ( [startpage] => [uriargs] => about/ [view] => 404 [viewtype] => 404_4 ) 40...

I wouldn't use ETag if it is not absolutely necessary. This caching mechanism is more or less defective by design, produces unnecessary HTTP requests and doesn't work well with load balancing. Normally you should go well with an Expires header set to a date fare in the future (for style sheets at le...

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

@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 $this->error_404 = TRUE; 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 ...

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

Well, let's see if I find the time for this one day. I still don't consider it good programming, but I also don't want to start flaming. Making use of weak typing is okay in my opinion, but not initializing variables often results in errors which take very long to investigate or even in security hol...