2

アプリケーションに HTTP-GET リクエストを送信するシステムと統合しています。Jetty を使用すると、何かを叩き合わせるのに数分かかりました。

curl (リクエストに必要なエスケープを含む) でテストしたところ、すべてバラ色でした。要求どおりに応答が返されました。

$ curl http://localhost:9100?field1=value1\&field2=value2\&field3=value3

マシン上の TCP ダンプは、リクエストが次のように送信されたことを示しています。

GET /?field1=value1&field2=value2&field3=value3 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3    libidn/1.18 libssh2/1.2.2
Host: xxx.xxx.xxx.xxx:9100
Accept: */*

しかし、人生はそれほど単純ではありません。実際のシステムとの統合を実際に開始できるようにこれをデプロイしたとき、コード内のハンドラーは呼び出されませんでした。Jetty はすぐに「HTTP/1.1 400 Bad Request」で応答しました。TCP ダンプにより、次のことが明らかになりました。

GET ?field1=value1&field2=value2&field3=value3 HTTP/1.1

それだけです...ヘッダー情報はありません。上記のみです。

私の質問は、上記の要求が実際に有効かどうかです。スラッシュは必須ですか？必須のヘッダー エントリはありますか?

何か案は？これは、これを機能させるためにホイールを再設計する必要があるということですか?

編集：

telnetで接続してみました。一部の Web サーバーでは、GET リクエストの後に / が実際に必要なようです。ただし、それらの間で扱いが異なるようです。Jetty は文句を言います。Google が実行している Web サーバーは文句を言います...しかし、Apache はそれで問題ない例です。ヘッダー情報は必要ないようです。

4

3 に答える 3

7

RFC 2616は、すべての雑多な詳細を提供します。

3.2.2

abs_pathがURLに存在しない場合、リソースのRequest-URIとして使用する場合は「/」として指定する必要があります（セクション5.1.2）。

14.23

クライアントは、すべてのHTTP/1.1要求メッセージにHostヘッダーフィールドを含める必要があります。

于 2012-08-23T09:31:22.157 に答える
2

HTTP1.1仕様によれば、Host:ヘッダーフィールドは必須です。先頭のスラッシュは必要ありません。先頭のスラッシュも必要であることがわかりました。

于 2012-08-23T09:31:14.293 に答える
0

何も問題はありません。スラッシュは必須ではありません。

訂正します。スラッシュが必要です。

于 2012-08-23T09:29:36.370 に答える