ID: 17098
Comment by: davisneilp at mindspring dot com
Reported By: pmoor at netpeople dot ch
Status: Closed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
All,
IIS responds the same way. I think this is more a case of reading the
"manual" (w3c http spec). The reason apache "worked" before was that
there was probably a bug in apache that sent the content when it was
supposed to send a 304 only.
When you do a browser refresh, you are sending a "If-None-Match:
[etag]" header, if an etag was originally sent with the content, which
it probably wasn't. You also send a "If-modified-since: [GMT HTTP
DATE]" with a refresh. If the file date hasn't changed, and is within
the expires time originally sent (usually a default is sent), the page
won't "actually" refresh.
This problem lies with the improper use (or lack thereof) of cache
control headers. Try sending an etag with all of your content, and no
expires header. For production make sure you send an Expires header: )
This Etag will change, if you set it based on the content, and inspire
IE to refresh the page. It seems to go in http 1.0, then http 1.1
order, with IE, so if you want it to really work, make sure you aren't
sending an expires header. Send an Etag only from your development
server.
Clearing your cache works because it forces the server to send the
content. It doesn't have the option of sending a 304 if you don't send
an If-none-match, or If-modified-since headers, neither of which is
possible if you have deleted the data and content from your box: )
An often misunderstood aspect of intentionally sending 304s is that
Apache is actually "dumb" in this respect. If you are not using php's
output buffer, it is impossible to stop the content from going out. You
should really use a callback function and set it in ob_start("function
name"). When sending a 304 return null out of your function and the 304
will be sent, but not the content. Apache happily sends out the content
with your 304 header otherwise.
Using a call back function gives you a lot more control of the flow of
bytes out of your server.
Not doing this wastes bandwidth and server connection resources,
especially considering that connection taken while the 14.4 modem user
downloads your 40k page. If you capture the output and stop it, you
only send the 304 and the connection is freed up. It is a lot faster to
send, say, a 250 byte header than the entire page. This frees up the
connection resource much faster and enables your server to scale more
efficiently.
It would be nice if the php team made php do this 304 header/output
stuff automatically. I can help if you need it: ) it will save your
users some head scratching if you add this feature. It took me an hour
or two to figure out what was really happening and coded it.
wget -S is your friend, use it!
l8,
neil
Previous Comments:
------------------------------------------------------------------------
[2003-01-09 14:45:38] daniel dot eckl at gmx dot de
I tried this and tested it with Horde's IMP which heavily needs correct
caching behavior. So far it seems to behave very smoothly. I'm
impressed of this idea.
I took some time but couldn't think of any drawbacks caused by this.
Because the unsetting is only internal, there should be no problems
with search spiders etc...
Any other opinions?
Greets,
Daniel
------------------------------------------------------------------------
[2003-01-03 13:44:12] pmichaud at pobox dot com
As another possible temporary workaround, I tried adding the directive
RequestHeader unset If-Modified-Since
into my Apache configuration when processing PHP scripts. This removes
the If-Modified-Since header entirely, causing Apache to always return
a 200 response. The resulting configuration looks like:
<Files *.php>
SetOutputFilter PHP
SetInputFilter PHP
LimitRequestBody 524288
RequestHeader unset If-Modified-Since
</Files>
Anyone know of a reason why this might be bad or otherwise won't work?
Pm
------------------------------------------------------------------------
[2002-12-29 15:56:05] [EMAIL PROTECTED]
Try a NON stable snapshot, it's fixed in CVS>
Derick
------------------------------------------------------------------------
[2002-12-29 15:51:59] dk at webcluster dot at
Isn't fixed in php4-STABLE-200212290030
Daniel [datenPUNK] Khan
------------------------------------------------------------------------
[2002-12-27 14:13:19] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17098
--
Edit this bug report at http://bugs.php.net/?id=17098&edit=1
