persistent connectionsの話はよく聞くのですが、私はLast-Modifiedフィールド、(すなわち、最終更新日時)の方が気になります。RFC 2616には、

HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.

とあります。ここが"SHOULD"になっている点は、persistent connectionsの話と同じですね。

RFCに書かれているだけあって、ほぼ全てのHTTPホストでは、デフォルトで、ファイルシステムのタイムスタンプを渡してきます。ですから、静的なコンテンツの場合、この仕組みは（半ば自動的に）うまく動いています。

一方で、ウェブサイトが動的なコンテンツの場合、言い換えると、ウェブ開発者がHTTPヘッダを手書きしている場合、Last-Modifiedは無視される傾向にあります。むしろ、Last-Modifiedをきちんと送ってくるケースは非常に稀です。If-Modified-Sinceは3秒前でもyesです。

検索サービスを始め、動的コンテンツにはタイムスタンプが全く無価値なものもあります。しかし、wikiやblogのように半静的コンテンツでは、最終更新日時がきちんと意味を持つものもあります。例えば、私のこの日記は私が最後に投稿した時刻が、万人の認めるところ、最終更新日時であるべきでしょう。しかし、日記の中身やRSSの"dc:date"には、きちんと日時が明記されているのにもかかわらず、その通信手段であるHTTPのヘッダにはLast-Modifiedがありません。そして、これは何もスラッシュドットに限ったことではなく、大多数のcgiはLast-Modifiedを返さないのです。

Last-Modifiedは、しばしば、キャッシュコントロールという観点で語られます。それは、裏を返せば、クライアントのキャッシュをサーバー側が、別の方法で上手くコントロールできるなら、Last-Modifiedは特に指定しなくてもいい、という考え方です。通常、UAはLast-Modifiedを「キャッシュを使うか、取りに行くか」の判断以外には使わないので、これは非の打ち所のない正論でもあります。そして、その正論にあえて反論をねじ込むなら、「最終更新日時を知っているのに、Last-Modifiedを指定していない、なら、それはRFC 2616に違反している」となります。

私は"Last-Modified"を仕様通り「可能な限り」忠実に指定して欲しいと思いますが、これは少々厚かましい意見である、とも思っています。広告、クローラー、ミラーリング、（転送量ではなく、CPUの）負荷などの様々な事情を考慮すると、サービス側にとってあまりメリットのある話ではないかもしれません。しかし、Last-Modifiedはあくまで最終更新日時で、キャッシュのことは一側面に過ぎません。別の使い道はいくらも考えられますし、そこには未開のサービスが眠っているように思えます。

余談ですが、２ちゃんねるのread.cgiはスレッドのLast-Modifiedを返していました。つまり、動的コンテンツがLast-Modifiedを返す稀有な例の一つでした。これは閉鎖騒動の際に、転送量を減らすギミックとして導入されたものですが、現在は違います。ちなみに、２ちゃんねるのdatファイルは、きちんとLast-Modifiedを返しますが、それはここで言う（動的に生成されても）静的なコンテンツだからです。