Closed since it doesn't appear to be a bug, but rather missing functionality in PHP.

moved to feature request

it is in the responsibility of the application code
to check for If-Modified-Since conditions and to
send 304 Status codes,
as PHP itself can't know what the data you are 
going to produce looks like or whether it has
changed since the last request in advance
without executing your code

PS: whatever the CGI script you are refering to
does, i'm rather sure that it deals with that
itself, too 

(Changing back to 'Open' since you clearly misunderstood the request.)

> as PHP itself can't know what the data you are 
> going to produce looks like or whether it has
> changed since the last request in advance
> without executing your code

This is not about suppressing the execution of code. It's about PHP (mod_php) handling If-Modified-Since automatically in the same manner as CGI on Apache.

This is possible, too, because I posted a proof-of-concept patch to the list.

> PS: whatever the CGI script you are refering to
> does, i'm rather sure that it deals with that
> itself, too 

You're saying my 5 line /bin/sh CGI script somehow "deals" with If-Modified-Since headers? I think not...

What kind of logic do you suggest PHP should use to 
determine whether the output of your script has indeed been 
modified since the IMS date sent by the user agent?

Hint: we don't cache script output internally, so there is 
NO WAY for us to do that.

As for www.php.net not returning 304 for you -- tough. It 
works for us. Some Internet Explorer versions have the 
unfortunate tendency of mangling the IMS date (ie. the IMS 
date is not the same as the Last-Modified date the UA 
received).

Because we follow the RFC 2616 recommendation of checking 
for an exact match between the IMS date and our internal 
Last-Modified date, the IMS negotiation mechanism we have 
in place for www.php.net doesn't work on such user agents.

Please check your user agent behaviour before concluding 
that this is a bug in PHP.

> What kind of logic do you suggest PHP should use to 
> determine whether the output of your script has indeed been 
> modified since the IMS date sent by the user agent?

Easy - compare any Last-Modified header against any If-Modified-Since request header. Just like Apache does when running any CGI script (be it PHP, Perl, Python, sh, or whatever).

See the past discussion on the mailing list:

http://marc.theaimsgroup.com/?t=97544892600002&r=1&w=2
http://marc.theaimsgroup.com/?t=97551909500005&r=1&w=2

And specifically, the little patch I posted:

http://marc.theaimsgroup.com/?l=php-dev&m=97553565420685&w=2

Granted, the Apache-specific ap_parseHTTPdate() call needs to be replaced with a portable PHP equivalent, but the patch proves that is indeed possible, and quite easy to do.

Again, all I'm suggesting is making If-Modified-Since headers be handled automatically *in the same manner* as CGI scripts. *Nothing more.* I don't really see a valid reason why mod_php PHP scripts shouldn't get If-Modified-Since handling by default, when CGI PHP scripts do. It is inconsistent.

> As for www.php.net not returning 304 for you -- 

I have no clue what www.php.net is doing these days, and it's not relevant anyway.

> Please check your user agent behaviour before concluding 
> that this is a bug in PHP.

It is not and never was my "conclusion" that this is a bug in PHP. Notice the category is "feature/change request".

Well slap my ass and call me a bitch! I only realised your 
intent after I sent my previous comment.

Now that I understand your request, I can see that it is 
indeed implementable. However, my answer to the request 
remains the same.

Saving bandwidth is only a half of the intent of the IMS 
negotiation mechanism. The other half is saving the cost 
and latency of generating the response. This is why we want 
to keep the IMS negotiation in the application domain -- to 
enable PHP users to choose the actions they want to take 
based on the If-Modified-Since header.

On www.php.net, for example, we have a low-cost method of 
finding out the Last-Modified date without actually 
executing the whole script. This enables us save 
considerable CPU resources in the cases we send a 304 to 
the UA.

Implementing the kind of generalized mechanism for IMS that 
you are advocating would create the illusion among PHP 
users that this matter was "taken care of". This wouldn't 
help the bigger goal of getting users aware of the 
underlying mechanisms and how to use them.

I am in the process of writing this issue up in the PHP 
manual; that is my preferred fix. I've also scratched the 
surface of the complexities involved in this article: 
http://homepage.mac.com/marko/20020514.html

And now, I'll play the open/close ping pong again...