[1] HTTP においてメソッドや要求が安全safeであるとは、 副作用が無い (少なくても利用者は求めていない) ことを表します。

仕様書

定義

[8] 要求メソッドは、その意味が読み取り専用と定義されていれば、 「安全safe」です。安全なメソッドでは、 クライアントは起源鯖が対象資源の状態を変化させることを要求も期待もしませんし、 普通に安全なメソッドを使っても、起源鯖で有害な事象やおかしなことは起こらないと期待されます。 >>6

[9] 実装が >>8 の条件を満たしている保証はなく、何かを変化させたり、 副作用を起こしたりすることはあり得ます。しかし、それはクライアントが要求したことではなく、 クライアントが責任を持つものではない、ということが重要とされています。 >>6

[10] 例えばほとんどの鯖はアクセスログにすべての要求を記録しています。 それによって鯖のストレージが満杯になってクラッシュする可能性があっても、 安全かどうかには影響しません。また、広告の取得であれば、 広告主への課金という副作用を持つかもしれませんが、やはり安全性とは関係ありません。 >>6

[11] ここでの「安全」は、セキュリティーとは関係ありません。

処理モデル

[13] 安全と非安全の区別は、無害な形で自動的な取得 (ボット) やキャッシュ処理 (先読み) を実行できるようにするためのものです。 >>6

[14] 利用者エージェントは、信頼できないかもしれない内容の処理時に安全でないメソッドの自動利用を制限することもできます。 >>6

[15] 利用者エージェントは、可能な操作を提示する時に安全か非安全かを明確に区別して、 非安全な操作を実行する前に利用者が気付けるようにするべきです >>6。

[16] 実効要求URLの一部が動作を表す場合、例えば page?do=delete のような URL の場合、資源の所有者は、安全なメソッドの時はその動作を無効にするか、 認めないようにしなければなりません >>6。

[19] キャッシュが非安全メソッドに対する応答を受信したら、 次のようにしなければなりません >>18。

  1. [20] 状態符号が誤りでない (2xx か 3xx) なら、
    1. [21] 非安全な要求メソッドなら、実効要求URLについて、非妥当化します。
    2. [22] 非安全な要求メソッドか、安全かどうかわからない要求メソッドなら、 Location: と Content-Location: の URL (あれば) について、
      1. [23] host が実効要求URLと同じなら、非妥当化します。

安全なメソッドの一覧

[7] 次の要求メソッドは、安全です。

[12] RFC 2616 までは GET と HEAD のみ安全とされていましたが、 RFC 7231 で OPTIONS と TRACE も追加されました。

[4] 要求メソッドを IANA に登録する際に、安全か否かも記載することになっています >>3。

Safe: ヘッダー

[25] Safe: ヘッダーは、 要求を繰り返しても安全であるか否かを示します >>24。

意味

[37] Safe: ヘッダーは、要求を反復しても安全かどうかを示します。

[32] ある要求が以前の要求の反復であるとは、両要求が次の条件をすべて満たすことをいいます >>24。

  • [33] 同じ利用者エージェントが発行したものである
  • [34] 同じ資源に適用される
  • [35] 同じ要求メソッドである
  • [36] 要求本体をどちらも有しないか、または内容符号化と転送符号化を復号するとバイト列として同じである

構文

[38] Safe: ヘッダーの値は、字句です。 大文字・小文字不区別です。

  1. 字句

[46] 現在次の値が定義されています。

  • yes
  • no
  • if-user-awake

[48] RFC 2310 では値として yes と no を規定しています。yes は安全、 no は非安全を表します。

[47] HTCPCP は if- を条件付きで安全であることを表すよう拡張しています。 具体的な値として、 if-user-awake を規定してます。 >>45

4月1日に公開された RFC でもあり、意味は明確には定義されていません。[49] RFC 2310 では値は2つだけで、拡張可能とはされていません。 HTCPCP が >>47 の通り拡張しており、それを含めると値は字句となります。 RFC 2310 でも HTCPCP でも ABNF 構文より定義済みの値および接頭辞 if- は大文字・小文字不区別となっていますが、 将来の拡張も不区別とは明記していません (おそらく意図は不区別ですが)。 どちらの RFC も if- で始まらない拡張の値は認めていません。

文脈

[50] 任意の応答で利用できると思われますが、不明です。 要求では利用できないと思われます。

[51] 実際に利用されている例があるかは不明です。

処理

[39] 応答に Safe: ヘッダーがなければ、 GET や HEAD の場合を除き、 非安全とみなさなければなりません >>24。

[40] 利用者エージェントは GET や HEAD の時 Safe: ヘッダーを無視するべきです >>24。

[41] RFC 7230 で安全なメソッドが増えているので (>>12)、 >>39 と >>40 もそのように読み替えるべきと思われます。

[26] 利用者エージェントは要求の反復が安全なら、 利用者に確認せずに自動的に反復して構いません >>24。

[27] 例えば次のような場合に利用者エージェントは POST 要求を繰り返す必要があります >>24。

  • [28] 中間器の誤りで失敗した場合
  • [29] POST 結果の表示中に利用者が再読み込みした場合
  • [30] 履歴から POST 結果を選んだ場合で、既に履歴バッファーに残っていない場合

[31] POST が不安全なら再試行する前に利用者に明示的に確認する必要がありますが、 多くの利用者を混乱させますし、 navigation を遅延させてしまいます。 安全ならこの確認を省略できます。 >>24

[52] 実装例があるかは不明です。

歴史

RFC

[2] RFC 2068・2616 (HTTP/1.1) 9.1 Safe and Idempotent Methods

RFC 1945 (HTTP/1.0) 12.2; RFC 2068・2616 (HTTP/1.1) 9.1.1 Safe Methods

The writers of client software Implementers {2616} Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they may might take which may have an unexpected significance to themselves or others.

実装者は、ソフトウェアがインターネット上の相互作用で利用者を表現することを意識し、 自身や他者に意図せぬ意味を持つかもしれない動作を取ろうとする時には利用者がそのことに気づけるように注意するべきです。

In particular, the convention has been established that the GET and HEAD methods should never SHOULD NOT have the significance of taking an action other than retrieval. These methods should ought to be considered "safe." "safe". This allows user agents to represent other methods, such as POST, {2068,2616} PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

特に、 GET 方式や HEAD 方式が取り出し (retrieval) 以外の動作を取る意味を持つべきではないという慣習が確立しています。 これらの方式は「安全」であると考えられるべきです。 これによって、利用者は他の方式、例えば POST や PUT や DELETE を、特別な用途で表明することができ、 よって利用者に非安全かもしれない動作が要求されようとしていることを気づかせることができます。

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

当然、サーバーが GET 要求を行うことで副作用を起こさないことを保証はできません。 実際、動的資源の中にはそれを機能としています。 ここでの重要な違いは、利用者は副作用を要求していないので、 従ってそれについての責任を負えないことです。

注: 注記のない変更点は、 RFC 2068→RFC 2616 での修正。

RFC 2068・2616 (HTTP/1.1) 9.1.2 Idempotent Methods

→冪等

RFC 2310

[42] RFC 2310 は Safe: ヘッダーを追加しました。

[44] RFC 4229 は RFC 2310 を出典に状態「実験的」でIANA登録簿に登録しています。

  • [43] RFC 4229 - HTTP Header Field Registrations ( 版) http://tools.ietf.org/html/rfc4229#section-2.1.93

関連

[5] 類似した概念に冪等があります。安全なメソッドは、冪等です >>6。

[17] 将来にわたってこの性質が保証されるのかは不明です。