Forum

Hiawatha version: 7.3
Operating System: FreeBSD 8.1

Hi,

I have Hiawatha running for a few weeks and is working great! Dokuwiki is successfully installed but there is only one obstacle that makes me bonkers. The first time When I visit my website there are no problems but when I refresh my browser cache I loose my css layout. Like this.

http://servertjes.xs4all.nl

Did I miss something?

Thanks in advance!

Yes, I did...

After reviewing my php.ini I found that session.save.path="tmp" was enabled. I disabled it and removed some mud from "tmp". Everything is working as expected.

Thanks anyway

Well, the website worked for a while but nope... the problem persist. I've checked my website with various browsers such as Opera 10, Firefox35 and Internet Explorer.

They all show the same behaviour as I have described in my first post. I found this link https://developer.mozilla.org/en/Incorrect_MIME_Type_for_CSS_Files which explains what it could be.

I have checked mimetypes.conf and the file seems ok. The only troublemaker could be dokuwiki itself but I am not sure about this because dokuwiki runs fine on apache.

...

If you look at the HTML source code of the dokuwiki, you'll see that the CSS is generated by a PHP script. If you request that script via your browser, one time you see CSS code, the other time you don't. This is clearly a badly written PHP script. And if it's working fine all the time in Apache, it's also clearly that Dokuwiki has been created for Apache only and with the 'official' standards in mind. Bad code if you ask me.

When I have the time, I'll install Dokuwiki myself and see what the problem is. Shouldn't be too hard

Thanks Hugo!

Really looking forward to it.

Looks like their caching system is bad. If you edit lib/exe/css.php and add a 'return false' directly after the 'global' statement in 'css_cacheok()', the problem is solved. Of course, disabling the cache is bad for performance, so I'll see if I can find the real problem. But at least for now, you'll have a styled webpage.

Found the bug. It's in 'http_conditionalRequest()' in the file 'inc/httputils.php'. At line 56, there is a statement 'header('HTTP/1.0 304 Not Modified');'. This is not allowed in a CGI script. If a CGI script wants to change the status code of a HTTP response, it should us the Status CGI header. It's clear that the Dokuwiki follow the Apache standards instead of the official standards. You can fix this bug by changing that line into 'header("Status: 304");'. You should consider reporting it to the Dokuwiki developers.

I just sent an email to andi@splitbrain.org to report the bug (I hate registering to report a bug) myself. After that, I did a simple grep on the code and learned that more of the same bug are present in the code:

# grep -r header * | grep "HTTP/"
doku.php:    header('HTTP/1.0 404 Not Found');
inc/auth.php:        header("HTTP/1.0 401 Unauthorized");
inc/httputils.php:                    header('HTTP/1.1 416 Requested Range Not Satisfiable');
inc/httputils.php:        header('HTTP/1.1 206 Partial Content');
inc/parser/code.php:        header("HTTP/1.0 404 Not Found");
lib/exe/fetch.php:      header("HTTP/1.0 412 Precondition Failed");
lib/exe/fetch.php:      header("HTTP/1.0 400 Bad Request");
lib/exe/fetch.php:      header("HTTP/1.0 401 Unauthorized");
lib/exe/fetch.php:    header("HTTP/1.0 404 Not Found");
lib/exe/fetch.php:    header("HTTP/1.0 500 Internal Server Error");
lib/exe/mediamanager.php:            header("HTTP/1.0 400 Bad Request");

These should also be changed in the same way: header("Status: <code>");

In the meanwhile you were doing some real bughunting... I've found a temporary workaround for my situation. Not the best solution but i installed tinyproxy on the client-side and the problem disappeared. This workaround is only for the client i am working on.

I changed the code you suggested and it works! Man, you did it!

None of us with common sense wants a bloated apache webserver and writing rules for modsecurity only serving Dokuwiki on a home brewed machine. We have Hiawatha for this...

Is it possible that this bug(s) is slowing down the performance of Hiawatha?

I can't think of any way how this bug would affect the performance of Hiawatha. At least not more than any other webserver.

Anyway. Thanks for sharing your time on this matter...