HTTP リクエストに netcat (nc) と curl を使用する場合の違いは何ですか?

HTTP リクエストに netcat (nc) と curl を使用する場合の違いは何ですか?

curl を使用して特定の URL をリクエストし、200 OK 応答を取得しています。

curl -v www.youtypeitwepostit.com
* About to connect() to www.youtypeitwepostit.com port 80 (#0)
*   Trying 54.197.246.21...
* Connected to www.youtypeitwepostit.com (54.197.246.21) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.youtypeitwepostit.com
> Accept: */*
>
< HTTP/1.1 200 OK
...

ヘッダーを次のようにファイルに保存する場合:

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: www.youtypeitwepostit.com
Accept: */*

ncコマンド (netcat)を実行してみてください:

nc www.youtypeitwepostit.com 80 < file
HTTP/1.1 505 HTTP Version Not Supported
Connection: close
Server: Cowboy
Date: Wed, 02 Nov 2016 04:08:34 GMT
Content-Length: 0

別の応答が返ってきます。違いは何ですか? また、 を使って 200 OK を取得するにはどうすればよいですかnc?

リクエスト ヘッダーで HTTP のさまざまなバージョンを試し、間違った CRLF を避けるためにリクエストを手動で入力し、オプションのヘッダーを除外してみました。結果は同様です。

答え1

関連するRFC、ハイパーテキスト転送プロトコル (HTTP/1.1): メッセージ構文とルーティング質問に対する答えは、HTTP リクエストの各行は CR/LF で終わる必要があるということです。


HTTPの文法メッセージ形式各ヘッダー行は、復帰文字 ( 0x0dASCII の場合) とそれに続く改行文字 ( 0x0a) で終了することを指定します。

 HTTP-message   = start-line
                  *( header-field CRLF )
                  CRLF
                  [ message-body ]

これは、リクエストライン:

リクエスト ラインはメソッド トークンで始まり、その後に 1 つのスペース (SP)、リクエスト ターゲット、別の 1 つのスペース (SP)、プロトコル バージョンが続き、CRLF で終わります。

 request-line   = method SP request-target SP HTTP-version CRLF

は HTTP リクエスト専用に開発されているためcurl、HTTP リクエストを行う際に適切な行末が既に使用されています。ただし、netcat はより汎用的なプログラムです。Unix ユーティリティであるため、デフォルトでは行末に改行文字が使用されるため、ユーザーは行が正しく終了していることを確認する必要があります。

unix2dosこのユーティリティを使用すると、リクエスト ヘッダーを含むファイルを、復帰改行コードで終了するように変換できます。

HTTP リクエストを手動で入力し、 の最新バージョンを使用している場合は、行末に を使用するオプションをnc使用する必要があります。-CCRLF

nc -C www.youtypeitwepostit.com 80

ちなみに、ほとんどの一般的なインターネット プロトコル (SMTP など) では CR/LF 行末が使用されていることに注意してください。


一部のウェブサーバー(Apacheなど)はより寛容で、ラインフィード文字で終了するリクエスト行のみを受け入れることに注意してください。HTTP仕様では、これが許可されており、メッセージ解析の堅牢性セクション:

開始行とヘッダー フィールドの行末文字は CRLF シーケンスですが、受信者は単一の LF を行末文字として認識し、先行する CR を無視する場合があります。

関連情報