Forum

New user of Hiawatha here. Very pleased in general - thank you very much for your work.

I'm hosting two Symphony CMS sites using the URL toolkit supplied which works fine. However, with one of them, I'm experiencing a delay of about 30 seconds after the actual content has loaded until the page seems to finish actually loading. The page-loading spinner in the browser tab keeps spinning until Firebug finally reports 'onload' has completed.

On some admin pages, this means the Javascript doesn't execute for 30 seconds, even though all items load as 200 OK.

Do you have any idea why this might be, or suggestions of what to look for? Thanks.

Hiawatha version: 7.8.2
Operating System: Debian 6

What does the error logfile say? Or the system.log file?

I'd checked the logs earlier, but I'd changed the user that hiawatha runs as, meaning that the log files (which still belonged to 'nobody') weren't being updated.

After correcting this, the system.log shows the following line after about 7 seconds into the page load when using Chromium (but not when using Firefox!):

Timeout while waiting for request

Then about 23 seconds later (making about 30 seconds), the page stops loading, seemingly completing as far as the visitor is concerned.

The actual HTML is loaded and displays straight away. You can test at http://dommett.doliver.co.uk/ (I've removed all CSS and images in hopes of simplifying/narrowing down).

The site's and hiawatha's main error.log files don't show anything.

The delay also occurs when accessing the backend admin of Symphony CMS, but the 'Timeout while waiting for request' is not logged in system.log as it is when accessing the frontend site page, even when using Chromium.

It's a bug in Symphony CMS. The size of your content is 7753 bytes. The HTTP header Content-Length is indeed set to 7753 by Symphony CMS. That's correct.

However, if your browser tells the server it supports gzip content encoding (via the Accept-Encoding: gzip HTTP header), Symphony gzips the data (or lets PHP do it), but still sets the Content-Length to 7753. This is incorrect because the content is smaller than 7753 bytes, because of the compression.

I've done a quick search in Symphony's code and didn't find any gzip routine. So, my guess is that PHP on your machine is responsible for the gzipping. Look for zlib.* settings in your php.ini.

The sollution is to remove the line from Symphony that prints the Content-Length or to disable PHP's gzipping. Please, let me know if that works.

Many thanks Hugo; removing that line fixes it.

Sorry for wasting your time with it here - it turns out this is an issue that's been fixed [github.com] (by removing the line!) in Symphony in recent versions. I should have made sure I was using the most recent version first.

Thanks again.

You could take a look at how I deal with this issue in the Banshee PHP framework [www.banshee-php.org]. The specific code can be found at the end of 'libraries/output.php'.

Thanks Hugo. I'll probably suggest that approach in case they want to take it, too.