私はHTTPプロトコル（リクエスト）レスポンスとそれがどのように機能するかについて読んでいました。私がまだ理解していないことが2つあり、最初にいくつかの説明を取得したいのですが、HTTPプロトコルが要求/応答として設計されたのはなぜですか？それの利点は何ですか？または他のオプションがありましたか？2つ目は、このプロトコルがWebアプリケーションのセキュリティにどのように影響するかです。httpsは暗号化を使用しているため、より安全であることを知っていますが、httpがまったく安全ではないという意味ですか？（GETなどではなくPOSTを使用している場合でも）
ありがとう！！！
安全なWebアプリケーションを開発する場合に注意すべき多くの問題があります。HTTP1.xと2.xの両方に関連していました。以下のセキュリティ問題の例をアプリケーションで実行する必要があります： https ：//www.owasp.org/index.php/Category：OWASP_Top_Ten_Project
私の知る限り、HTTP は主にドキュメントをフェッチして読み取るように設計されています。これは遠距離でのやり取りには最適なプロトコルではありませんが、HTTP サーバーに必要なドキュメントを伝え、それを受信するのは良いことです。そして、それがまさにインターネットの始まりです。誰でもアクセスできるはずの多数のドキュメントです。開発は 1989 年に CERN で開始され、科学と大学のドキュメントを共有することが主なタスクでした。
HTTPS から得られる唯一の利点は、リクエストとレスポンスの両方が暗号化されることです。つまり、クライアントとサーバー以外の誰も、両者が何について通信したかを知ることができないということです。しかし、私は現在 HTTP クライアントを開発しているので、GET とは対照的に POST からのセキュリティ上の利点は見られません (もちろん、一部のクライアント側スクリプト (javascript) が要求コンテンツにアクセスできない場合を除きます)。
全体として、HTTP は Web サイト全般に最適なプロトコルではないと思いますが、幅広い機能をサポートするのは良いことです。なぜなら、HTTP を使用すると、最も複雑で動的な Web サイトだけでなく、静的ドキュメントも実装できるからです。
/編集
HTTP が安全でないとはまったく思いません。さて、どのような場合に安全ではないのでしょうか? 一部のソフトウェアがどのリソースがどのパラメータで要求されたかを知る可能性しかありませんが、それが問題になるかどうかは関係ありません: 他のプロトコル (暗号化されたプロトコルを除く) は同じ問題に直面します。
また、HTTP 1.1 標準が 1999 年に公開されたので、彼らはついに HTTP 2.0 と呼ばれる新しいバージョンに取り組んでいます。これは (2012 年 11 月の RFC によると) Google の SPDY (スピーディーと発音) プロトコルのほぼコピーであり、より高速です。 HTTP 1.1。
残念ながら、Google が立ち上げたデモンストレーション ページを見つけることができませんでしたが、新しいプロトコルは、特に多くの小さなリソース (アイコンなど) を読み込む場合に高速です。