私のウェブサイトの一部はHTTPS経由でのみアクセス可能であり（ウェブサイト全体ではなく、セキュリティとパフォーマンスの妥協）、プレーンHTTP経由で送信された場合、安全な部分へのリクエストに対してHTTPSが302リダイレクトで適用されます。
問題は、すべての主要なブラウザで、POSTで302リダイレクトを実行すると、自動的にGETに切り替えられることです（これは303でのみ発生するはずですが、誰も気にしないようです）。追加の問題は、すべてのPOSTデータが失われることです。
では、HTTPを介してサイトを保護するためのPOSTを受け入れ、後でリダイレクトするか、コードの負荷を変更して、Webサイトの一部を保護するためのすべての投稿が最初からHTTPSを経由するようにする以外に、ここでの私のオプションは何ですか？
あなたは正しいです、これが唯一の信頼できる方法です。POSTリクエストは、最初からhttps接続を経由する必要があります。さらに、そのようなPOSTにつながるフォームもhttps経由でロードすることをお勧めします。通常、その後のhttps接続の最初のフォームはログインフォームです。httpおよびhttpsを介してロードされたページに異なるセキュリティ制限を適用するすべてのブラウザ。したがって、これにより、適切なデータを所有するコンテキストで悪意のあるスクリプトを実行するリスクが低下します。
それが307の目的だと思います。 RFC2616は次のように述べています。
GETまたはHEAD以外の要求に応答して307ステータスコードを受信した場合、ユーザーが確認できない限り、ユーザーエージェントは要求を自動的にリダイレクトしてはなりません。これにより、要求が発行された条件が変わる可能性があります。
しかし、302についても同じことが言え、そこで何が起こるかはわかっています。
残念ながら、RFCのように応答コードを処理しないブラウザよりも大きな問題があり、それはHTTPの動作に関係しています。簡略化すると、プロセスは次のようになります。
おそらく、ユーザーは自分の投稿で機密情報を送信しているので、暗号化を使用する必要があります。ただし、リダイレクト応答（ステップ3）をユーザーの暗号化されていないPOST（ステップ1）に送信した場合、ユーザーはすでにすべての機密情報を暗号化されていない状態で送信しています。
ユーザーが送信する情報を機密情報とは見なさず、送信する応答のみを機密情報と見なす可能性があります。ただし、これは意味がありません。機密情報は特定の個人のみが利用できるようにする必要があり、ユーザーの認証に使用される情報は必然的にリクエストの一部になります。つまり、応答は誰でも利用できるようになります。したがって、応答が機密である場合、要求も機密です。
すべての安全な投稿がHTTPSを使用するように、多くのコードを変更したいと思うようです（おそらく、そもそもそのように記述しておく必要があります）。また、HTTPSでWebサイトの一部のみをホストするという決定を再検討することもできます。インフラストラクチャがすべてのHTTPS接続を使用して処理できないことを確認しますか？できると思います。そうでない場合は、おそらくアップグレードの時期です。