They rely on dates - they have to since they need to work out if one date is after another.

Lexicographical do not work with inconsistent (but still valid) date formats: eg 9/08/2011 sorts after 10/08/2011 if sorting lexicographical.

In actual case, most server software probably relies on the date format being in W3C format. If the parsing fails (which it would in the case of 9/08/2011) then the server ignores the date instead of attempting a lexicographical sort.

(I've never written a web server, but have written both client and server side software that works like this.)

Why do they need to work out whether the date they get back is before or after the one on the server? If it changes at all, presumably the browser has the wrong version so they should send down a 200 response with the correct version. If all the server needs to do is check whether the date has changed, and all the major browsers just return back whatever they got sent, why bother with parsing dates at all?

The server needs to parse the date sent by the browser to compare it against the date the file was last modified (which is retrieved from the operating system, probably as UNIX time).

As mentioned by sirclueless, that's not necessarily the case. Since last-modified is sent by the server and simply replayed by the browser, the server can simply make sure the two strings are identical.

Browser: "I want index.html"

Server: "index.html was last modified on 'Pungenday, the 9th day of Bureaucracy, 3177 at 14:53'. Here are its contents."

[Time passes]

Browser: "I want index.html. I have a cached copy that you said was last modified on 'Pungenday, the 9th day of Bureaucracy, 3177 at 14:53'. Is there a newer version?"

Server: "Nope, your Last-Modified is the same thing I would tell you if I sent it right now."

Note that because the server sets the contents of last-modified for the browser, it can simply check if it's identical to what it would currently send as the last-modified header for that request.

> Server: "Nope, your Last-Modified is the same thing I would tell you if I sent it right now."

To get that information the web browser must ask the file system when the file was last modified and compare it. It is recommended to do a "submitted time is less than time now" on the file (which means the date must be parsed), by the RFC (2616 14.25); however, some people do use inequality operators as you suggest.

In this case, it would be the web server that is not following the RFC (sending arbitrary Last-Modified header), not the browser.

I've written server-side software that generated a meaningful Last-Modified header (it's very useful information) and also did an exact comparison instead of a time-based one. I did the exact comparison because I realized that it was very hard to guarantee correct results otherwise (correct being that I never 304'd a request unless the client already had the exact version of the page that I would have served). The problem is that there are a number of situations in a web server that can cause page modification time to go backwards. For example, several ways of doing rollback to previous versions of content will also roll back the page time, such as simply renaming an old version of the file to the current name.

To do correct time-based If-Not-Modified comparisons you really need to guarantee that all changes moves your Last-Modified time forward, no matter what. My view is that this is surprisingly hard once you start looking at corner cases. Certainly it's not something that a web server that serves general file content can ever guarantee; there are too many ways to shuffle files around behind the web server's back.