why do so many major php sites not send last modified headers

[jamie]

just wondered by so many major players don't bother sending Last-Modified headers with their pages. this includes zend, devshed, phpfreaks... in fact the only one i could find was php.net

doesn't this waste bandwidth by preventing any browsers from caching the pages?

or do they have to ensure that the browser downloads the newest version of the page on every visit because of advertising?

as a newbie it has got me very confused. i am in the process of transforming our static site into a dynamic one and am going to GREAT lengths to make sure the correct last modified headers are returned (this includes suplementary querying of the db to get the latest db timestamp and comparing filemtimes).

but, is this all a waste of time? what do you established programmers do?

cheers

[vincevincevince]

last modified is useful for search engines and for slow dial-up users. however, i find that it's a whole pile more trouble that it's worth. it's an extra database query per page (at least), and reqires you to constantly work out what the last modified date is. if the browser has got mixed up with dates, or the sys-clock is wrong, then some users won't be able to see your updates - many sites pretty much update constantly. most dynamic php content is text based - it's fast to load anyway - and image headers can be sent straight from apache.

[jamie]

that's a really interesting standpoint vince - cheers.

much of our site will be generated from included files - without db queries - and will not change much, so for those pages it sounds sensible to implement.

i always thought it was of vital importance for search engines (well GG recommended it). however, based on what you said i might end up leaving it off the pages with db queries. i am caching the html output anyway, so page delivery is fast.... hmmmmmm. look forward to reading some other opinions on this.

cheers

[dingman]

I've got one unimportant, light-weight site that I could easily set up last-modified headers for. Since it is unimportant and light-weight, I haven't bothered.

I've got another where it would be marginally useful, but the work involved would be phenomenal, and probably involve more processing on the server to figure out what last-modified date to use than it does to generate the pages. I'd also have to store a whole bunch of timestamp data in the back-end database that I have no other need for. If I started serving images from a database table, I'd almost certainly keep the data there, because the bandwidth savings and loading speed improvement would be worth the effort.

[jamie]

thanks for replying dingman

i think i've got it more or less sorted in my head now...

* for pages with includes only, it is easy to return last modified headers

* for pages with only one db query, caching the query result and returning a timestamp as the last modified is a viable option (and the performance doesn't take too much of a hit either).

* but for pages with multiple db queries which are used to display different sections of the page, i shan't bother. the newest version of the page will be downloaded at all times (isn't that the theory behind dynamic anyway ;-)

many thanks for your input, this has been a breakthrough in php logic for me.