ご存知のように、ファイルのアップロードはほとんどの場合、POST
メソッドを使用して行われます。GET
では、代わりにこのメソッドをファイルのアップロードに使用できないのはなぜでしょうか? GET
HTTPアップロードに対する具体的な禁止事項はありますか?
2 に答える
GET リクエストにはエンティティ本体が含まれる場合があります
RFC 2616 は、GET 要求の一部としてのエンティティ ボディを妨げません。これはよく誤解されます。なぜなら、PHP は不適切な名前の $_GET
スーパーグローバルで水域を混乱させるからです。$_GET
技術的には、HTTPGET
リクエスト メソッドとは何の関係もありません。これは、リクエスト URI クエリ文字列からの URL エンコードされたパラメータのキーと値のリストにすぎません。$_GET
リクエストが POST/PUT/etc 経由で行われた場合でも、配列にアクセスできます。変ですよね?あまり良い抽象化ではありませんか?
GET エンティティ本体が悪い考えである理由
それで、仕様はGETメソッドについて何を言っていますか...まあ:
特に、GET メソッドと HEAD メソッドは、検索以外のアクションを実行するという意味を持つべきではないという規則が確立されています。これらの方法は「安全」であると考えるべきです。
したがって、GET で重要なことは、すべての GET リクエストが安全であることを確認することです。それでも、禁止事項は「SHOULD NOT」だけです...技術的には、HTTP では GET リクエストが「取得」に厳密に基づいていないアクションをもたらすことを依然として許可しています。
もちろん、セマンティックの観点からはGET
、リソースを「取得」する以外のアクションを実行するために名前が付けられたメソッドを使用することもあまり意味がありません。
GETエンティティ本体が完全に間違っている場合
べき等性に関して、仕様は次のように述べています。
メソッドは、(エラーや有効期限の問題は別として) N > 0 の同一のリクエストの副作用が単一のリクエストの場合と同じであるという点で、「冪等性」のプロパティを持つこともできます。メソッド GET、HEAD、PUT、および DELETE は、このプロパティを共有します。
これは、同じリソースに対する複数のリクエストに対して、GET メソッドに異なる副作用があってはならないことを意味します。したがって、GET 要求の一部として存在するエンティティ本体に関係なく、副作用は常に同じでなければなりません。簡単に言えば、これは、エンティティ本体で GET を 100 回送信すると、サーバーが 100 個の新しいリソースを作成できないことを意味します。リクエストが 1 回送信された場合でも 100 回送信された場合でも、同じ結果が得られる必要があります。これにより、エンティティ本体を送信するための GET メソッドの有用性が大幅に制限されます。
疑わしい場合は、メソッドの有効性とその結果として生じる副作用を評価するときに、常に安全性/冪等性テストに頼ってください。
GETメソッドの場合
- フォーム データを名前と値のペアで URL に追加します。URL の長さは制限されています (3000 文字)。
- フォームを使用してファイルの内容を URL パラメータ内に配置することはできません。そのため、POST を使用してください
- Get メソッドでは、action の値に「?」を追加します。それに、「application/x-www-form-urlencoded」コンテンツ タイプを使用してエンコードされたフォーム データ セットを追加します。次に、ユーザー エージェントは、この URI へのリンクをトラバースします。このシナリオでは、フォーム データはASCII コードに制限されています。
そのため、GETメソッドではそのファイルのアップロードはできません