[1] HTTP においてメソッドや要求が安全であるとは、 副作用が無い (少なくても利用者は求めていない) ことを表します。
[8] 要求メソッドは、その意味が読み取り専用と定義されていれば、 「安全」です。安全なメソッドでは、 クライアントは起源鯖が対象資源の状態を変化させることを要求も期待もしませんし、 普通に安全なメソッドを使っても、起源鯖で有害な事象やおかしなことは起こらないと期待されます。 >>6
[9] 実装が >>8 の条件を満たしている保証はなく、何かを変化させたり、 副作用を起こしたりすることはあり得ます。しかし、それはクライアントが要求したことではなく、 クライアントが責任を持つものではない、ということが重要とされています。 >>6
[10] 例えばほとんどの鯖はアクセスログにすべての要求を記録しています。 それによって鯖のストレージが満杯になってクラッシュする可能性があっても、 安全かどうかには影響しません。また、広告の取得であれば、 広告主への課金という副作用を持つかもしれませんが、やはり安全性とは関係ありません。 >>6
[13] 安全と非安全の区別は、無害な形で自動的な取得 (ボット) やキャッシュ処理 (先読み) を実行できるようにするためのものです。 >>6
[14] 利用者エージェントは、信頼できないかもしれない内容の処理時に安全でないメソッドの自動利用を制限することもできます。 >>6
[15] 利用者エージェントは、可能な操作を提示する時に安全か非安全かを明確に区別して、 非安全な操作を実行する前に利用者が気付けるようにするべきです >>6。
[16] 実効要求URLの一部が動作を表す場合、例えば page?do=delete
のような URL の場合、資源の所有者は、安全なメソッドの時はその動作を無効にするか、
認めないようにしなければなりません >>6。
[19] キャッシュが非安全メソッドに対する応答を受信したら、 次のようにしなければなりません >>18。
Safe: ヘッダー[25] Safe: ヘッダーは、
要求を繰り返しても安全であるか否かを示します >>24。
[38] Safe: ヘッダーの値は、字句です。
大文字・小文字不区別です。
[46] 現在次の値が定義されています。
[48] RFC 2310 では値として yes と no
を規定しています。yes は安全、 no
は非安全を表します。
[47] HTCPCP は if- を条件付きで安全であることを表すよう拡張しています。
具体的な値として、 if-user-awake を規定してます。 >>45
[50] 任意の応答で利用できると思われますが、不明です。 要求では利用できないと思われます。
[51] 実際に利用されている例があるかは不明です。
[39] 応答に Safe: ヘッダーがなければ、
GET や HEAD の場合を除き、
非安全とみなさなければなりません >>24。
[40] 利用者エージェントは GET や HEAD
の時 Safe: ヘッダーを無視するべきです >>24。
[26] 利用者エージェントは要求の反復が安全なら、 利用者に確認せずに自動的に反復して構いません >>24。
[27] 例えば次のような場合に利用者エージェントは POST
要求を繰り返す必要があります >>24。
[31] POST が不安全なら再試行する前に利用者に明示的に確認する必要がありますが、
多くの利用者を混乱させますし、 navigation を遅延させてしまいます。
安全ならこの確認を省略できます。 >>24
[52] 実装例があるかは不明です。
{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 theyThe writers of client softwareImplementersmaymight 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 neverSHOULD NOT have the significance of taking an action other than retrieval. These methodsshouldought 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 での修正。
→冪等
[5] 類似した概念に冪等があります。安全なメソッドは、冪等です >>6。