リクエストボディを含むHTTP GET

アプリケーション用の新しいRESTful Webサービスを開発しています。

特定のエンティティに対してGETを実行すると、クライアントはエンティティのコンテンツを要求できます。一部のパラメーターを追加する場合（リストの並べ替えなど）、これらのパラメーターをクエリ文字列に追加できます。

あるいは、リクエストの本文でこれらのパラメーターを指定できるようにしたいです。 HTTP / 1.1はこれを明示的に禁止していないようです。これにより、より多くの情報を指定できるようになり、複雑なXML要求を指定しやすくなる場合があります。

私の質問：

• これは完全に良いアイデアですか？
• HTTPクライアントは、GETリクエスト内のリクエスト本文の使用に問題がありますか？

http://tools.ietf.org/html/rfc2616

GETリクエストに本文を含めることに関するRoy Fieldingのコメント。

はい。つまり、すべてのHTTPリクエストメッセージにメッセージ本文を含めることができるため、メッセージ本文を解析する必要があります。ただし、GETのサーバーセマンティクスは制限され、ボディが存在しても、リクエストに対してセマンティックな意味がありません。解析の要件は、メソッドのセマンティクスの要件とは異なります。

そのため、はい、GETで本文を送信できます。いいえ、送信しても役に立ちません。

これはHTTP / 1.1の階層化された設計の一部であり、仕様がパーティション化されると（作業中）、再び明らかになります。

....ロイ

はい、GETを使用してリクエスト本文を送信できますが、意味はありません。サーバー上で構文解析し、その内容に基づいて応答を変更することで意味を与える場合、HTTP / 1.1仕様のセクション4.3でこの推奨事項を無視しています。

[...]リクエストメソッドにエンティティボディの定義されたセマンティクスが含まれていない場合、リクエストを処理するときにメッセージボディを無視する必要があります（SHOULD）。

また、HTTP / 1.1仕様のセクション9.3のGETメソッドの説明：

GETメソッドは、Request-URIで識別される情報（[...]）を取得することを意味します。

これは、リクエストボディがGETリクエストのリソースの識別の一部ではなく、リクエストURIのみであることを示しています。

更新 「HTTP / 1.1仕様」として参照されているRFC2616は廃止されました。2014年には、RFC 7230〜7237に置き換えられました。「リクエストを処理する場合、メッセージ本文は無視する必要があります」という引用が削除されました。これは、「メソッドがメッセージ本文の用途を定義していなくても、リクエストメッセージのフレーミングはメソッドのセマンティクスに依存しない」にすぎません。削除されました。-コメントから

HTTP仕様で明示的に除外されていない限り、それを行うことができますが、人々がそのように機能することを期待していないという理由だけで、それを回避することをお勧めします。HTTPリクエストチェーンには多くのフェーズがあり、それらは「ほぼ」HTTP仕様に準拠していますが、Webブラウザーで従来使用されているように動作することが保証されます。（透過プロキシ、アクセラレータ、A / Vツールキットなどを考えています）

これは、ロバスト性の原則の背後にある精神であり、大まかに「受け入れるものは寛大であり、送信するものは保守的である」ため、正当な理由なしに仕様の境界を押し広げたくない。

しかし、もしあなたが正当な理由があるなら、それのために行ってください。

キャッシュを利用しようとすると、問題が発生する可能性があります。プロキシーは、GET本体を調べて、パラメーターが応答に影響を与えるかどうかを確認しません。

restclientもRESTコンソールもこれをサポートしていませんが、curlはサポートしています。

HTTPの仕様では、 4.3節で述べています

リクエストメソッドの仕様（セクション5.1.1）がリクエストでのエンティティボディの送信を許可しない場合、メッセージボディをリクエストに含めることはできません。

セクション5.1.1は、さまざまな方法についてセクション9.xにリダイレクトします。メッセージ本文を含めることを明示的に禁止するものはありません。しかしながら...

セクション5.2は言う

インターネット要求によって識別される正確なリソースは、Request-URIとHostヘッダーフィールドの両方を調べることによって決定されます。

そしてセクション9.3は言う

GETメソッドは、Request-URIで識別される情報（エンティティーの形式）を取得します。

これは、GET要求を処理するときに、サーバーがRequest-URIおよびHostヘッダーフィールド以外のものを調べる必要がないことを示唆しています。

要約すると、HTTP仕様はGETでメッセージ本文を送信することを妨げるものではありませんが、すべてのサーバーでサポートされていなかったとしても不思議ではありません。

Elasticsearchは、本文付きのGETリクエストを受け入れます。これは推奨される方法であるように見えます：Elasticsearchガイド

一部のクライアントライブラリ（Rubyドライバーなど）は、開発モードでcryコマンドをstdoutに記録でき、この構文を広く使用しています。

あなたが達成しようとしていることは、ずっと一般的な方法で長い間行われており、GETでペイロードを使用することに依存しない方法です。

