問題タブ [rfc2616]

httpリダイレクトの場合、たとえば302の場合、新しいページの完全なURLを返す必要がありますか？http://または、ルートURLに相対アドレスのみを送信することは可能/my/viewですか？

https://www.rfc-editor.org/rfc/rfc2616#section-10.3.3でrfc2616を読み込もうとしましたが、明示的なものを見つけることができました。

また、これに関する既知のブラウザのバグはありますか？

私はブラウザの履歴対キャッシングとRFC2616 13.13の問題全体に頭を悩ませようとしてきました

RFC のこのセクションは、たとえば、ユーザーがブラウザーで「戻る」場合、ユーザーが別の方法で構成していない限り、キャッシュ ディレクティブを無視して、常にローカル ストレージからページを表示する必要があることを意味しますか?

履歴をナビゲートするときにページをリロードするブラウザーは、キャッシュ ディレクティブがそうするように指示していても、仕様に準拠していませんか? 仕様では、これは悪いことであると述べています。「これにより、サービスの作成者は、HTTP の有効期限制御とキャッシュ制御を使用したいときに使用を避けるように強制される傾向がある」からです。

また、ディレクティブがブラウザにキャッシュしないように指示する場合がありますが、たとえば を使用してCache-Control: no-store、それを履歴キャッシュに保存できますか/保存する必要がありますか?

私が読んだ限りでは、Opera を除いて、ほとんどのブラウザは標準に違反しているようです。これは、履歴からの機密データを含むページの再表示に関するセキュリティ上の懸念が、標準で述べられている問題よりも重要であると見なされているためですか?

誰かがこの分野についていくつかの光/説明を与えることができれば、私は感謝しています。

バックグラウンド

デバイスの安全なリモート構成を目的として、ハードウェアの内部に配置されるHTTPSサーバーを実装しました。これを実現するために、既存の軽量組み込みTCP/IPスタックをオープンソースSSLライブラリと一緒に使用しました。その上にあるWebサーバーは、私が完全にゼロから作成したものです。（これは車輪の再発明のように見えるかもしれませんが、私たちの目的のためには、非常に軽量で、特定の機能のセットが非常に狭い必要があります。たとえば、使用している組み込みRTOSやROM「ファイルシステム」との互換性。これは、HTTP（S）セッションとSSLコンテキストで利用できるのは数百キロバイトで、数メガバイトではないシステムです。すべてのことを検討し、他のさまざまな製品を検討した後、独自の製品を作成することは理にかなっています）。このWebサーバーは、5〜10個の同時ソケット接続（つまり、5〜10個の同時または永続的なHTTP接続）のみをサポートする必要があります。これは、ハードウェアが処理できる量とほぼ同じです。ボックスを管理するために1人か2人だけがアクセスできるように設計されているため、これは問題ありません。

現在、すべてがうまく機能しています。HTTP1.1に必要と思われるRFC2616をできるだけ多く実装するようにコーディングしました。現時点では、5つのHTTPSポート（443）でリッスンしているだけで、ポート80からリダイレクトするものはまだ実装していません。

最初の質問-リダイレクト

HTTPからHTTPSへのリダイレクトに関する記事を数え切れないほど見ましたが、これを行うために既存および従来のWebサーバーを構成する方法に関する記事を読んだことがあります。私が解決したいのは、これをプログラムで実装する必要があるため、プロトコルレベルでどのような手法が使用されているかです。

一般的な方法は、301/302応答を発行することのようです。したがって、私が考えていた戦略は、例として、8つの同時リクエストのリソースがあると仮定した場合です。

• ポート443でHTTPS接続をリッスンします。最大6つの同時HTTPS接続（6つのソケット）が利用可能です。

• ポート80でHTTP接続をリッスンし、最大2つのHTTP接続（したがって、ポート80で2つのソケット）を使用できます。ポート80のソケットの場合、実際のWebサーバーには実際にはアクセスされません。\r\n\r\n代わりに、またはが表示されるまで（要求ヘッダーの終わりを示す）ソケットから読み取りを続けてから、\n\n301（または302）応答を返します。これは、私のコードではほとんどハードコードされたconst char*文字列です。次に、ソケットを閉じます。これらの2つのポート80ソケットは、純粋にリダイレクトの目的で存在します。

この戦略は賢明に聞こえますか？

現時点で私が確信していないのは、301/302応答にリダイレクトURLが含まれていることだけです。このハードウェアの「ボックス」は、家の中やルーターの後ろに置いて、ダイナミックDNSサービスなどを介してアクセスできるデバイスです。では、プログラムで「外の世界」に相当するHTTPSURLを決定するにはどうすればよいでしょうか。おそらく、リクエストURIとhost:元のHTTPリクエストヘッダーのフィールドの組み合わせを使用することによってですか？

上記で問題が発生した場合は、代わりにHTMLの小さな部分を提供することをお勧めします。これには、ブラウザーからURLを取得することでHTTPSリダイレクトを実行するJavaScriptが少し含まれています（具体的には、どのJavaScriptメソッドを使用しますか）。これを行うために私は手に負えないことを思い出せませんが、私はそれを何年も前にやりました）。（現時点では、指定できる特定のドメインがないことを考えると、SSL証明書がどのように機能するかはわかりませんが、後で、おそらく別のSOの質問でそのブリッジを通過する予定です。）

