#HTTP Status Code Lab
代表的なステータスコードを固定応答で返します。curl -i でステータスラインとヘッダーを確認できます。各URLには X-Demo ヘッダーを付けています。
$ curl -i https://web-protocol-lab.com/status/200
200 OK
正常応答。ボディとヘッダーの基本形。
/status/200
確認: Status line, Content-Type
204 No Content
ボディなしの成功応答。Content-Length の扱いに注目。
/status/204
確認: ボディ無し, Content-Length
301 Moved Permanently
恒久リダイレクト。キャッシュ可能で、ブラウザが保存・再利用する場合がある。
/status/301
確認: Location, キャッシュ挙動
302 Found
一時リダイレクト。curl は -L を付けない限り追跡しない。
/status/302
確認: Location, curl -L の挙動
304 Not Modified
本エンドポイントは形を観測する固定応答。本来は条件付きリクエストに対する「変更なし」を示し、ボディは返さない。
/status/304
確認: ボディ無し, ETag との組合せ
400 Bad Request
構文不正なリクエストへの応答。
/status/400
確認: Status line
401 Unauthorized
認証が必要。WWW-Authenticate ヘッダーを返す。
/status/401
確認: WWW-Authenticate
403 Forbidden
サーバーがリクエストを理解したが実行を拒否。認証済みでも返る場合がある。
/status/403
確認: 401 との違い
404 Not Found
対象リソースを見つけられない、または存在を明かしたくない場合の応答。
/status/404
確認: Status line
405 Method Not Allowed
許可されないメソッド。Allow ヘッダーを返す。
/status/405
確認: Allow
408 Request Timeout
サーバー側のリクエスト受信タイムアウト。
/status/408
確認: Connection の扱い
409 Conflict
リソースの状態と競合。PUT の競合などで使われる。
/status/409
確認: Status line
410 Gone
対象へのアクセスが意図的に失われ、その状態が永続的と見込まれる場合の応答。
/status/410
確認: 404 との違い
429 Too Many Requests
レート制限超過。Retry-After ヘッダーを返す。
/status/429
確認: Retry-After
500 Internal Server Error
サーバー内部エラー。
/status/500
確認: Status line
502 Bad Gateway
上流サーバーからの不正応答。プロキシ環境の定番エラー。
/status/502
確認: プロキシ経由での見え方
503 Service Unavailable
一時的に処理不能。Retry-After ヘッダーを返す。
/status/503
確認: Retry-After
観測ポイント
| curl | curl -i でステータスライン・ヘッダーを確認。リダイレクトは -L の有無で挙動比較。 |
|---|---|
| DevTools | Network タブで Status 列と Response Headers を確認。301 はディスクキャッシュから返る場合がある((from disk cache) 表示)。 |
| Proxy | プロキシ経由時に Via や X-Forwarded-For が付与されるか、5xx がプロキシ自身のエラーページに差し替えられないかを確認。 |
| tcpdump / Wireshark | 平文HTTPなら http フィルタでステータスライン確認。HTTPS は TLS 復号設定(SSLKEYLOGFILE)が必要。 |
| TLS inspection | 直接接続と装置経由のレスポンスを比較し、ステータスコードやヘッダーに差がないか確認。 |
#Cache Control Lab
各エンドポイントは異なる Cache-Control ディレクティブを返します。ブラウザのリロード / スーパーリロード、curl の条件付きリクエストで挙動の違いを観測してください。
no-store
HTTPキャッシュに応答を保存させない。プライベート・共有キャッシュの両方が対象。
/cache/no-store
確認: HTTPキャッシュから再利用しない
no-cache
基本仕様では、保存はできますが、再利用の前にオリジンへの再検証が必要です。
/cache/no-cache
確認: ETag + 再検証リクエスト
max-age=60
保存された場合、60秒間はfreshとして再利用できる。リロード操作や実装によっては期間内でも通信が発生し得る。
/cache/max-age-60
確認: 60秒以内の再訪問
public, max-age=3600
共有キャッシュ(プロキシ/CDN)にも保存可能。
/cache/public-max-age
確認: プロキシ経由の Age ヘッダー
private, max-age=60
ブラウザなどのプライベートキャッシュには保存可能。共有キャッシュには保存させない。
/cache/private
確認: 共有キャッシュでの非保存
max-age=0, must-revalidate
基本仕様では、staleな応答を再利用する前に、オリジンへの再検証が必要です。
/cache/must-revalidate
確認: 再検証の強制
stale-while-revalidate
指定期間内であれば、stale応答を返しつつ非同期に再検証することをキャッシュに許可する。
/cache/stale-while-revalidate
確認: stale 応答と非同期再検証
ETag / If-None-Match
静的ファイル配信で自然な ETag と 304 を検証。
/cache/static/etag-demo.txt
確認: ETag → 304 Not Modified
Last-Modified / If-Modified-Since
更新日時ベースの条件付きリクエストと 304 を検証。
/cache/static/last-modified-demo.txt
確認: Last-Modified → 304
ETag → 304 を体験する
curl# 1回目: 200 OK と ETag を受け取る $ curl -i https://web-protocol-lab.com/cache/static/etag-demo.txt # 2回目: 受け取った ETag を If-None-Match に入れて送る → 304 $ curl -i -H 'If-None-Match: "<上で受け取ったETag値>"' \ https://web-protocol-lab.com/cache/static/etag-demo.txt応答例 (ETag値はファイルと環境で変わる)
HTTP/1.1 304 Not Modified
ETag: "<実際に受け取った値>"
Cache-Control: public, max-age=0, must-revalidate
Last-Modified → 304 を体験する
curl# 1回目: Last-Modified を受け取る $ curl -i https://web-protocol-lab.com/cache/static/last-modified-demo.txt # 2回目: その日時を If-Modified-Since に入れて送る → 304 $ curl -i -H 'If-Modified-Since: <上で受け取ったLast-Modified値>' \ https://web-protocol-lab.com/cache/static/last-modified-demo.txt
この環境の設定:
if_modified_since exact; を指定しています。送信した日時が更新日時と一致すれば 304、異なれば 200 になります。
観測ポイント
| curl | 条件付きヘッダー(If-None-Match / If-Modified-Since)有無での 200 / 304 の変化。304 のときボディが無いこと。 |
|---|---|
| DevTools | Network タブの Size 列: (from memory cache) / (from disk cache) / 304 の違い。リロードとURL再入力で挙動が変わる。 |
| Proxy | 共有キャッシュが Age ヘッダーを付けるか、private をキャッシュしないか、Vary をキーに含めるか。 |
| tcpdump / Wireshark | 応答がキャッシュに保存され、freshなまま再利用された場合は、ネットワークへのリクエスト自体が発生しないことを確認。 |
| TLS inspection | インスペクション装置自身がキャッシュを持つ場合、オリジンに到達せず応答が返るケースを diff で確認。 |
#Header Lab
セキュリティヘッダー、CORS、Content-Type、圧縮、リダイレクトチェーンの挙動を確認します。
Security Headers
HSTS、X-Content-Type-Options、Referrer-Policy、CSPを返す。
/headers/security
確認: Strict-Transport-Security ほか
CORS
Access-Control-Allow-* 一式を返す。プリフライトの観測に。
/headers/cors
確認: Access-Control-Allow-Origin
Content-Type
application/json を返す。MIMEタイプとブラウザ表示の関係。
/headers/content-type
確認: Content-Type とレンダリング
Compression
Accept-Encoding に応じて gzip 圧縮して返す。
/headers/compression
確認: Content-Encoding: gzip, Vary
Redirect Chain
302 → 301 → 200 の多段リダイレクトを観測。
/headers/redirect
確認: curl -L -v でのチェーン追跡
基本仕様では、HSTS (Strict-Transport-Security) はHTTPSで受信したときに処理されます。このURLではヘッダーを確認できます。HTTPからHTTPSへの切り替えは、ブラウザの状態や設定も含めて確認してください。
# 圧縮: Accept-Encoding の有無で Content-Encoding が変わる $ curl -i https://web-protocol-lab.com/headers/compression $ curl -i --compressed https://web-protocol-lab.com/headers/compression # リダイレクトチェーンを追跡 $ curl -iL https://web-protocol-lab.com/headers/redirect
#Protocol Guides
主要プロトコルの流れと観測ポイントをまとめています。HTTPステータス、キャッシュ、ヘッダー以外は解説が中心で、実行環境を提供していないページがあります。
HTTP/1.1
テキスト形式の開始行・ヘッダー、Keep-Alive、応答順序とHead-of-line blocking。
RFC 9112
HTTP/2
バイナリフレーミング、多重化、HPACK、ALPNネゴシエーション。
RFC 9113
WebSocket
HTTP Upgrade、101 Switching Protocols、双方向フレーム、プロキシ通過性。
RFC 6455
gRPC
HTTP/2上のRPC、Protocol Buffers、trailers、grpcurl での観測。
gRPC over HTTP/2
HTTP/3
QUIC上のHTTP、QPACK、Alt-Svc による発見、UDP 443。
RFC 9114
QUIC
UDP上のトランスポート、TLS 1.3統合、connection migration、0-RTT。
RFC 9000
TLS
1.2 / 1.3 のハンドシェイク、SNI・ALPN の見え方、証明書チェーンとインスペクション検証。
RFC 9846
DTLS
UDP上のTLS。cookie交換による送信元検証、WebRTC・VPNでの利用。
RFC 9147
WebRTC
SDP交換、ICE / STUN / TURN による NAT 越え、DTLS-SRTP。webrtc-internals での観測。
RFC 8825
RTP / RTCP / SRTP
メディア転送のヘッダー構造、品質レポート、暗号化範囲。Wiresharkでのロス・ジッタ解析。
RFC 3550 / 3711
MQTT
pub/sub、QoS 0/1/2、retained・LWT。mosquitto CLI と Wireshark での観測。
OASIS MQTT 5.0