May 25, 2006

• .htm and .html *shouldn't* matter. Can you paste in the js here?
• Why, yessssssss:
• The js is probably correct, you should be able to verify that by looking at what the last-modified timestamp for that page is in your browser. If that's the case, the server is sending what it thinks is the correct last-modified date, but it is not what you expect. You can do an "ls" in the filesystem to check what the real modified date of the page is. Maybe some process is touching those pages unbeknownst to you.
• D'oh! What's "ls" ?
• Give us URLs for two of the pages, fish, one that works as it should and one that doesn't. Betcha the ones that give todays date are being partially created on the fly, as un- hinted.
• "ls" is just a listing of directory contents, which should give you filename, size and date last modified. I agree with un- that something else is "modifying" the pages.
• If only Bill Clinton read Mofi he'd finally know what the definition of "is" is.
• D'oh! What's "ls" Ha ha ... sometimes I think that there is only Unix.
• *greps un-*
• what's the web server? Maybe it's not getting the data from the .htm pages for some reason... See if this is a known issue.
• Thanks all, I will meddle some more and hope that this helps.
• another possibility: compare the http header for a file that works versus a file that doesn't. afaik, document.lastModified looks at the header for the information. maybe the pages that work have been edited with an app that will record this information (e.g. dreamweaver) and the pages that don't work have been edited with an app that doesn't record the information (a text editor)? some sort of fallback is giving the current date because the last modified isn't available.
• Try to run your pages (one that works and one that doesn't) at http://www.delorie.com/web/headers.html and see what it comes back with. You will have to create a file called delorie.html on your website for the tool to believe you're the webmaster of the site in question (to prevent people from scanning websites not their own). You'll hopefully see the Last Modified headers and figure it out from there. Perhaps the pages that don't work get sent out without a last modified header, which would apparently get Internet Explorer to spit out today's date (netscape/opera should see january 1st, 1970). Or perhaps the header is there, but because of dynamic content gets set to today's date? Have fun troubleshooting :)
• Thanks for that site, splice. I ran two pages through the header check, and the non-working one (current day's date) has "Pragma: no-cache" in the results which I'm guessing must be a clue. Both pages have been edited with Dreamweaver, both use the same template, they have identical header content (except for the title field), and when I look at the remote files via Dreamweaver, the file dates are correct.
• Another sniffling plea for help: is there something in this bit of JavaScript mumbo-jumbo that might be preventing the previously quoted "last modified" JavaScript from showing a date other than today's? Thank you, geekish monkeys.
• It doesn't look like your argle bargle code would fudge up the modified date to me, but I ain't no js expert. Just to be clear, when you did the delorie test recommended by splice, did the Last-Modified header show correctly for the problem page? It is possible that on your server .htm are configured to be served differently than .html, so did you try renaming a problem page from .htm to .html?
• The significance of whether the HTTP Last-Modified header is correct on the problem pages is that it will basically tell us if the problem is a server configuration error or on the client side. If the server is sending the correct date in the header, then we know the problem is almost assuredly on the client side. But if the header has the wrong date, then the problem has to do with the server's configuration. So far, I don't see any problem with the javascript, so I'm betting on some server configuration problem.