🙏🏻 🐼 🈺 両面のREQUEST_URIまたは正しいHTTP / 1.1サーバーを探している 👩🏻‍🤝‍👨🏽 👨🏿‍🚀 ⚱️

Apache mod_rewriteの％{REQUEST_URI}とPHPの$ _SERVER ["REQUEST_URI"]の違いを知っていますか？

wwwプレフィックスを持つドメインから、またはApacheレベルの.htaccessでドメインに301を正しく転送できますか？

最後の質問については、まだ解決策を提供できません。その理由は、HTTP / 1.1プロトコルです。これは、「自転車を発明した」（サイトのコアを作成した）ときに、より詳細に調査する必要がありました。

「Host：」リクエストのHTTPヘッダーがすべてです。特定の条件下では、何でもそこにある可能性があり、サーバーはHTTP / 1.1に従って完全に無視する必要があります。ほとんどの開発者は、SEO最適化などにこのフィールドの値を使用します。今後、追加のプロキシ（たとえば、nginx）がこの問題を解決すると言います。

サーバーの不正な動作を説明するために、Habr社のサイトを反復処理することにしました。ダースのサイトでは、彼は手動でそれを行い、その後、一部のサイトが誤った要求に「正しく」応答することを発見しました。その後、小さなテストユーティリティが作成され、テストするテストパターンとサイトの数を増やすことができました。

HTTP / 1.1でREQUEST_URIを隠すものは何ですか？

理論

HTTP / 1.0

HTTP / 1.0プロトコルから始めます。これは、RfC1945 www.w3.org/Protocols/rfc1945/rfc1945で説明されており、1996年5月の日付です。目的のページを取得するには、サーバーに接続して1行送信するだけで十分です。

  GET /path/to/resource.html HTTP / 1.0

プロキシサーバーにアクセスするときは、絶対パスではなく、完全なアドレスを使用する必要がありました。

  GET http://domain.name/path/to/resource.html HTTP / 1.0

これはすべてセクション5.1.2「Request-URI」で説明されています。

ホストの外観

1つのサーバーが一度に複数のドメイン名を提供できるようにするために、プロトコル作成者は、アクセスされるドメインを含む「Host：」リクエストヘッダーを追加しました。このヘッダーはHTTP / 1.0標準の一部ではありませんが、一部のサーバーおよびクライアントでサポートされるようになりました。たとえば、wgetはHTTP / 1.0を介してリクエストを送信しますが、「Host：」を追加します。

HTTP / 1.1

1999年6月（14年前）にHTTP / 1.1プロトコルが登場しました。これは、RfC2616 www.w3.org/Protocols/rfc2616/rfc2616.htmlで説明されています。セクション14.23で、新しいプロトコルでは、各リクエストヘッダーに「ホスト」フィールドを含める必要がありました。

クライアントは、すべてのHTTP / 1.1要求メッセージにHostヘッダーフィールドを含める必要があります。要求されたURIに、要求されているサービスのインターネットホスト名が含まれていない場合、Hostヘッダーフィールドには空の値を指定する必要があります。

さらに、クエリ文字列からRequest-URIに大幅な変更が加えられました（セクション5.1.2 ）。前のプロトコルと同様に、プロキシサーバーへの要求には完全なアドレスが必要です（「要求がプロキシに対して行われる場合、absoluteURIフォームが必要です。」）。ただし、すべてのサーバーはこのようなリクエストに応答する必要がありますが、クライアントはプロキシサーバーに対してのみそのようなリクエストを発行します。

HTTPの将来のバージョンのすべてのリクエストで絶対URIへの移行を可能にするには、HTTP / 1.1クライアントがプロキシへのリクエストでのみ生成する場合でも、すべてのHTTP / 1.1サーバーはリクエストで絶対URIフォームを受け入れなければなりません。

