この頁では、HTTP通信を構成するソフトウェアについて、RFC 2616で定義されている「クライアント」「（オリジン）サーバ」「プロクシ（プロキシ）」について解説します。
HTTPでは、クライアントという用語と、それによく似た意味を持つユーザエージェントという用語が定義されています。 しばしば、この二つの語は同義語として扱われたり、または意味を取り違えられたりしますが、本来は以下のような意味を持ちます。 RFC 2616のsection 1.3をご覧下さい。
- クライアント {client}
- リクエストを送信する目的でコネクションを確立するプログラム。
- ユーザエージェント {user agent}
- リクエストを発行するクライアント。 これらはしばしば、ブラウザ、エディタ、スパイダ (web ロボット)、あるいはその他のエンドユーザツールである。
まず、「クライアント」についてです。 クライアントの定義の中で記述されている「コネクション」とは、TCP接続を指しています。 つまり、言葉通りに解釈すると、クライアントとは、HTTP通信が行えるように、前もって（仮想的）通信路を確保するという作業を行うプログラムということになります。
これに対し、ユーザエージェントとは、クライアントが確保した通信路上で、HTTPリクエストを発行するプログラムです。 たとえば、ユーザエージェントには、以下のようなものがあります。
前節で、「クライアントは、サーバとコネクションを確立するプログラムである」と記述しましたが、コネクションを確立するためにOSが提供している仕組みとしてソケットというものがあります。 ソケットは、元々4.2 BSD向けに開発された技術ですが、現在はその他のOSでも利用できるようになっています。 特に、Windows上のソケットはWinsockと呼ばれています。
（※） ソケットには、「ストリームソケット」と「データグラムソケット」の2種類があり、HTTPでは通信にTCP/IPを利用するので、HTTPアプリケーションを実装する際には「ストリームソケット」を利用することになります。 この節では、“ソケット”は「ストリームソケット」を指すものとします。
以下に、ソケットによる通信の手順を示します。
HTTPクライアントは、HTTPサーバがlisten()しているポート番号に対して、connect()を行うことによって、接続を確立します。
クライアントとの接続が確立したら、サーバはaccept()を実行します。
接続を終了する場合は、close()にてソケットを閉じます。
HTTP/1.0では「接続の終了＝データ送信の完了」とすることができますが、HTTP/1.1では持続的接続という仕組みが取り入れられたので、1つのソケットを使って何度も通信を行うことができる代わりに、データ送信時は常にデータの長さを明示しなければなりません。
ユーザエージェントは、HTTPヘッダという仕組みを使って、サーバに対して情報を送信することができますが、その中に「ユーザエージェントに関する情報」も含まれています。 その中で、最も代表的なものがUser-Agentヘッダです。 これは、その名の通り「ユーザエージェントそのものに関する情報」を送るために使用されます。 RFC 2616のsection 14.43をご覧下さい。
User-Agent リクエストヘッダフィールドは、リクエストを生成したユーザエージェントについての情報を含む。 これは、統計目的、プロトコル違反の追跡、特定のユーザエージェントの制限を回避するようなレスポンスを作成するためのユーザエージェントの自動認識のために使う。 ユーザエージェントは、リクエストの際にこのヘッダを含むべきである。 このフィールドには、複数の製品トークン (section 3.8) や、エージェントやユーザエージェントの重要な付属製品を識別するためのコメントを含める事ができる。 慣習によれば、製品トークンはアプリケーションを識別するために重要な順に列挙される。
User-Agent = "User-Agent" ":" 1*( product | comment )
このヘッダでは、製品トークンというものが使用されます。 製品トークンに使用できる値はそれぞれ決まっており、そのフォーマットに違反するような製品トークンを使用した場合、文字化けやフィルタリングなどにより、通信相手に内容が正しく伝わらない可能性があります。 以下に、フォーマット仕様を違反しているUser-Agentヘッダの例を示します。
productとcommentをSP（スペース）で区切っていない（※1） メールアドレスを通知するためにはFromヘッダを使います。
（※2） この場合の「日本語」とは、ISO-2022-JPなどの文字セットを用いて記述されたものを指します。 User-Agentヘッダに“日本語”を用いたい場合は、Base64エンコードやパーセントエンコーディングなどの適切なエンコードを施さないと、HTTPのフォーマット仕様違反になります。
User-Agentヘッダのフォーマットが誤っていた場合、サーバがユーザエージェントを判別に失敗し、最悪の場合リソースが取得できなかったり、Webページができない可能性がありますので、HTTPクライアントの作成者は特に注意して値を決定しなければいけません。
多くのユーザエージェントは履歴メカニズムというものを持っています。 RFC 2616のsection 13.13をご覧ください。
ユーザエージェントはしばしば、"戻る" ボタンと履歴リストのような履歴メカニズムを持っていて、セッションにおいて以前に回収したエンティティを再表示するために使う事ができる。
履歴メカニズムとキャッシュは異なる。 特に履歴メカニズムはリソースの現在の状態の意味的に透過なビューを表示しようとはすべきではない。 むしろ、履歴メカニズムはリソースが回収された時刻を正確に表示するという意味を持つ。
既定では、有効期限は履歴メカニズムには適用されない。 もしそのエンティティがまだ保存していて、ユーザが特にエージェントを期限切れの履歴文書をリフレッシュするように設定していなければ、履歴メカニズムは例えエンティティの期限が切れていてもそれを表示すべきである。
これは、履歴システムがユーザにビューが古くなっているかもしれないという事を知らせる事を禁止すると解釈されるものではない。
注: もし履歴表メカニズムがユーザが古くなったリソースを見る事を不必要に妨げるのであれば、サービスの著者が別の方法を望む場合に、HTTP の期限制御とキャッシュ制御を強制的に使わせないようにする傾向があるだろう。 サービスの著者は、ユーザが前もって回収したリソースを見るために (「戻る」のような) ナビゲーション制御を使う時にユーザがエラーメッセージや警告メッセージが見えない事を重要だと考えるかもしれない。 例え、時にそのようなリソースはキャッシュされるべきではなく、すぐに期限が切れるべきだとしても、不適当に機能している履歴メカニズムの影響のよって苦しまないためにユーザインターフェースはサービスの著者にキャッシングさせないようにするための別の方法 (例: "一度きりの" URL) に強制的に訴える事ができるように考慮されている。
先に紹介した多くのユーザエージェントには、履歴メカニズムが実装されています。 これは、ユーザがそのリソースを何時何分何秒に取得したかを示すためのものですが、履歴メカニズムを用いて過去に取得したリソースを表示する場合は、自身の中に保持するキャッシュを用いることができます。 この時、もしキャッシュの有効期限が切れていたとしても、そのキャッシュを使うことができますが、「このキャッシュは有効期限切れである」という旨は表示してもいいし、しなくてもかまいません。 有効期限切れであるリソースを利用させたくないサービス著者は、ユニークなクエリを持つURIを使用するなどして、キャッシュへ格納されることを回避することできます。
HTTPクライアントにはいろいろな種類がありますが、そのうち最もよく利用されるものは、Webブラウザ{browser}です。 “browse”という単語はもともと「ざっと見る」「拾い読みする」などという意味ですが、現在では「Webサイトを閲覧・巡回する」という意味の方が一般的になりました。
Webブラウザの歴史は、WWWの考案者であるTim Berners-Leeが世界最初のWebブラウザ「WorldWideWeb」を作った1990年に始まり、その後これまでに数えきれないほどのWebブラウザが開発されてきました。 その中にはすでに開発が終了したものもありますが、現在世界的に有名なWebブラウザには、以下のようなものがあります。 これらのブラウザだけで、全世界でのシェアの95%以上を占めています。
現在では、上記のWebブラウザを含むほぼすべてのWebブラウザが無料で利用可能（※）となっています。
（※） かつては、Webブラウザも、一般的なアプリケーションソフトウェアのように有償でした。 たとえば、現在はすでに存在しませんが、Netscape Navigatorというブラウザはバージョン4（の途中）まで有償バージョンが発売されていましたし、またOperaなどは「ブラウザの中に広告を表示する」という形態を取っていました。
現在、Webブラウザは、単にWeb上の情報を閲覧するという用途だけでなく、Webサーバ上に実装された様々なアプリケーション（たとえばスケジュールの管理ツールや、ワープロや表計算などのオフィススィートなど）を利用するためのツールとしても利用されています。 Webブラウザには、「HTTPを使ってネットワーク越しにリソースを取得する機能」のほかに、「JavaScriptやAdobe Flashなどを使ってリソースを動的に生成・加工できる機能」なども備わっているため、そのような機能が求められるアプリケーションの開発を一から行う必要がなく、開発が容易になるからです。 また、アプリケーションの利用者にとっては、Webブラウザさえあれば、専用のソフトをインストールする必要がないこと、また使い慣れたWebブラウザというソフトを利用するため、その機能を利用しやすいといったメリットもあります。
（※） このようなシステムは、一般にWebアプリケーションと呼ばれています。
サーバに関連する用語は、RFC 2616のsection 1.3にて定義されています。
- サーバ {server}
- レスポンスを送り返す事で、リクエストを処理するためのコネクションを受け入れるようなアプリケーションプログラム。 プログラムの中にはクライアントとサーバの両方の機能を持つものがある; しかし、ここではこの用語を、一般的なプログラムの機能というよりむしろ、特定のコネクションについてプログラムによって果たされる役割のみのために使用する。 同様に、各リクエストの性質に応じてその振る舞いを、オリジンサーバ、プロクシ、ゲートウェイ、トンネルと切り換えるサーバもある。
- オリジンサーバ {origin server}
- 指定されるリソースが存在するか、あるいは生成されるサーバ。
サーバとは、「リソース」を保持していて、リクエストが来た時にそれに従ってリソースを供給{serve}するものです。 ここでいう「リソース」とは、HTMLのような静的ファイル、あるいはCGIなどによって動的に生成されるデータなどの総称です。 そして、特にリソースの起点となるサーバ（リソースが格納されているサーバ、あるいはリソースが生成されるサーバ）を「オリジンサーバ」と呼びます。
2010年現在、世界には2億台以上ものWebサーバが存在すると言われていますが、その内50%以上がApache HTTP Server（略称：Apache）だと言われています。 Apacheは、NCSA（米国立スーパーコンピュータ応用センター）が開発したNCSA HTTPdを元に開発されたWebサーバですが、現在のApacheのコードは全て書き換えられており、完全なオリジナルとなっています。 現在公開されている Apache には“1.3系”、“2.0系”、“2.2系”があり、メインストリームは2.2系となっていますが、安定したバージョン、あるいは使い慣れているバージョンを求めて、あえて1.3系や2.0系を選択することもあります。
その次に利用されているWebサーバとして、約25%のWebサーバがMicrosoft社のIISであると言われています。 これは、同社のWindowsというOSに組み込んで使い、サーバに対する設定もWindowsのインタフェースを使って操作することができるため、企業などを中心に利用されているようです。
サーバは、ユーザエージェントと同じように、HTTPヘッダを使って「サーバに関する情報」をユーザエージェントに送ります。 その中で、最も代表的なものがServerヘッダです。 これは、その名の通り「サーバそのものに関する情報」を送るために使用されます。 RFC 2616のsection 14.38をご覧下さい。
Server レスポンスヘッダフィールドは、リクエストを処理するオリジンサーバが使っているソフトウェアについての情報を含んでいる。 このフィールドには、複数の製品トークン (section 3.8) や、サーバとその他の重要な付属製品を識別するためのコメントを含める事ができる。 製品トークンは、アプリケーションを識別するために重要な順に列挙される。
Server = "Server" ":" 1*( product | comment )例を見よ。
Server: CERN/3.0 libwww/2.17レスポンスがプロクシを通して送られた場合、プロクシアプリケーションは Server レスポンスヘッダを書き換えてはならない。 代わりに、 (section 14.45 に記述されている) Via フィールドを使うべきである。
注: サーバのソフトウェアバージョンを明らかにする事で、セキュリティホールを持っている事がわかっているソフトウェアを使うサーバのマシンは攻撃を受けやすくなるかもしれない。 サーバの開発者は、このフィールドをオプションとして設定を変更できるようにする事が推奨される。
Serverヘッダのフィールド値も、User-Agentと同じように、製品トークンが使用されています。 ただし、HTTPアプリケーションは、セキュリティの観点上、不用意に製品トークンを公開する前に注意を払う必要があります。 section 15.1.2をご覧下さい。
サーバの具体的なソフトウェアのバージョンを示す事によって、サーバマシンはあるセキュリティホールが知られているソフトウェアに対するアタックを受けやすくなるかもしれない。 実装者は、Server ヘッダフィールドを設定可能なオプションとすべきである。
たとえば、セキュリティホールが既に報告されているサーバソフトの場合、クラッカーは製品トークンによってそのソフトが利用されていることを知ることができ、そのソフト（あるいはそのソフトを利用するユーザ）を攻撃しようするかもしれません。 そのベストな対策方法は、セキュリティホールの対策が施されたアプリケーションへ更新することですが、対策済のアプリケーションが手に入らないなどの理由ですぐに更新することができない場合には、製品トークンを隠したり、適宜変更することで、安易な攻撃を避けることができるかもしれません。
WWW上に公開されているほぼ全てのWebサーバはクライアントからのアクセスをログとして記録しています。 サーバのログには、多くの個人情報が含まれており、セキュリティが甘ければ、個人情報の流出元となってしまいます。 RFC 2616のsection 15.1.1では、サーバログの管理の重要性について記述されています。
サーバは、読み込みの傾向や興味の対象で識別されるであろうユーザのリクエストについての個人情報を保存する立場にある。 この情報は本質的に明らかに秘密であり、その扱いは国によっては法によって統制されているであろう。 データを供給するために HTTP プロトコルを使用している人々は、そのようなデータは発行された結果、身元がわかってしまうその個人の許可無しには配布されないという事を保証しなければならない。
サーバログに記録される情報としては、たとえば以下のようなものがあります。 Apache HTTP Serverでの例を示します。
127.0.0.1 - - [01/Jan/2004:00:00:00 +0900] "GET /security.html HTTP/1.1" 200 28158 "http://www.studyinghttp.net/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" |<-(1)->| |<----------(2)----------->| |<-----------(3)----------->| |<-(4)->| |<-----------(5)------------>| |<----------------------(6)----------------------->|
（※） もちろんこれは一例なので、これ以外の情報が記録されている可能性もあります。
一般に、ユーザは特定のクライアントから操作を行う場合が多いので、特定のクライアントからのアクセス情報が明らかになってしまった場合、ユーザが特定され、それによりユーザは不都合な影響を被る可能性があります。 したがって、サーバ管理者はアクセスログの管理方法などについて、適切な「セキュリティポリシー」を設け、それを厳守しなければなりません。
HTTP通信では、HTTPリクエストを発行するクライアントと、HTTPリクエストを受信し、HTTPレスポンスを返すサーバの他に、それらを中継するプログラムがあります。 RFC 2616のsection 1.3をご覧ください。
- プロクシ {proxy}
- 他のクライアントの代わりとしてリクエストを行うためにサーバとクライアントの両方の役割を果たす中継プログラム。 リクエストは、可能な変換をもって、内部で処理されるか、あるいは他のサーバに渡される。 プロクシは、この仕様書が要求するクライアントとサーバの両方の機能を実装しなければならない。 "透過的プロクシ" とは、プロクシへの認証やクライアント自身の証明が要求されるようなもの以外のリクエストやレスポンスを修正しないようなプロクシである。 "透過的でないプロクシ" とは、ユーザエージェントに、ある種の翻訳、メディアタイプの変形、使用プロトコルの制限、匿名性向上のためのフィルタリング等のような、追加的サービスを提供するためにリクエストやレスポンスを修正するようなプロクシである。 その振る舞いが透過的であるか無いかが明言されている部分を除けば、それぞれのプロクシは HTTP プロクシとして必要な要素を共に持ち合わせている。
- ゲートウェイ {gateway}
- 他のサーバを中継するサーバ。 プロクシとは違い、ゲートウェイはまるでリクエストされたリソースのオリジンサーバのように、リクエストを受ける。 リクエストしたクライアントは、それをゲートウェイと通信しているという事を気付かないかもしれない。
- トンネル {tunnel}
- 二つの接続の間をまるで目隠しリレーを行う様に振る舞う中継プログラム。 一度起動したら、それが HTTP リクエストによるものであっても、トンネル自身は HTTP 通信における当事者とみなさない。 トンネルは中継する両端の通信が終了した時、終了する。
クライアントとサーバの中間に入り処理をするプログラムには、プロクシ（※）、ゲートウェイ、トンネルがあります。
（※） “proxy”は、「プロキシ」と書かれる場合が多いですが、このサイトでは「プロクシ」で統一しています。
「HTTP/1.1プロクシ」の条件は、「HTTP/1.1クライアントの条件」かつ「HTTP/1.1サーバの条件」を満たし、かつ、「HTTP/1.1プロクシ」の条件を満たすという、とても厳しいものになります。 そのような条件を満たしていないプロクシがHTTP/1.1を名乗ってしまうと、通信が破綻してしまう可能性があるので注意が必要です。
HTTP/1.1プロクシは、クライアント-サーバ間でリクエストを処理する場合、必ずViaヘッダをつけなければいけません。 RFC 2616のsection 14.45をご覧下さい。
Via 一般ヘッダフィールドは、リクエスト時におけるユーザエージェントからサーバ間の、またレスポンス時におけるオリジンサーバからユーザエージェント間の、中間のプロトコルと受信者を示すためにゲートウェイやプロクシによって使われなければならない。 これは、RFC 822 での "Received" フィールドに類似しており、転送されるメッセージを追跡したり、リクエストループを回避したり、リクエスト/レスポンス連鎖上のすべての送信者のプロトコル能力を識別したりする意図を持つ。
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version protocol-name = token protocol-version = token received-by = ( host [ ":" port ] ) | pseudonym pseudonym = token(中略)
複数の Via フィールド値は、それぞれがメッセージを転送したプロクシやゲートウェイを表す。 それぞれの受信者は、その結果がアプリケーションを転送する順序になるように末尾に自身の情報を付加しなければならない。
コメントは、User-Agent や Server 各ヘッダフィールドと同様に、受信プロクシやゲートウェイソフトウェアを識別するために Via ヘッダフィールド内で使う事ができる。 しかし、Via フィールド内のすべてのコメントは省略可能であり、他の受信者はそのメッセージを転送する前にそれを削除する事ができる。
例えば、リクエストメッセージが HTTP/1.0 ユーザエージェントから "fred" というコードネームの内部プロクシに送られ、これが HTTP/1.1 を使って nowhere.com にある公衆プロクシにリクエストを転送し、最後に www.ics.uci.edu というオリジンサーバにリクエストを転送する事で完了する場合を考える。 www.ics.uci.edu が受けるリクエストは、次のような Via ヘッダフィールドを持っているだろう。
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Viaヘッダは、クライアント-サーバ間で使用するプロトコルなどを示すために使用するHTTPヘッダなので、もし適切に付加されないと使用プロトコルの矛盾によって通信に失敗する可能性があります。 ただし、Viaの使い方によっては、クライアントのセキュリティを下げる可能性があります。 この点については、section 15.1.2をご覧下さい。
ネットワークファイアウォールの入口の役割を果たすプロクシは、ファイアウォールの内側にあるホストを識別するヘッダ情報の転送について特に用心すべきである。 特に、ファイアウォールの内側で生成されたすべての Via フィールドは削除するか安全なものに置き換えるべきである。
プロクシ内部のホスト名が外部に晒されると、外部の攻撃者にそのホストが狙われるリスクが高まります。 このため、Viaヘッダではホスト名に「偽名」をつけることができるようになっています。 再び、section 14.45をご覧下さい。
ネットワークファイアウォールへの入り口として使われるプロクシやゲートウェイは、既定では、ファイアウォール域内部のホスト名やポート番号を転送すべきではない。 この情報は、明示的に許可された場合にのみ伝えられるべきである。 許可されなければ、ファイアウォール内のあらゆるホストの
received-byは、適当な偽名に置き換えられるべきである。内部構造の守秘に関して強いプライバシー要求を持つ組織では、プロクシは同一の
received-protocol値を持つ連続した Via ヘッダフィールドエントリを一つのエントリに連結する事ができる。 次の例を見よ。Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucyこれは次のようにまとめられる。
Via: 1.0 ricky, 1.1 mertz, 1.0 lucyアプリケーションは、それらがすべて同じ組織コントロール化にあって、ホスト名が既に偽名に置き換えられている場合以外には、複数のエントリを連結すべきではない。 アプリケーションは、異なる
received-protocol値を持つエントリを連結してはならない。
HTTP通信を中継するホストが複数存在する場合、その通信を成功させるために必要な情報はHTTPバージョンだけであり、中継をするホスト名は必ずしも必要ではありません。 そのため、HTTPでは、中継ホスト名は偽名に置き換えたり、同じHTTPバージョンを持つホストが続く場合はそれらを連結したりすることで、ホスト名を外部に晒すことを避けられるようになっています。
そもそも、HTTP通信において、プロクシのような中継プログラムを使うとするならば、単純なクライアント-サーバ間の通信よりも、プロクシを介在する分交信回数が増えることになります。 すなわち、そこに何かしらのメリットがなければ、この交信は無駄になってしまいます。
プロクシを使うメリットとしては、上述の通り、ユーザエージェントに、ある種の翻訳、メディアタイプの変形、使用プロトコルの制限、匿名性向上のためのフィルタリング等のような各サービスを提供する
ということが挙げられますが、この他にプロクシの代表的な機能にキャッシュ{cache}があります。
たとえば、「今見ているWebページの1つ前に見たページに『戻る』場合」を考えます。 この時、もし1つ前のページを手元に保存していれば、再度サーバにリクエストしてリソースを取り寄せなくても、1つ前のページを見ることができます。 これが「キャッシュ」です。 つまり、キャッシュを適切に利用することによって、同じデータを何度もサーバから転送させる必要が無くなり、クライアントの時間的・金銭的通信コストが節約されます。 また、サーバもアクセス頻度が低減することにより、パフォーマンスは向上するでしょう。
キャッシュについての詳しい説明は、HTTP Caching をご覧下さい。
プロクシを利用するにあたってのセキュリティに関する問題点について、RFC 2616のsection 15.7の中で記されています。
その性質から必然的に、HTTP プロクシは人と人の間に入り{men-in-the-middle}、中継者による攻撃{man-in-the-middle attacks} の機会が与えられる。 プロクシが運転されているシステムの妥協{compromise} が深刻なセキュリティとプライバシーの問題を引き起こす。 プロクシはセキュリティに関係した情報、ユーザ個人やその団体についての個別の情報、ユーザやそのプロバイダが所有する所有者情報にアクセスする。 妥協したプロクシや、セキュリティやプライバシーの問題に無関心に実装、形成されたプロクシは、様々な可能性を持つ攻撃に使われる。
プロクシのオペレータは、機密性の高い情報を含み、また転送するシステムを守るように、プロクシが運転しているシステムを守るべきである。 特に、プロクシによって集められたログ情報はしばしば特に機密性の高い個人情報や組織情報を含んでいる。 ログ情報は注意深く監視すべきであり、改善や更新のための使用にも適切なガイドラインを設けるべきである。 (section 15.1.1)
キャッシングプロクシは、キャッシュの内容が悪意ある利用には魅力的なターゲットを表しているので、潜在的な弱点が付け加えられる。 キャッシュの内容が HTTP リクエストが完了した後もずっと残っているので、キャッシュへのアタックでユーザがその情報はネットワークからは既に削除されたと信じているずっと後にその情報を見る事ができる。 それ故に、キャッシュの内容は機密性の高い情報として守られるべきである。
プロクシの実装者は、その設計やコーディングの決定、そしてプロクシオペレータへ提供する設定オプション (特に既定の設定) がプライバシーやセキュリティに関わるという事を考慮すべきである。
プロクシのユーザは、プロクシを運転する人間しか信頼する価値のある人はいないという事を知っておく必要がある。 HTTP 自身はこの問題を解決できない。
プロクシを介したアクセスでは、サーバから見ると、プロクシがまるでクライアントとして動作しているように見えます。 このため、アクセス制限のされていないプロクシは、悪意を持つクラッカーがサーバを攻撃する際の中継地点となる、いわゆる「踏み台」として使われがちです。 この結果、プロクシの管理者が余計なトラブルに巻き込まれる可能性があります。 プロクシの管理者は、自身の管理するプロクシには適切なアクセス制限を施すべきでしょう。
また、匿名性を高めたHTTP通信を行いたいユーザが、管理者の許可を得ずにプロクシを勝手に使用することがあります。 しかし、プロクシのユーザは「HTTPプロクシを使うということは、そのプロクシの管理者を信頼したということを意味する」ということを確実に理解した上で、使用しなければなりません。
（※） しばしば、自身の匿名性を向上させたいがために、プロクシの管理者の許可を得ていないプロクシを使う人がいますが、そのようなプロクシを使用したとしても、プロクシのログ情報にはアクセス元はもちろん、アクセス先やアクセス時間がすべて記されているため、完全な匿名性を確保できるわけではありません。 また、そのようなログ情報を悪用することを目的に、あえて本来使用権限がないプロクシを公開している場合があります（ハニーポット）。 その場合、匿名性の確保どころか、かえって不利益を被る可能性すらあるので、使用権限がないプロクシは使用すべきではないでしょう。
, All Rights Reserved.