2番目の質問-HTTPとHTTPSを提供する

これはおそらく、プログラミングの質問というよりも、設計の質問の方がはるかに多いか、顧客が何を望んでいるのかということですが、とにかくここに入れて、人々の意見を確認したいと思いました。私の問題は、クライアントがボックスに「SSLが必要」と単純に述べていることですが、それ以上のものではありません。たとえば、SSLを使用するかどうかをエンドユーザーに選択できるようになることを期待しているかどうかはわかりません。実際に質問する前に、何が質問されるかを予想しているだけなので、事前に知識と答えを身に付けておきたいと思います。言い換えれば、この仕様を書いている人々は「南京錠を見たいだけ」と「SSLが欲しい」ということです。これは明らかに良いことです。

まず第一に、SSLを使用した中途半端な解決策のようなものはないことを私は知っています。つまり、すべてを持っているか、何も持っていない必要があります。つまり、HTTPSを介して重要なものを提供することで、小さなプロセッサが実行する必要のある作業を減らすことにしたが、HTTPを介して画像とCSSファイルを提供するとします。いくつか読んだ後、私は今、これが多くの理由で絶対にノーノーである理由を正確に知っています。

ただし、最初のログインページでHTTPSまたはHTTPのいずれかを選択する機能をエンドユーザーに提供した場合はどうなりますか？「HTTPS」を選択すると、安全なHTTPSログインページにリダイレクトされます。これは、たとえば携帯電話からボックスにアクセスするときにアクセス速度を上げるために、ユーザーがセキュリティを侵害することを選択した場合に提供する便利なオプションです。この最初のページでは、「安全なログイン」と「標準の安全でないログイン-推奨されません」などの両方が提供される場合があります。明らかに、これはユーザーに関する限り脆弱性を開きますが、SSL接続も危険にさらしますか？つまり、この最初のログインページはHTTP経由で提供される必要があるため、おそらく攻撃者は理論的にはボタンを入れ替えるようにそれを壊す可能性があります-そのようなことです。したがって、HTTPSはHTTPSを意味する必要があります最初から？私がHTTPSをこのことに靴べらにして機能させることができ、それが最新のブラウザー（IE8 / 9、FF）で使用するように特別に設計されていることを考えると、通常のHTTPアクセスが必要な実際的な理由はありますか？代替として提供されますか？

HTTP 1.1 RFC（2616）のセクション19.3「トレラントアプリケーション」は、HTTPクライアントアプリケーションからの日付の解析について次のように述べています。

HTTPヘッダーがGMT以外のタイムゾーンの日付値を誤って保持している場合は、可能な限り最も保守的な変換を使用してGMTに変換する必要があります。

2つの質問：

1. これは、サーバーがGMT以外の日付値をGMTに変換する必要があることを意味しますか？または、（オプションで）GMT以外の日付値を（拒否するのではなく）GMTに変換することを選択した場合、可能な限り最も保守的な変換を使用する必要があることを意味しますか？

2. 「可能な限り最も保守的な変換」とはどういう意味ですか？

編集これは今では古い質問ですが、誰かがそれを持っているなら、私はまだ答えを知ることに興味があります。

RFC 2616を読んでいて、すべてのhttpパケットを確認したいと思います。これに最適なツールはどれですか？

私は現在、特定のリソースに対する同時 GET リクエストを禁止することが RFC 2616 (特に、GET メソッドに必要な冪等性と安全性プロパティ、§9.1) に違反するかどうかについて議論しています。

例えば; サーバーが GET /data/?dataId=123456 を同時に 2 回受信した場合、一方または両方の要求がエラー メッセージを返すことは、安全性または冪等性の違反と見なされますか?

私の理解によると、RFC では、同じ要求が再度呼び出されたときに同じ結果が得られるように指定されています。ただし、同時リクエストに関してどのような動作が許容されるかについては何も見ていません。

私の感じでは、同時 GET アクセスを許可しないこと (もちろん一般的な規則としてではなく、特定のリソースで) は RFC の違反にはなりません。423 応答コード、または 500 (あまりエレガントではありませんが)、または 429 または 420 (意味は少し異なりますが) を返すことは、私には受け入れられるようです。

ただし、RFCがこの立場を否定していることを証明する有効な議論があるかどうかを知りたい.

よろしくお願いいたします。

Cache-Control: no-cachevsを使用した HTTP 応答の違いは何Cache-Control: max-age=0, must-revalidate, proxy-revalidateですか?

ブラウザはそれを同一のものとして扱いますか?

2つのURIを比較して一致するかどうかを判断する場合、クライアントは 、次の例外を除いて、URI
全体の大文字と小文字を区別するオクテットごとの比較を使用する必要があります。

上記のHttpRfcの文を読みました。URLでは大文字と小文字が区別されないと思いますが、それが何を意味するのか理解できませんか？