特定の検索メディアタイプを作成するか、よりRESTfulにしたい場合は、OpenSearchなどを使用して、サーバーが指示したURI（/ searchなど）に要求をPOSTできます。次に、サーバーは検索結果を生成するか、最終的なURIを作成して303を使用してリダイレクトできます。

これには、従来のPRG方式に従う利点があり、仲介者が結果をキャッシュするのに役立ちます。

とはいえ、URIはASCII以外のすべてのものに合わせてエンコードされるため、application / x-www-form-urlencodedおよびmultipart / form-dataも同様です。ReSTfulシナリオをサポートする場合は、さらに別のカスタムjson形式を作成するのではなく、これを使用することをお勧めします。

本文でGETを送信するか、POSTを送信してRESTの信仰を放棄することができます（それほど悪くはありません。5年前は、その信仰のメンバーは1人しかいませんでした-彼のコメントは上記にリンクされています）。

どちらもすばらしい決定ではありませんが、GET本文を送信すると、一部のクライアント（一部のサーバー）の問題を防ぐことができます。

POSTを実行すると、一部のRESTishフレームワークに障害が生じる可能性があります。

Julian Reschkeさんは、「SEARCH」のような非標準のHTTPヘッダーを使用することを上記で提案しましたが、サポートされる可能性がさらに低いことを除けば、エレガントなソリューションになる可能性があります。

上記のそれぞれを実行できるクライアントと実行できないクライアントをリストすることは、最も生産的です。

（私が知っている）本文付きのGETを送信できないクライアント：

• XmlHTTPRequest Fiddler

本文付きのGETを送信できるクライアント：

• ほとんどのブラウザ

GETから本体を取得できるサーバーとライブラリ：

• Apache
• PHP

GETから本文を削除するサーバー（およびプロキシ）：

• ？

この質問はIETF HTTP WGに寄せました。Roy Fielding（1998年のhttp / 1.1ドキュメントの著者）からのコメントは、

「...実装は、受信された場合、その本体を解析して破棄する以外のことを行うために壊れます。」

RFC 7213（HTTPbis）は次のように述べています：

「GETリクエストメッセージ内のペイロードにはセマンティクスが定義されていません。」

GETリクエストボディでのセマンティックな意味は禁止されていること、つまりリクエストボディを結果に影響を与えるために使用できないことが意図されていたことは明らかです。

GETに本文を含めると、さまざまな方法でリクエストを確実に中断するプロキシが世の中に存在します。

要約すると、それを行わないでください。

どのサーバーがそれを無視しますか？– fijiaaron 2012年8月30日21:27

たとえばグーグルはそれを無視するよりも悪いことをしている、それはそれをエラーとみなすだろう！

簡単なnetcatを使って自分で試してください：

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

（1234コンテンツの後にCR-LFが続くため、合計6バイトになります）

あなたは得るでしょう：

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

また、BingやAppleなどからAkamaiGhostが提供する400 Bad Requestも受け取ります。

そのため、ボディエンティティでGETリクエストを使用することはお勧めしません。

RFC 2616、セクション4.3、 "メッセージ本文"：

サーバーはどんなリクエストでもメッセージボディを読んで転送すべきです。リクエストメソッドにエンティティボディの定義されたセマンティクスが含まれていない場合、リクエストを処理するときにメッセージボディを無視する必要があります（SHOULD）。

つまり、サーバーは常にネットワークから提供されたリクエスト本文を読み取る必要があります（Content-Lengthを確認するか、チャンクボディを読み取るなど）。また、プロキシは受け取ったそのようなリクエスト本文を転送する必要があります。次に、RFCが指定されたメソッドの本文のセマンティクスを定義している場合、サーバーは実際に要求本文を使用して応答を生成できます。ただし、RFC がそうしない場合本文のセマンティクスを定義しサーバーはそれを無視する必要があります。

これは、上記のフィールディングからの引用と一致しています。

9.3項「GET」では、GETメソッドのセマンティクスについて説明し、リクエストの本文については触れていません。したがって、サーバーはGET要求で受信した要求本文を無視する必要があります。

XMLHttpRequestによると、これは無効です。標準から：

4.5.6 send()メソッド

client . send([body = null])

リクエストを開始します。オプションの引数は、リクエストの本文を提供します。リクエストメソッドがGETまたはの場合、引数は無視されHEADます。

をスローします InvalidStateErrorいずれかの状態が開かれていないか、send()フラグが設定されている場合は例外をます 。

この方法は、以下の手順を実行する必要があります。send(body)

1. 状態がそうでない場合 開かれて、InvalidStateError例外をます。
2. send()フラグが設定されている場合は、InvalidStateError例外をます。
3. リクエストメソッドがGETまたはHEAD、本文を設定しますをnullします。
4. 体ならがnullのは、次の手順に進みます。

ただし、GETリクエストには大きな本文コンテンツが必要になる可能性があるため、そうすべきではないと思います。

したがって、ブラウザーのXMLHttpRequestに依存している場合は、機能しない可能性があります。

