【実務・中級編】HTTP/1.1の条件付きリクエスト(If-Modified-Since, If-None-Match) – HTTPプロトコル・通信規格実践ガイド

無駄なパケットを削ぎ落とせ：HTTP/1.1の条件付きリクエストが支える「賢い」通信の極意

ネットワークの現場で「なぜかレスポンスが遅い」「帯域を圧迫している」という相談を受けると、私はまずブラウザのデベロッパーツールを開き、HTTPヘッダーを眺めることから始めます。

多くのエンジニアがHTTPを単なる「リクエストとレスポンスの運び屋」だと思っていますが、それは大きな誤解です。HTTPは、何万回、何億回と繰り返される通信の中で、いかに賢くデータをやり取りするかという「効率化の歴史」そのものなのです。

今回は、キャッシュ制御の要である「条件付きリクエスト（Conditional Requests）」について、現場の視点から掘り下げていきます。

—

なぜ「304 Not Modified」が美しいのか

Web APIを設計する際、全てのレスポンスを毎回フルサイズで返していては、サーバーのCPUも帯域も持ちません。そこで登場するのが、`If-Modified-Since` と `If-None-Match` です。

これらは、ブラウザ（クライアント）が「このデータ、昨日もらったものと同じですか？」とサーバーに問いかけるための仕組みです。サーバー側で「ああ、更新されていないね」と判断できれば、本文（Body）を空にして 304 Not Modified を返せます。

この「たった数バイトの304レスポンス」こそが、トラフィックを劇的に削減し、ユーザー体験を高速化させる魔法なのです。

—

2つの検証キー：タイムスタンプ vs ETag

条件付きリクエストには大きく分けて2つの判定基準があります。

1. If-Modified-Since（日付ベース）

サーバーが送信した `Last-Modified` ヘッダーの値を、クライアントが記憶しておき、次のリクエストで `If-Modified-Since` として送り返す方式です。

利点: 実装が容易。
欠点: 1秒未満の更新や、ファイルの内容が変わらずにタイムスタンプだけが変わるケースに弱い。

2. If-None-Match（ETagベース）

サーバーがコンテンツの内容をハッシュ化した `ETag` を付与し、クライアントが `If-None-Match` にそれを載せて確認する方式です。

利点: コンテンツの同一性を厳密に保証できる。現在のWeb API設計ではこちらが主流です。

—

実践：curlで挙動を追いかける

理論だけでは現場は動きません。まずは自分の手元で、この挙動を可視化してみましょう。

1. 初回リクエスト（レスポンスにETagが含まれることを確認）
curl -I https://api.example.com/data/resource

2. 2回目：If-None-Matchヘッダーを付けて問い合わせる
サーバーが「変わっていない」と判断すれば、HTTP 304 が返る
curl -I -H “If-None-Match: \”abcdef123456\”” https://api.example.com/data/resource

もし自作のWeb APIでこれを実装するなら、Python (FastAPI) では以下のように書けます。

from fastapi import FastAPI, Request, Response

app = FastAPI()

模擬的なリソースのETag
CURRENT_ETAG = “abcdef123456”

@app.get(“/data/resource”)
async def get_resource(request: Request):
# クライアントから送られてきたIf-None-Matchを取得
if_none_match = request.headers.get(“if-none-match”)

# ETagが一致すれば、304を返す（Bodyは不要）
if if_none_match == CURRENT_ETAG:
return Response(status_code=304)

# 変わっていれば、ETagを付けてデータを返す
return {“data”: “ここに重いコンテンツ”}, {“ETag”: CURRENT_ETAG}

—

インフラ運用者が知っておくべきデバッグの勘所

現場でよくあるトラブルは、「キャッシュが効いているはずなのに、なぜか毎回200 OKが返ってくる」というケースです。これを解決するためのチェックリストを授けます。

1. プロキシの介入: 前段のCDNやロードバランサーが、`If-None-Match` ヘッダーを無視していないか？（`Vary: If-None-Match` の設定漏れがないか）
2. 時刻のズレ: `If-Modified-Since` を使う場合、サーバーとクライアントの時計がズレていると、条件判定が正しく機能しません。
3. ETagの生成ロジック: ETagを動的に生成する場合、ファイルの内容は同じなのにETagが変わってしまうような「揺らぎ」が混入していないか確認してください。

最後に：エンジニアとしての矜持

「動くコード」を書くのはスタートラインに過ぎません。ネットワークの先にあるサーバーの負荷を想像し、無駄なパケットを流さないための工夫を凝らす。それこそが、プロのインフラエンジニアであり、アーキテクトの仕事です。

条件付きリクエストは、ただの仕様書の一節ではありません。それは、私たちが作り上げるシステムが、どれだけエレガントに世界と通信できるかを示す「品格」のようなものです。

次のリリースの際は、ぜひデベロッパーツールを開いて、304のレスポンスコードが美しく並んでいるかを確認してみてください。その時、あなたのネットワークに対する視界は、少しだけクリアになっているはずです。