特に MIME Header の Content-type フィールドの導入によって, filename と filetype の分離ができるようになった. この Content-type フィールドは filetype の決定権を クライアント側からサーバ側に移した. このことにより「URL の抽象化」の自由度がかなり増した. 例えば後述する 回転印の画像を動的に生成する CGI コマンドの例では, クライアントにデータを GIF 形式の画像データファイルであると 思わせるためには, HTTP/0.9 では
GET /cgi-bin/seal.gifなどとして, アクセスするための URL の最後に GIF ファイルであることを示す 拡張子がついている必要があった. しかし, HTTP/1.0 では
GET /cgi-bin/seal HTTP/1.0とアクセスしてきても, MIME Header の中で
... Content-type: image/gif ... [gif のデータ]と返すことにより, クライアントはサーバが返すデータを GIF 形式と解釈して適切なビューアにそのデータを渡して 表示してくれる.
また MIME Header により Security の仕組みも容易に 導入できるようになった. MIME Header の中に鍵などを埋め込み, データ自身 (あるいはもともとの MIME Header なども含めたもの) を 暗号化することにより, Security を確保した アクセスが可能になる. SHTTP (Secure HTTP) は基本的にこの線でいくようである (0).
GET /cgi-bin/seal HTTP/1.0と WWW のサーバにアクセスすると, 回転印の画像が 動的に生成される. この回転印の画像の中の日付の部分が毎日変わる. その当時, 現在時刻の時計の絵を生成するツールがあったので, それをいろいろ変更して図のような回転印の画像を生成する ものを作った. 折角作るならきれいに作ろうといろいろ工夫しており, この回転印の動的画像生成は以下のようになされる. まず回転印の画像をスキャンしたものと, 当日の日付から 当日の日付が入った PostScript のデータを作る. (2) その PostScript のデータから, フリーソフトである ghostscript で PPM (Portable PixMap) ファイルを作り, やはりフリーソフトの netpbm を 使って少し小さくすることにより anti-aliasing (3) をかけ, さらに背景色を透明と指定した GIF 形式の 画像データに変換している.
時刻表であれば, ただ単に時刻表を出すだけではなく, 現在時刻とその時間を表すアナログの時計のイメージを示し, 現在の時刻の近辺の時刻表を出力する. さらにその時刻表の中で乗ることのできる 電車の時間を強調して出し, その電車までの時間を表示するように した. 例えば WWW のクライアントから WWW サーバに
GET /cgi-bin/tt-www?Nakahara-T+5のようなアクセスがあると, 武蔵中原駅 (4) の立川方面の時刻表で 現在時刻から 5 分後に駅につくとした場合の時刻表と 乗ることのできる電車の時刻を提示してくれる.
以下の説明ではゲートウェイマシンの名前を ``gateway'' とする. ``gateway'' 自身も WWW サーバである. さて最初の一度だけは以下のような URL で WWW クライアントから アクセスする.
http://gateway/cgi-bin/sjis/http://www.fujitsu.co.jp/すわなち, メソッドは HTTP でマシンは ``gateway'' にアクセスするのだが, 通常の URL の ``path'' に当たる部分にさらに ``cgi-bin/sjis/'' + URL を指定するのである. ``gateway'' には
GET /cgi-bin/sjis/http://www.fujitsu.co.jp/というアクセスが来る. ``gateway'' は ``sjis'' という CGI コマンドを実行することにより, この URL ( http://www.fujitsu.co.jp/) に対応する文書をとってくる. そしてまずこの文書のコードを Shift JIS に変換する. 次にこの文書内をパースして, ``リンク'' になっている URL を探す. 例えば現在このページには 次のような ``リンク'' がある.
<A HREF=hypertext/About_fujitsu/> <iMG ALIGN=DOWN ALT="o" SRC=images/icon_1b1.gif> 富士通紹介</A>この ``リンク'' を
<A HREF=http://gateway/cgi-bin/sjis/http://www.fujitsu.co.jp/hypertext/About_fujitsu/> <iMG ALIGN=DOWN ALT="o" SRC=http://www.fujitsu.co.jp/images/icon_1b1.gif> 富士通紹介</A>と書き換える (5). その他のリンクも同様に書き換えた文書をユーザに返す. ユーザは画面上では 図-1 と同じように見える (6). ユーザがそれ以降文書の中のどのリンクをクリックしても, ``gateway'' を 通じてアクセスすることになる. 戻ってくる文書も再び Shift JIS になって, ``リンク'' が書き換えられている (7).
Proxy Server とは違い, サーバ側にどのマシンをゲートウェイとして アクセスするのかの決定権があるので以下のようなことができる. 同じようなゲートウェイマシンをいくつか用意して, 上の ``リンク'' の書き換えで URL のゲートウェイマシンの名前の 部分を, 例えばそれらのマシンの名前からランダムに選ぶことにより, 負荷分散も可能になる.
このアイデアを使って, Proxy と同様に社内から社外の WWW サーバを 見せることも考えていたが, 結局 SOCKS (8) が出てきたので使わなかった.
代理サーバは, URL キャッシュという手法でによって Internet の負荷を減らすことができる. あるクライアントからの要求で URL をアクセスしたとき, その URL とそれに対する応答を記録しておく. 再び同じ URL が別クライアントから要求されたときには, 代理サーバ内の記録に基づいて応答し, 本来のサーバからの情報の取り出しを省略する. 毎回 Internet を介して遠隔地へアクセスしなくてすむため, 通信量が減る. また, クライアントから見たレスポンスも向上する.
代理サーバ技術には他の用途もある. 例えば企業内のローカルなネットワークから Internet にアクセスする場合, 逆方向の進入を防ぐために FireWall などと呼ぶ技術を用いることが多い. 代理サーバを社内ネットワークと Internet との境界に設置することで, FireWall による保護をより効果的なものにすることができる.