キャッシュ可能なJSON / XMLボディをWebアプリケーションに送信したい場合、データを配置するための唯一の妥当な場所は、RFC4648：Base 64 Encoding with URL and Filename Safe Alphabetでエンコードされたクエリ文字列です。もちろん、JSONをurlencodeしてURLパラメータの値に配置することもできますが、Base64の方が結果は小さくなります。URLサイズの制限があることに注意してください。さまざまなブラウザーでのURLの最大長は何ですか？を参照してください。。

Base64のパディング=文字はURLのparam値としては悪いと思われるかもしれませんが、そうではないようです-次のディスカッションを参照してください：http : //mail.python.org/pipermail/python-bugs-list/2007-February/037195.html。ただし、パディング付きのエンコードされた文字列は空の値を持つparamキーとして解釈されるため、param名なしでエンコードされたデータを配置しないでください。のようなものを使用します?_b64=<encodeddata>。

私はこれを助言しません、それは標準的な慣行に反し、その見返りにはそれほど多くを提供しません。オプションではなく、コンテンツの本文を保持したい。

非準拠のbase64エンコードされたヘッダーはどうですか？「SOMETHINGAPP-PARAMS：sdfSD45fdg45 / aS」

長さ制限hm。POST処理で意味を区別できませんか？並べ替えのような単純なパラメーターが必要な場合、なぜこれが問題になるのかわかりません。あなたが心配していることは確かだと思います。

プロトコルがOOPをサポートしていないため、RESTに不満を感じています。 Get方法が証明されている。ソリューションとして、DTOをJSONにシリアル化し、クエリ文字列を作成できます。サーバー側では、クエリ文字列をDTOに逆シリアル化できます。

見てみましょう：

• ServiceStackでのメッセージベースの設計
• WCFを使用したRESTfulメッセージベースのWebサービスの構築

メッセージベースのアプローチは、Getメソッドの制限を解決するのに役立ちます。リクエスト本文と同様に、任意のDTOを送信できます

Nelibur Webサービスフレームワークは、使用できる機能を提供します

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

たとえば、Curl、Apache、PHPで動作します。

PHPファイル：

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

コンソールコマンド：

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

出力：

GET
{"the": "body"}

私見では、JSONエンコードされた（つまりencodeURIComponent）をで送信するだけでURLよいので、HTTP仕様に違反せずにJSONサーバーにアクセスできます。

GETでリクエストボディを使用するよりもはるかに優れたオプションのリストがあります。

カテゴリと各カテゴリのアイテムがあるとします。どちらもIDで識別されます（この例では、 "catid" / "itemid"）。特定の「順序」で別のパラメーター「sortby」に従ってソートしたい。「sortby」と「order」のパラメーターを渡したい場合：

あなたはできる：

1. クエリ文字列を使用してください。 example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. パスにはmod_rewrite（または同様のもの）を使用します。 example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. リクエストで渡す個々のHTTPヘッダーを使用する
4. リソースを取得するには、POSTなどの別のメソッドを使用します。

すべてに欠点がありますが、ボディでGETを使用するよりもはるかに優れています。

このページで頻繁に引用されているように、人気のあるツールがこれを使用していても、仕様に禁じられていないにもかかわらず、あまりにもエキゾチックであるというのは依然としてかなり悪い考えだと思います。

多くの中間インフラストラクチャは、このようなリクエストを拒否するだけです。

一例では、このように、あなたのウェブサイトの前に利用可能CDNの一部を使用して忘れる1：

ビューアのGETリクエストに本文が含まれている場合、CloudFrontはHTTPステータスコード403（禁止）をビューアに返します。

このコメントで報告されているように、クライアントライブラリもそのようなリクエストの発行をサポートしていない場合があります。

私はクライアントプログラムでSpringフレームワークのRestTemplateを使用しており、サーバー側で、Json本文を使用してGETリクエストを定義しています。私の主な目的はあなたのものと同じです。リクエストに多数のパラメーターがある場合、それらを本文に入れると、長いURI文字列に入れるよりも整然と見えます。はい？

しかし、残念ながら、それは機能していません！サーバー側は次の例外をスローしました：

org.springframework.http.converter.HttpMessageNotReadableException：必要なリクエスト本文がありません...

しかし、メッセージ本文がクライアントコードによって正しく提供されていると確信しているので、何が問題になっていますか？

RestTemplate.exchange（）メソッドをたどると、次のことがわかりました。

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

executeInternal（）メソッドでは、入力引数 'bufferedOutput'に、コードによって提供されたメッセージ本文が含まれていることに注意してください。デバッガを通して見ました。

ただし、prepareConnection（）により、executeInternal（）のgetDoOutput（）は常にfalseを返すため、bufferedOutputは完全に無視されます。出力ストリームにはコピーされません。

その結果、サーバープログラムはメッセージ本文を受信せず、その例外をスローしました。

これは、SpringフレームワークのRestTemplateの例です。重要なのは、メッセージ本文がHTTP仕様で禁止されなくなっても、一部のクライアントまたはサーバーライブラリまたはフレームワークは古い仕様に準拠し、GETリクエストからのメッセージ本文を拒否する可能性があるということです。