Bug #8017 Updated: PHP ignores "If-Modified-Since" headers

ID: 8017 Updated by: markonen@php.net Reported By: jr-php@quo.to -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.1 New Comment: 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... Previous Comments: ------------------------------------------------------------------------ [2002-06-18 11:06:39] jr-php@quo.to > 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". ------------------------------------------------------------------------ [2002-06-18 04:12:40] markonen@php.net 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. ------------------------------------------------------------------------ [2002-06-17 14:00:12] jr-php@quo.to (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... ------------------------------------------------------------------------ [2002-06-17 13:20:48] hholzgra@php.net 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 ------------------------------------------------------------------------ [2000-11-29 11:57:24] stas@php.net moved to feature request ------------------------------------------------------------------------ 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/8017 -- Edit this bug report at http://bugs.php.net/?id=8017&edit=1