標準になっている(i.e RFCに載っている)よーなものは基本的に載せません。
$Id: nonstdhdr.html,v 2.10 2018-11-30 20:29:11+09 kabe Exp $
Proxy-Connectionの扱いについては RFC等には出てきませんが、 Netscapeが HTTP/1.1 以前に persistent connection を実装した際、 persistent を解さないproxyがあると
ところが、proxyが二段 (一段目persistent、二段目HTTP/1.0) になると破綻します。 このため Proxy-Connection はRFCにはならず、request-line の 末尾の "HTTP/1.1" で persistent を表すよう変更されました。
なお、CacheFlowは "GET url HTTP/1.1" ではpersistentにならず、 "Connection: keep-alive" が必要という、 今となってはやや古くさい仕様となっています。
unknownIPaddr は
by proxy-URI [(product)] [for client-FQDN]xvert
color8|color16|color24|color32
Windows 3.1|Windows 95|Windows NT|Windows CE|MacOS
x86|PPCMSIE/3.x がつけていたヘッダ。 MSIE/4.x以降は基本的につかないのですが、Mac版は今でもついたままなので、 "UA-OS:" の観測量は "MacOS" が現在では一番多いと思います。 他のブラウザでつけてくるものとしては
draft-luotonen-http-url-byterange-01 から 02の間の案に現れます。 その後、 他ヘッダとの整合性のため Range: に変更され、最終的には HTTP/1.1 に吸収されています。
結局 RFCにはならなかったわけですが、 Netscape/3以降で使われている ようです。 全く同じ内容が "Range:" としても渡されているので、 HTTP的には単に冗長なだけですが、
draftに基づいた実装のブラウザに対しては、 responseとして
標準の multipart/byteranges
ではなく multipart/x-byteranges で返してやらないと
うまく動きません。
(Apache でも 1.3.0 から対策済)
主に
Traffic Server
がつけているもの。
稀に Netscape-Proxy でも観測されます。
常につくというわけではないので設定可能な機能だと思われます。
"IP"はプロトコル依存の概念なので、この系統のヘッダは
HTTP的には絶対に標準化されません。
クライアントが Compuserveの Remote Passphrase Authentication に対応していることを示すもの。 RFC draftでは draft-petke-remote-pass-auth-00.txt と draft-petke-http-auth-scheme-00.txt に現れてますが、 とっくに期限切れなので今は Compuserve のサイトを 直接参照した方がよさげです。
規格的には "might" となってるので、別に送らなくてもよさそうですし、 RFC2617 (Basic and Digest Access Authentication) 的にもこんなものは必要ないはずなんですが、 実装ではこのヘッダがないとWWWサーバーは WWW-Authenticate: Remote-Passphrase を 返してくれんようです。 (http://www.compuserve.com/rpa/datest.htmで試してみましょう)
RPAに対応している サーバー には何があるんですかね (テスト用の datest.web.compuserve.com は IIS の模様。 Apacheは誰かがmoduleを書くまで使えないと思う)
FrontPage の内部がわかりにくいのは元々そういう風に作ってあるからで、 Microsoft だからというわけではない。
POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 Date: Thu, 19 Oct 2000 14:59:59 GMT MIME-Version: 1.0 User-Agent: MSFrontPage/4.0 Host: muc01134:8888 Accept: auth/sicily Content-Length: 41 Content-Type: application/x-www-form-urlencoded X-Vermeer-Content-Type: application/x-www-form-urlencoded Connection: Keep-Alive method=server+version%3a4%2e0%2e2%2e3717
普通の Content-Type: もついているので、 HTTP的には意味なし。 auth/sicily てのも なんだか謎。 なくても動くんかな？
大本営発表： Microsoft Acquires Vermeer Technologies Inc.
Vermeerの創立者が書いた、視点かたより本の "High St@kes, No Prisoners" の感想文は こんなところ が面白いかも
もともとは Netscape の Lou Montulli によって 提案 された。(当初はlength= ではなくsize=になっている)
壊れたキャッシュ対策 (サーバー側でブラウザキャッシュが壊れているかどうか判定できるように) ということで提案されているが、 実際の原因は NN1.1 がreload時にno-cacheとIMSを両方送っているため。 IMS を送ると、ブラウザ側のキャッシュが壊れていても サーバー側は 304 Not Modified を返すので、このままでは永久に まともなリロードができない。
Netscape 1.22 のリロード時のヘッダ：If-Modified-Since: Thursday, 07-Dec-00 16:21:45 GMT User-Agent: Mozilla/1.22 (Windows; I; 32bit) Pragma: no-cache Accept: */* Accept: image/gif Accept: image/x-xbitmap Accept: image/jpeg
なぜ IMS と Pragma: no-cache 両方つけると問題かというと、
が、なぜか Lou は IMS を削ることに 消極的である。 Louは、これは中間のキャッシュがLast-Modifiedだけでは十分な照合が できないからとしているが、他の参加者は単にクライアント(NN)が 腐れているからであるとしている。(こちらが正しい。) 変なLast-Modifiedで腐るのは源サーバーの責任。
この辺の議論から ETag が出てきたのだなーということが感じられる。
公開されたばかりの頃のMozillaにも "; length=" を 出すコードは存在していたはずだが、 ネットワークまわりが network→netwerk とフルスクラッチに近い 入れ替えが行われた頃に、バグレポートに現れることもなく ひっそりと姿を消している。
Louの主張は今見るとNetscapeの担当者にしてはえらくわがままに写るが、 当時はMosaicやChimeraも使われていてNetscapeは新進気鋭のココロに あふれていたことを考えるとそれほどムチャではない、かも。
このlength=が、なんでMSIEにも未だに継承されているのかは謎である。
プリフェッチ機能の概念自体は 1995年の Mosaic 2.0 で
"AutoSurf" として実装されてますし、
それ以降「プロードバンド」が流行するまでは独立アプリケーション
として色々作られていました
(WebAuto, InterGet, HotCargo Expressなどなど)。
これらは独立アプリケーションなので、判別ヘッダはUser-Agentくらいしか
なく、正確なヒット数判定に苦労していた人が極少数いました。
ブラウザ組込に回帰したのは Mozilla 1.2 が初めてかも。
(MSIEの「購読」は更新チェックなので除外)
x-awg-client-version:08.07.0500 x-awg-client-protocol-version:0701 x-awg-client-ex-info:base64-80