完全なアドレス（たとえば、 http ： //www.w3.org/pub/WWW/TheProject.html ）に移動することになっていたことに注意してください。したがって 、クライアントは絶対パス（abs_pathなど、 / pubなど）のみを使用する必要はありません。 /WWW/TheProject.html ）。さらに、サーバーはクライアントからの要求に絶対URIで応答する機能を明示的に必要とします。したがって、この場合、クライアントの要求が正しくないという異議は、「クライアントは常に正しい」ため、すぐに除外します。

HTTP / 1.1のホスト

Request-URIの変更は無害に見えるかもしれませんが、セクション5.2には1つの重要な要件が含まれています。「Request-URIがabsoluteURIである場合、ホストはRequest-URIの一部です。要求内のHostヘッダーフィールドの値は無視する必要があります。”つまり、要求の解釈

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：anytext

要求に一致する必要があります

  GET /path/to/resource.html HTTP / 1.1
ホスト：domain.name

absoluteURIでクエリを実行するときに「Host：」を無視しますか？

％{REQUEST_URI}および$ _SERVER ["REQUEST_URI"]

mod_rewriteのドキュメントには、次のことが記載されています。

THE_REQUEST

ブラウザからサーバーに送信される完全なHTTPリクエスト行（例：「GET /index.html HTTP / 1.1」）。これには、ブラウザから送信された追加のヘッダーは含まれません。この値は、以下の他のほとんどの変数とは異なり、エスケープされていません（デコードされていません）。

REQUEST_URI

「/index.html」など、要求されたURIのパスコンポーネント。これは、QUERY_STRINGという名前の独自の変数として使用可能なクエリ文字列を特に除外します。

つまり、％{REQUEST_URI}には常に絶対パスがあり、完全なアドレスはありません。

ユーザーが次のリクエストを送信した場合、mod_rewriteを使用せずにドメインに「www」を追加する標準SEOタスクを試してください。

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：www.domain.name

記事の冒頭で、Apache mod_rewriteの％{REQUEST_URI}とPHPの$ _SERVER ["REQUEST_URI"]の違いについて尋ねたので、PHPのドキュメントからの抜粋を示します。

REQUEST_URI

このページにアクセスするために指定されたURI。たとえば、「/ index.html」。

どこかで設定できますが、私にとっては、PHP / 5.3.13は完全なアドレスで要求されたときにabsoluteURIを返します。

練習する

実サーバーにクエリを実行するとどうなるかを考えてみましょう。 Webサイトのアドレスは、 Habra社のページから取得しました（リストはそこに変更されます。先週の終わりに取得しました）。 Node.JSで小さなスクリプトをスケッチしました。http_check関数は単一のリクエストを送信し、full_http_checkは特定のテンプレートに従って特定のサーバーに複数のリクエストを生成します。

スクリプトコード

