Apparently most (or all) client implementations hand back the Last-Modified: date that they received from the origin server, rather than some other arbitrary date (such as the date that the client actually received the response). We seemed to be in agreement that this was the right thing to do; that is, that it would be a bad idea for a client to use anything but a Last-Modified: date in an If-Modified-Since: header.
Apparently, at least one browser (Netscape?) parses and internalizes the Last-Modified: date, then reconstitutes it in HTTP-Date form when generating an If-Modified-Since: header. This should be harmless (unless a date encoding is used that drops the century, in which case things could go wrong at the turn of the millenium).
If the server receives an If-Modified-Since: containing a date that is later than the actual modification time of the resource, should it return 304 Not Modified or should it treat this as a validation failure? For example, if the I-M-S header says "Tue Jan 30 00:59:57 1996" but the resource's actual modification time is Jan 29 00:00:00 1996, should the server be paranoid and return the full resource, or should it blithely assume that the client had a good reason for constructing its own I-M-S date?
"Franz J. Hauck" <fjh@cs.vu.nl> in <3121BC92.3EC9@cs.vu.nl> claims example for which this doesn't work.