Nope, this is not another question about this bug....it's a workaround!

I ran headlong into this bug today after moving my mail setup from a
RH 7.2 server to a RH 8.0 server.  I went searching and noticed in the
mailing list archives that I wasn't alone.

I found out that Apache is declaring the PHP pages unchanged - it
actually checks the PHP file dates instead of *running* them to get
their dynamic content.  So, it immediately returns a "304 Not
Modified" instead of actually running the PHP script to get its
output.

The behavior actually seems to depend somewhat on your browser.  IE
5.5 worked perfectly for me, but Opera 7 was having fits with the
refreshes.  This isn't too surprising since IE seems to ignore many of
the standard protocol defs anyway....

It seems that the Apache group and the PHP group are playing the blame
game - each one thinks it's the other's bug, and it's not getting
fixed in either place.  The problem has been known for months.  BUT, I
managed to find a workaround in one of the PHP groups, and it seems to
work.

You need to add a directive to the Apache configuration so that it
strips the If-Modified-Since headers off of the incoming request. 
With this header stripped, Apache can't do a date compare, so it has
to resend the page each time.  Your Apache-PHP config should look
something like this when you're done:

    <Files *.php>
        SetOutputFilter PHP
        SetInputFilter PHP
        LimitRequestBody 524288
        RequestHeader unset If-Modified-Since
    </Files>

Anyway, I hope this solves some headaches for some of you.

roger





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
--
squirrelmail-users mailing list
List Address: [EMAIL PROTECTED]
List Archives:  http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users

Reply via email to