var net = require('net'); var default_result = function(title) { if (title) { return {'title': 'title', 'step': 'step', 'host': 'host', 'request': 'request', 'header': 'header', 'full_response': 'full_response', 'response': 'response', 'server': 'server', 'length': 'length', 'location': 'location', 'error': 'error'}; } else { return {'title': '', 'step': '', 'host': '', 'request': '', 'header': '', 'full_response': '', 'response': '', 'server': '', 'length': '', 'location': '', 'error': ''}; } }; var format_result = function(result) { return '' + result['title'].toString() + '\t' + result['step'] + '\t' + result['host'] + '\t' + result['request'].toString() + '\t' + result['header'].toString() + '\t' + result['response'].toString() + '\t' + result['server'].toString() + '\t' + result['length'].toString() + '\t' + result['error'].toString() + '\t' + result['location'].toString() + '\t' + result['full_response'].toString(); }; var http_check = function(title, step, host, req, host_hdr) { var host_header = host_hdr || ''; var result = default_result(false); result['title'] = title; result['step'] = step; result['host'] = host; result['request'] = req; result['header'] = host_header; var dat = ''; var client = net.connect({port: 80, host: host}, function() { //'connect' listener client.on('data', function (data) { dat = dat + data; var lines = dat.toString().split('\r\n'); result['full_response'] = JSON.stringify(dat.toString().split('\r\n\r\n')[0]); result['response'] = lines[0] || false; if (lines[0].substring(0, 5) == 'HTTP/') { var i = 1; while (lines[i] != '') { var title = lines[i].match(/^([^:]+:)\s(.+)$/); if (title[1] == 'Location:') { result['location'] = title[2]; } else if (title[1] == 'Server:') { result['server'] = title[2]; } else if (title[1] == 'Content-Length:') { result['length'] = title[2]; } i++; } if (dat.indexOf('\r\n\r\n') >= 0) { client.end(); client.destroy(); } } else { client.end(); client.destroy(); } }); client.on('end', function () { console.log('client disconnected'); }); client.on('error', function (error) { console.log('ERROR: ' + error.toString()); }); client.on('timeout', function () { console.log('Timeout'); }); client.on('close', function (had_error) { result['error'] = result['error'] || had_error || ''; console.log(format_result(result)); }); client.write(req + '\r\n'); host_hdr && client.write('Host: ' + host_hdr + '\r\n'); client.write('\r\n'); }); }; var full_http_check = function(title, url) { var parts = url.match(/^http:\/\/([^\/]+)(.+)$/); // 1 // GET /path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '01', parts[1], 'GET ' + parts[2] + ' HTTP/1.1', parts[1]); // 2 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '02', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 3 // GET /path/to/resource.html HTTP/1.0 http_check(title, '03', parts[1], 'GET ' + parts[2] + ' HTTP/1.0', ''); // 4 // GET /path/to/resource.html HTTP/1.0 // Host: domain.name http_check(title, '04', parts[1], 'GET ' + parts[2] + ' HTTP/1.0', parts[1]); // 5 // GET http://domain.name/path/to/resource.html HTTP/1.0 http_check(title, '05', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.0', ''); // 6 // GET http://domain.name/path/to/resource.html HTTP/1.0 // Host: domain.name http_check(title, '06', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.0', parts[1]); // 7 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: void.domain.name http_check(title, '07', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', 'void.' + parts[1]); // 8 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: local.fake http_check(title, '08', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', 'local.fake'); // 9 // GET http://domain.name/path/to/resource.html HTTP/1.1 // Host: l-IjFN=fiG(w+J2p:#.{92!m`d^? http_check(title, '09', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', 'l-IjFN=fiG(w+J2p:#.{92!m`d^?'); // 10 // GET http://fake.domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '10', parts[1], 'GET http://fake.' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 11 // GET http://local.fake/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '11', parts[1], 'GET http://local.fake' + parts[2] + ' HTTP/1.1', parts[1]); // 12 // GET http://l-IjFN=fiG(w+J2p:#.{92!m`d^?/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '12', parts[1], 'GET http://l-IjFN=fiG(w+J2p:#.{92!m`d^?' + parts[2] + ' HTTP/1.1', parts[1]); // 13 // GET http://local.fake/path/to/resource.html HTTP/1.1 // Host: void.domain.name http_check(title, '13', parts[1], 'GET http://local.fake' + parts[2] + ' HTTP/1.1', 'void.' + parts[1]); // 14 // GET habr://domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '14', parts[1], 'GET habr://' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 15 // GET habr://void.domain.name/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '15', parts[1], 'GET habr://void.' + parts[1] + parts[2] + ' HTTP/1.1', parts[1]); // 16 // GET habr://local.fake/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '16', parts[1], 'GET habr://local.fake' + parts[2] + ' HTTP/1.1', parts[1]); // 17 // GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?/path/to/resource.html HTTP/1.1 // Host: domain.name http_check(title, '17', parts[1], 'GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?' + parts[2] + ' HTTP/1.1', parts[1]); // 18 // GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?/path/to/resource.html HTTP/1.1 // Host: local.fake http_check(title, '18', parts[1], 'GET habr://l-IjFN=fiG(w+J2p:#.{92!m`d^?' + parts[2] + ' HTTP/1.1', 'local.fake'); }; console.log(format_result(default_result(true))); /* http_check('IBM Fake', 'www.ibm.com', 'GET ttp://com/midmarket/ru/ru/ HTTP/1.1', 'ibm'); full_http_check('IBM', 'http://www.ibm.com/midmarket/ru/ru/'); */ full_http_check('', 'http://company.yandex.ru/about/main/'); full_http_check('JetBrains', 'http://www.jetbrains.com/products.html'); full_http_check('Box Overview', 'http://7del.net/texts/galaxy-note.html'); full_http_check('KolibriOS Project Team', 'http://kolibrios.org/en/download.htm'); full_http_check('Opera Software ASA', 'http://www.opera.com/about'); full_http_check('Apps4All', 'http://apps4all.ru/news/apple/apple-ios-7-beta.html'); full_http_check('', 'http://nordavind.ru/node/207'); full_http_check('Mail.Ru Group', 'http://corp.mail.ru/about/'); full_http_check('Microsoft', 'http://windows.microsoft.com/ru-RU/windows/home'); full_http_check('Zfort Group', 'http://www.zfort.com.ua/company/about/'); full_http_check('IBM', 'http://www.ibm.com/contact/ru/ru/'); full_http_check('UIDG', 'http://uidesign.ru/about/'); full_http_check('Intel', 'http://www.intel.ru/content/www/ru/ru/company-overview/company-overview.html'); full_http_check('Rusonyx', 'http://www.rusonyx.ru/company/reasons/'); full_http_check('', 'http://www.mosigra.ru/page/about/'); full_http_check('DevConf', 'http://devconf.ru/about/'); full_http_check('e-Legion Ltd.', 'http://www.e-legion.ru/contacts/'); full_http_check('Badoo', 'http://corp.badoo.com/company/'); full_http_check(' ()', 'http://mobile.beeline.ru/msk/setup/index.wbp');

次に、各テンプレートとサイトの反応を詳しく見てみましょう。

リクエスト1

絶対パスと正しいHostヘッダーを含む、最も一般的なHTTP / 1.1要求オプション。どのサーバーも正しく応答する必要があります。つまり、「HTTP / 1.1 200 OK」を待っています。

  GET /path/to/resource.html HTTP / 1.1
ホスト：domain.name

すべてのサーバーが「HTTP / 1.1 200 OK」を返しました。以下は、「サーバー」応答ヘッダーの値の表です。

会社	サーバー見出し：
Apps4All	nginx / 1.0.15
バドゥー	nginx
ボックスの概要	nginx / 1.2.1
Devconf	nginx / 1.0.15
e-Legion Ltd.	nginx / 1.0.5
Ibm	IBM_HTTP_Server
Intel	Microsoft-IIS / 7.5
ジェットブレイン	nginx
KolibriOSプロジェクトチーム	lighttpd / 1.4.32
Mail.Ruグループ	nginx / 1.2.5
マイクロソフト	Microsoft-IIS / 7.5
Opera Software ASA	nginx
ルソニックス	nginx
UIDG	アパッチ
Zfortグループ	nginx / 1.4.1
VimpelCom（ビーライン）	Microsoft-IIS / 7.5
モシグラ	nginx / 1.4.1
ノルダビンド	nginx / 1.0.4
ヤンデックス	nginx / 1.2.1

リクエスト2

最初のタイプのリクエストのバリアントですが、絶対パスではなく、完全なアドレスを指定します。

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：domain.name

このリクエストに応えて、すべてのサーバーが再び全会一致を示しました。「ライト」は、各サーバーが解析方法を知っていることを要求します。

リクエスト3

「Host：」なしの絶対パスでのHTTP / 1.0のリクエスト。「HTTP / 1.0 200 OK」を取得する必要があります。

  GET /path/to/resource.html HTTP / 1.0

3番目の要求で、サーバーは「シャワー」を浴びました。また、単一のHTTP / 1.0 200 OK応答はありません。

会社	サーバー応答
Apps4All	HTTP / 1.1 301が永続的に移動しました
バドゥー	HTTP / 1.1 302が一時的に移動しました
ボックスの概要	HTTP / 1.1 200 OK
Devconf	HTTP / 1.1 404が見つかりません
e-Legion Ltd.	HTTP / 1.1 301が永続的に移動しました
Ibm	HTTP / 1.1 200 OK
Intel	HTTP / 1.0 400不正なリクエスト
ジェットブレイン	HTTP / 1.1 301が永続的に移動しました
KolibriOSプロジェクトチーム	HTTP / 1.0 404が見つかりません
Mail.Ruグループ	HTTP / 1.1 200 OK
マイクロソフト	HTTP / 1.1 200 OK
Opera Software ASA	HTTP / 1.1 404が見つかりません
ルソニックス	HTTP / 1.1 301が永続的に移動しました
UIDG	HTTP / 1.1 404が見つかりません
Zfortグループ	HTTP / 1.1 404が見つかりません
VimpelCom（ビーライン）	HTTP / 1.1 302リダイレクト
モシグラ	HTTP / 1.1 404が見つかりません
ノルダビンド	HTTP / 1.1 200 OK
ヤンデックス	HTTP / 1.1 404が見つかりません

リクエスト4

前のリクエストですが、「Host：」を追加します。最初のリクエストとはプロトコルバージョンのみが異なります。

  GET /path/to/resource.html HTTP / 1.0
ホスト：domain.name

ホストはサーバー上で非常に前向きに行動しました-誰もが「200 OK」の応答を返しましたが、HTTP / 1.0を持っているのはIntelとKolibriOSプロジェクトチームのみでした。

リクエスト5

「ホスト：」なしの完全なアドレスを持つHTTP / 1.0の要求。「HTTP / 1.0 200 OK」を読むといいでしょう。

  GET http://domain.name/path/to/resource.html HTTP / 1.0

この図は、前のクエリの結果と完全に一致していますが、e-Legion Ltd. 「HTTP / 1.1 500内部サーバーエラー」が発行されました。

リクエスト6

前のリクエストですが、「Host：」を追加します。 2番目の要求と異なるのは、プロトコルバージョンのみです。

  GET http://domain.name/path/to/resource.html HTTP / 1.0
ホスト：domain.name

結果は4番目のクエリと完全に一致します。つまり、「Host：」はe-Legion Ltd.サーバーの内部エラーを修正しました。

リクエスト7

完全なアドレスを持つ2番目のリクエストのバリアントですが、「Host：」には存在しないサブドメインを記述します。要求は完全に正しいため、サーバーは「HTTP / 1.1 200 OK」で応答する必要があります。

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：void.domain.name

リクエスト8

ここで、「Host：」として、存在しないドメインを指定します。リクエスト内で何も変更されていませんが、一部のサーバーはそれを気に入らないかもしれません。

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：local.fake

リクエスト9

「Host：」ヘッダーは完全に無視する必要があるため、多くのパスワードがうらやむような任意のテキストを記述します。標準に従って、「HTTP / 1.1 200 OK」が期待されます。

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：l-IjFN = fiG（w + J2p：＃。{92！M`d ^？

サーバー7-9は、次のようにリクエストに等しく応答しました。

会社	サーバー応答	サーバー見出し：
Apps4All	HTTP / 1.1 200 OK	nginx / 1.0.15
バドゥー	HTTP / 1.1 200 OK	nginx
ボックスの概要	HTTP / 1.1 200 OK	nginx / 1.2.1
Devconf	HTTP / 1.1 500内部サーバーエラー	nginx / 1.0.15
e-Legion Ltd.	HTTP / 1.1 500内部サーバーエラー	nginx / 1.0.5
Ibm	HTTP / 1.1 200 OK	IBM_HTTP_Server
Intel	HTTP / 1.0 400不正なリクエスト	AkamaiGHost
ジェットブレイン	HTTP / 1.1 200 OK	nginx
KolibriOSプロジェクトチーム	HTTP / 1.1 200 OK	lighttpd / 1.4.32
Mail.Ruグループ	HTTP / 1.1 200 OK	nginx / 1.2.5
マイクロソフト	HTTP / 1.1 200 OK	Microsoft-IIS / 7.5
Opera Software ASA	HTTP / 1.1 200 OK	nginx
ルソニックス	HTTP / 1.1 200 OK	nginx
UIDG	HTTP / 1.1 200 OK	アパッチ
Zfortグループ	HTTP / 1.1 200 OK	nginx / 1.4.1
VimpelCom（ビーライン）	HTTP / 1.1 200 OK	Microsoft-IIS / 7.5
モシグラ	HTTP / 1.1 200 OK	nginx / 1.4.1
ノルダビンド	HTTP / 1.1 200 OK	nginx / 1.0.4
ヤンデックス	HTTP / 1.1 200 OK	nginx / 1.2.1

リクエスト10

間違ったリクエストの最初。正しい「Host：」を送信しますが、完全なアドレスに存在しないサブドメインを追加します。

  GET http://fake.domain.name/path/to/resource.html HTTP / 1.1
ホスト：domain.name

エラーのあるクエリが開始されたので、結果は恐ろしくありません。

会社	サーバー応答
Apps4All	HTTP / 1.1 301が永続的に移動しました
バドゥー	HTTP / 1.1 301が永続的に移動しました
ボックスの概要	HTTP / 1.1 200 OK
Devconf	HTTP / 1.1 404が見つかりません
e-Legion Ltd.	HTTP / 1.1 301が永続的に移動しました
Ibm	HTTP / 1.1 200 OK
Intel	HTTP / 1.1 200 OK
ジェットブレイン	HTTP / 1.1 301が永続的に移動しました
KolibriOSプロジェクトチーム	HTTP / 1.1 404が見つかりません
Mail.Ruグループ	HTTP / 1.1 200 OK
マイクロソフト	HTTP / 1.1 200 OK
Opera Software ASA	HTTP / 1.1 404が見つかりません
ルソニックス	HTTP / 1.1 301が永続的に移動しました
UIDG	HTTP / 1.1 404が見つかりません
Zfortグループ	HTTP / 1.1 404が見つかりません
VimpelCom（ビーライン）	HTTP / 1.1 302リダイレクト
モシグラ	HTTP / 1.1 301が永続的に移動しました
ノルダビンド	HTTP / 1.1 200 OK
ヤンデックス	HTTP / 1.1 404が見つかりません

サーバーのほぼ3分の1は、正しいパス（リダイレクト）を提案しようとして時間を無駄にしませんでした。残念ながら、多くのサーバーは単にメインページにリダイレクトします。

リクエスト11

次に、存在しないドメインを送信してみます。

  GET http：//local.fake/path/to/resource.html HTTP / 1.1
ホスト：domain.name

ここでの結果は以前のリクエストと完全に一致していますが、Mosigraではなく「HTTP / 1.1 301 Moved Permanently」が既に「HTTP / 1.1 404 Not Found」を発行しています。

リクエスト12

しかし、任意のテキストはドメインとしてまったく機能しますか？

  GET http：// l-IjFN = fiG（w + J2p：＃。{92！M`d ^？/パス/ to / resource.html HTTP / 1.1
ホスト：domain.name

応答「HTTP / 1.1 200 OK」は、IntelおよびOpera Software ASAから送信されました。 IBMとMosigraはHTTP / 1.1 404 Not Foundを返しました。他の人はすべて、ヘッダーのない部分（HTTP / 1.0で可能なオプション）で404 Bad Requestを書きました。

リクエスト13

11番目のリクエストのコピーですが、「Host：」としてサブドメインもあります。他の誤った組み合わせをチェックすることはほとんど意味がありません。

  GET http：//local.fake/path/to/resource.html HTTP / 1.1
ホスト：void.domain.name

結果はリクエスト11のコピーにもなりましたが、Intelは降伏して「HTTP / 1.0 400 Bad Request」を返しました。

リクエスト14

2番目の要求。ただし、完全なアドレスを指定するときに存在しないプロトコルを使用します。間違いがすでにあるに違いありません。

  GET habr：//domain.name/path/to/resource.html HTTP / 1.1
ホスト：domain.name

かなりの数のサイトがHABRプロトコルを受け入れていることが判明しました。

会社	サーバー応答
Apps4All	HTTP / 1.1 200 OK
バドゥー	HTTP / 1.1 200 OK
ボックスの概要	HTTP / 1.1 200 OK
Devconf	HTTP / 1.1 200 OK
e-Legion Ltd.	HTTP / 1.1 200 OK
Ibm	HTTP / 1.1 200 OK
Intel	HTTP / 1.0 400不正なリクエスト
ジェットブレイン	HTTP / 1.1 200 OK
KolibriOSプロジェクトチーム	HTTP / 1.1 301が永続的に移動しました
Mail.Ruグループ	HTTP / 1.1 200 OK
マイクロソフト	HTTP / 1.1 400の悪いリクエスト
Opera Software ASA	HTTP / 1.1 400 BAD_REQUEST
ルソニックス	HTTP / 1.1 200 OK
UIDG	HTTP / 1.1 200 OK
Zfortグループ	HTTP / 1.1 200 OK
VimpelCom（ビーライン）	HTTP / 1.1 400の悪いリクエスト
モシグラ	HTTP / 1.1 400 BAD_REQUEST
ノルダビンド	HTTP / 1.1 200 OK
ヤンデックス	HTTP / 1.1 200 OK

リクエスト15

最終的にサーバーの抵抗を打ち破り、前のリクエストを送信しようとしますが、サブドメインは間違っています。

  GET habr：//void.domain.name/path/to/resource.html HTTP / 1.1
ホスト：domain.name

結果は10番目のクエリに似ていますが、変更点もあります。

会社	リクエスト10	リクエスト15
Apps4All	HTTP / 1.1 301が永続的に移動しました	HTTP / 1.1 301が永続的に移動しました
バドゥー	HTTP / 1.1 301が永続的に移動しました	HTTP / 1.1 301が永続的に移動しました
ボックスの概要	HTTP / 1.1 200 OK	HTTP / 1.1 200 OK
Devconf	HTTP / 1.1 404が見つかりません	HTTP / 1.1 404が見つかりません
e-Legion Ltd.	HTTP / 1.1 301が永続的に移動しました	HTTP / 1.1 301が永続的に移動しました
Ibm	HTTP / 1.1 200 OK	HTTP / 1.1 200 OK
Intel	HTTP / 1.1 200 OK	HTTP / 1.0 400不正なリクエスト
ジェットブレイン	HTTP / 1.1 301が永続的に移動しました	HTTP / 1.1 301が永続的に移動しました
KolibriOSプロジェクトチーム	HTTP / 1.1 404が見つかりません	HTTP / 1.1 301が永続的に移動しました
Mail.Ruグループ	HTTP / 1.1 200 OK	HTTP / 1.1 200 OK
マイクロソフト	HTTP / 1.1 200 OK	HTTP / 1.1 400の悪いリクエスト
Opera Software ASA	HTTP / 1.1 404が見つかりません	HTTP / 1.1 400 BAD_REQUEST
ルソニックス	HTTP / 1.1 301が永続的に移動しました	HTTP / 1.1 301が永続的に移動しました
UIDG	HTTP / 1.1 404が見つかりません	HTTP / 1.1 404が見つかりません
Zfortグループ	HTTP / 1.1 404が見つかりません	HTTP / 1.1 404が見つかりません
VimpelCom（ビーライン）	HTTP / 1.1 302リダイレクト	HTTP / 1.1 400の悪いリクエスト
モシグラ	HTTP / 1.1 301が永続的に移動しました	HTTP / 1.1 400 BAD_REQUEST
ノルダビンド	HTTP / 1.1 200 OK	HTTP / 1.1 200 OK
ヤンデックス	HTTP / 1.1 404が見つかりません	HTTP / 1.1 404が見つかりません

リクエスト16

任意のドメインを使用してみましょう。

  GET habr：//local.fake/path/to/resource.html HTTP / 1.1
ホスト：domain.name

結果は前のクエリと一致しました。

リクエスト17

そして、3回目は、ドメインを任意のテキストに置き換えようとします。

  GET habr：// l-IjFN = fiG（w + J2p：＃。{92！M`d ^？/パス/ to / resource.html HTTP / 1.1
ホスト：domain.name

サーバーからの単一の肯定的な応答ではありません。リクエスト12と比較すると、次のサイトに変更があります。

会社	リクエスト12	リクエスト17
Intel	HTTP / 1.1 200 OK	HTTP / 1.0 400不正なリクエスト
KolibriOSプロジェクトチーム	HTTP / 1.1 400の悪いリクエスト	HTTP / 1.1 301が永続的に移動しました
Opera Software ASA	HTTP / 1.1 200 OK	HTTP / 1.1 400 BAD_REQUEST
モシグラ	HTTP / 1.1 404が見つかりません	HTTP / 1.1 400 BAD_REQUEST

リクエスト18

では、正しい「Host：」ヘッダーを削除してみましょう。

  GET habr：// l-IjFN = fiG（w + J2p：＃。{92！M`d ^？/パス/ to / resource.html HTTP / 1.1
ホスト：local.fake

前の結果から1つだけ変更があります-KolibriOS Project Teamサーバーは、「HTTP / 1.1 301 Moved Permanently」ではなく「HTTP / 1.1 404 Not Found」を返し始めました。

リクエストN

他のクエリオプションを試してみたい場合に書いてください。そして、あなたは自分でそれを行うことができます。

おわりに

結果のいくつかを要約してみましょう。レビューしたサーバーのほぼすべてがHTTP / 1.1リクエストに正しく応答しました。例外はDevConf、e-Legion Ltdでした。とIntel。最初の2つはnginxを使用しているため、問題はおそらくその構成にあります。 IntelはAkamaiGHostを使用していますが、これは不適切に構成されているか、HTTP / 1.1のサポートが不十分です。テストに正しく合格した理由の1つはnginx（19台のサーバーのうち14台で使用された）であると認めます。バージョンの違いにより、UIDGのnginx / 1.0.10とnginx / 1.4.1のチェーンが発見されました。

あなたはすべてがシンプルだと思いますか？ SEOを念頭に置いてApacheをセットアップしてみて、誤った「Host：」のリクエストを正しく処理し、クエリ文字列の完全なアドレスのみに基づいてください。

「間違った」正しいクエリの実際的な意味は何ですか？脆弱性が見つかる可能性があるとは思わない。しかし、実際には、ほぼ15年間で、誰も正しいHTTP / 1.1サーバーを作成する方法を学んでいませんか？

PS Apache mod_rewriteの％{REQUEST_URI}とPHPの$ _SERVER ["REQUEST_URI"]の違いを覚えておいてください。

UPD1：

リクエスト19

AEPのアドバイスで、2番目の要求を受け取りましたが、ホストに別のゼロバイトと文字列を追加しました。これは、サーバーがゼロバイトのホストをどれだけうまく無視するかにかかっていました。

  GET http://domain.name/path/to/resource.html HTTP / 1.1
ホスト：domain.name {zero byte} fake_and_void

次のテンプレートをスクリプトに追加しました。

 http_check(title, '19', parts[1], 'GET http://' + parts[1] + parts[2] + ' HTTP/1.1', parts[1] + '\0fake_and_void_text');

IBM、Opera Software ASA、およびMosigraを除き、すべてのサーバーが「HTTP / 1.1 400 Bad Request」を返しました。

要求にゼロバイトを追加しようとしたときに、IBMとOpera Softwareを除いて、全員が400エラーを報告しました。

両面のREQUEST_URIまたは正しいHTTP / 1.1サーバーを探している

理論