]> Nonstandard HTTP Headers

▼非標準 HTTP ヘッダ一覧▼

標準になっている(i.e RFCに載っている)よーなものは基本的に載せません。

$Id: nonstdhdr.html,v 2.10 2018-11-30 20:29:11+09 kabe Exp $


Remote-Host: ClientIPaddr (札幌WinProxy 1.51-)
Remote-Host-Wp: ClientIPaddr (札幌WinProxy 2.00-b4以降)
札幌版WinProxy が追加するヘッダ。 Viaはつかないが、上に加えて X-Forwarded-For と Forwardedがつくという なんだか中途半端な仕様となっています。
名称変更後も別に Remote-Host-bjd になったりはしません。

Xonnection: original-Connection
Xroxy-Connection: original-Proxy-Connection
CacheFlowによる Connection, Proxy-Connectionの変換。ある意味正しい動作。

Proxy-Connectionの扱いについては RFC等には出てきませんが、 Netscapeが HTTP/1.1 以前に persistent connection を実装した際、 persistent を解さないproxyがあると

これへの対策として 中間に persistent を解す proxy (Netscape-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" が必要という、 今となってはやや古くさい仕様となっています。

XXXXXXXXXXXXXXXXX: orig-If-Modified-Since
XXXXXXXXXXXXXXX: orig-If-Modified-Since
CacheFlowによる If-Modified-Sinceの書き換え。 「キャッシュにはないのだが、クライアントが IMS つきの要求をした」 場合に、自分でため込めるように IMS を削ります。 この辺は Squid とは逆の動作となっています。 また、Cookie:, Proxy-Authorization:, Authorization: が ある場合も変換される。 長さ15と17がありますが詳細不明。17は2.2.16以前、15は2.2.17?

Unless-Modified-Since: Date
Range: の変調用。HTTP/1.1では"If-Range"に統合されています。 draft-ietf-http-range-retrieval-00.txt に現れる。 wininetではまだ使っている模様。
http://msdn.microsoft.com/workshop/networking/wininet/reference/constants/queryinfo_flags.asp

X-Forwarded-For: clientIPaddr|unknown
Squid が最初。 他のproxyがつけているのはSquidのマネ。 HTTP DraftがForwarded:からVia: へ変更されたのを受けて、 クライアントアドレスをどこかに残すために新設されました。 この頃の Squid はバージョンアップがやたら激しく、 alphaだbetaだreleaseだといった違いにあまり意味はありません。

X-Locking: IPaddr:cachepath
DeleGate (2.0.5-) が 上位proxyがある際につけるもの。 コメントには自己ループ検出とあるが、 実質的にはループした際にキャッシュファイルの上書きを防ぐためのもの。 (本当にコレで正しいのかいまいち不安)

IPaddr

ここの部分を見て「生IPが抜けたぜ、うほうほ」と思っている 人がいるようですが必ずしも正しくありません。

Forwarded: by proxy-URI [(product)] [for client-FQDN]
draft-ietf-http-v10-spec-01.txt および draft-ietf-http-v11-spec-01.txt までの HTTP-draft に出現。 標準化に際しては 「冗長である」 という理由から Via: に置き換わっています。 "for ..." 部分は Via: から削られたため、Squid では代わりに X-Forwarded-For ヘッダを新設しました。 (当時まじめにDraft等を追っかけていたのは Squid くらいだったような気が)

UA-pixels: horizxvert
UA-color: color8|color16|color24|color32
UA-OS: Windows 3.1|Windows 95|Windows NT|Windows CE|MacOS
UA-CPU: x86|PPC

MSIE/3.x がつけていたヘッダ。 MSIE/4.x以降は基本的につかないのですが、Mac版は今でもついたままなので、 "UA-OS:" の観測量は "MacOS" が現在では一番多いと思います。 他のブラウザでつけてくるものとしては

AVE-Front
例のむやみに長い User-Agent に加えて これらも送ってくる場合があります。 "UA-OS: NetFront" となるようです。 ("ITRON"じゃないのか…) UA-CPU はいろいろなバリエーションあり。
Device Mosaic
"UA-OS: Win32" となります。希少。
MSPIE 2.0
"UA-OS: Windows CE"。UA-CPUもバリエーションあり。 MSPIE 1.1 ではつきません。

Request-Range: ranges-specifier

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 から対策済)

Client-ip: IPaddr

主に Traffic Server がつけているもの。 稀に Netscape-Proxy でも観測されます。 常につくというわけではないので設定可能な機能だと思われます。
"IP"はプロトコル依存の概念なので、この系統のヘッダは HTTP的には絶対に標準化されません。

Extension: Security/Remote-Passphrase

クライアントが 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を書くまで使えないと思う)

X-Vermeer-Content-Type: application/x-www-form-urlencoded
FrontPage が吐くヘッダ。 Vermeer は FrontPageを開発していた 会社の名前。後に Microsoft に買収される。 _vti_* は Vermeer Technologies Inc. のなごり。

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" の感想文は こんなところ が面白いかも

If-Modified-Since: ...; length=...
4.x 以前の Netscape Navigator と、 意味もわからずまねをする MSIE 3.02以降、 および Milestone12 以前の Mozilla(.org)がつけるもの。

もともとは 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にも未だに継承されているのかは謎である。

X-moz: prefetch
Mozilla 1.2 beta 以降に搭載されたプリフェッチ機能を使った際に 使われるヘッダ。 Googleもアクセラレータ で仕様追従。

プリフェッチ機能の概念自体は 1995年の Mosaic 2.0 で "AutoSurf" として実装されてますし、 それ以降「プロードバンド」が流行するまでは独立アプリケーション として色々作られていました (WebAuto, InterGet, HotCargo Expressなどなど)。
これらは独立アプリケーションなので、判別ヘッダはUser-Agentくらいしか なく、正確なヒット数判定に苦労していた人が極少数いました。 ブラウザ組込に回帰したのは Mozilla 1.2 が初めてかも。 (MSIEの「購読」は更新チェックなので除外)

x-awg-client-*
おそらくSophosのAstaro Web Gateway (AWG) アプライアンスが つけているヘッダ。 クライアントリクエストに追加しているのは、アプライアンスを 多段接続した際の何らかの情報のやり取りに使われているんだと思われます。 自己ループ検出も当然入っていると思いたい。
	x-awg-client-version:08.07.0500
	x-awg-client-protocol-version:0701
	x-awg-client-ex-info:base64-80
	

かべ@sra-tohoku.co.jp