nDiki : Internet Explorer

2001年10月2日 (火)

Apache Proxy で アンテナの ?%MM%%DD%%HH%%TT% 除去

アンテナページの多くはリンクURLに更新日時を付加する。 例えば

 http://www.naney.org/personal/diary/hns/

が、10月02日 14:46 に最終更新されているとう情報を取得すると

 http://www.naney.org/personal/diary/hns/?10021446

という、URL を持つリンクをアンテナページに生成する。 ページが更新されるとURLも変化するので、(Mozilla, Internet Explorer 等の)以前にアクセスした事のあるリンクの色を変えるブラウザでは、更新されたことを確認しやすい。

が、これはキャッシュ proxy には仇になる。 更新されるたびにURLが変化するということは、そのURLごとにキャッシュが作られるということだ。 私の愛用の WWWOFFLE もご多分にもれずそうである。 私は3ヶ月間キャッシュを保持するようにしているから、一日に3度更新されるページをアンテナのリンク経由で見ると、約90のコピーがキャッシュされる事になる。 そして、最新以外のキャッシュは(通常)2度と利用されることもない。 もはや、その URL ではアクセスされないから。

これはもったいない。 ようは、アンテナ経由でのアクセスの ? 以下を削除してキャッシュすればいいのだが、WWWOFFLE にはあいにくそのような機能はない。 そこで、URL を書きかえる proxy をブラウザと WWWOFFLE の間にカマせようということになる。

 Mozilla -> rewrite proxy -> WWWOFFLE -> target site

ここでは、Apache を rewrite proxy にすることにしてみた。 Apachemod_proxyproxy になるし、mod_rewriteURL を柔軟に変更できる。 もともと、自分の Web サイトのチェック用にローカルマシンで Apache も常時起動しているので設定を変更するだけだ。

とりあえず、大抵のアンテナは ?と8桁の数字(「なつみかん」でいうところの?%MM%%DD%%HH%%TT%)を付加するので、これをもぎとればよい。 以下、httpd.conf の修正。

 LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
 LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so

とモジュールをそれぞれ有効にする。rewrite_module より proxy_module を先に Load するようにする(デフォルトでは逆順なので注意)。

そして、httpd.conf の最後に

 ProxyRequests On
 ProxyRemote * http://127.0.0.1:8080/
 NoCache *
 <IfModule mod_rewrite.c>
 RewriteEngine on
 #RewriteLog /tmp/rewrite_log
 #RewriteLogLevel 9
 RewriteRule ^proxy:(.*)\?[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]$ $1? [L]
 </IfModule>

を追加。ProxyRemote で、WWWOFFLEproxy を指定。 RewriteLog, RewriteLogLevel はうまく書き替らない時に有効にしてログを確認するのに使う。 最後の RewriteRule で実際に書き替えを行う。 ポイントは $1? と、置換後の文字列指定で最後に ? をつけること。 これをつけないと query-string が削除されない(これに気が付くのに随分かかった)。

後はブラウザ側の http プロキシ先を 127.0.0.1:80 にすれば OK。

無条件に ?と8桁数字が末尾にくれば、取り除いてしまうので荒っぽい RewriteRule だ。 だが上記のような query string を使っているページは(多分)そうないから、とりあえず、これで良しとしよう。 困ったら直せばいい。

追加リンク

スポンサード リンク
[ 10月2日全て ]

2002年4月17日 (水)

Apacheミラー proxy

「会社のサイトにあるデモをノート PC に載せて、オフラインで使いたい」という事で、Windows XPノート PCApacheインストール

Internet Explorer からは http://会社のサーバ名/ でアクセスできるようにしなければならないので*1 Apacheproxy を使う事にする。 mod_proxymod_rewrite を(この順番で)有効にして

 ProxyRequests On
 NoCache *
 <IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteRule ^proxy:http://会社のサーバ名/(.*)$ http://127.0.0.1/会社のサーバ名/$1 [P]
 </IfModule>

としておく。 '<DocumentRoot>/会社のサーバ名' ディレクトリ以下に公開サーバの内容をコピー。 これで、Internet Explorerproxy を 127.0.0.1:80 にすれば、会社のサーバへの URL はローカル Apacheミラーコンテンツを返してくれる。

ただ、オフライン時に Internet Explorer が直接 DNS をひきにいこうとして proxy に行く前に名前解決失敗してエラーにしてしまったり、途中未接続の旨のダイアログが出たりすると一筋縄では行かなかったり。

自分の開発Windows 2000 BOX だと不具合が多かったけど頼まれた XP のノート PC は、あまりいじってないせいか割に素直に動いた。

*1そうしないとデモが動かない

[ 4月17日全て ]

2005年1月31日 (月)

朝日新聞購読申込み

Webサイトから申し込む。

新規に3カ月以上のご購読を、この画面からお申し込みの方(日本国内在住)にもれなく朝日新聞オリジナルのクオ・カードをプレゼント。(クオ・カードは購読開始から2週間ほどでお届けします。)

フォームに契約期間の入力襴がないな。

新聞購読については、お客様と当該販売店の間で改めて契約を交わしていただくようになります。この画面はお客様からのお申し込みを販売店に連絡するための画面です。お名前・ご住所・TEL番号、メールアドレスは、必ずご記入ください。

この点は毎日新聞と同じ。

申し込みページは mteria.com というサイトにあるのだが、www.asahi.com から辿る途中で外注している旨の説明はない。 https にしている意味も薄い。

フォームを記入して申込ボタンを押しても Firefox on Linux では送信されない。JavaScript の挙動の違いかなにからしい。

いろいろアラが見えて萎えるものの、しょうがなく WindowsInternet Explorer から申し込み。

新聞選択の理由

積極的というよりかは、消去法で残ったからという理由。

ということで。

朝日新聞NHKと今いろいろあったりと必ずしもいい印象ではないのだが(この件はまだ真相がわからないので態度保留)、とりあえず読んでみようかと。

[ 1月31日全て ]

2006年2月22日 (水)

今月の社長ガジェット - W-ZERO3

rimage:ISBN:4797334231

朝出社してきた社長がいきなり、ケースに入った何かをちらつかせてきた。 ニューアイテムだ。

何だ何だと見にいったら W-ZERO3。 そういえば、以前から買おうかどうか考えているっていっていたっけか。 結局昨日ついに購入したらしい。

以下ちょっと触らせてもらってのファーストインプレッション:

  • 本体はプラプラしており、社長もいう通りもうちょっと質感が高いといいのにという感じ。
  • 横置きするとカーソルボタンが左側にくる、
  • 見慣れない Windows Mobile 5.0 のせいか、画面は 640x480 でも狭く感じた。
  • Web ブラウザ Internet Explorer Mobile は文字もうまくスケーリングされて、結構見やすい。

W-ZERO3 はほとんどノーマークだったので、知らなかったのだが普通に通話もできのだね。 (持ちやすいかは別として)普通に通話もできた。

主にずっと Palm を使っている社長が今後どう使っていくかに興味津々。 果たして Palm から乗り換えてしまうのか?

[ 2月22日全て ]

2006年4月29日 (土)

WikiPage 編集画面で Ctrl+S を押すとプレビューするようにしてみる

「ついつい保存しようとして Ctrl+S を押して Web ブラウザの保存ダイアログを開いてしまうんだよね。Ctrl+S で (WikiPage を)保存してくれると嬉しいんだけれど。」

WiKicker を使用している同僚からのアイデア。 自分にとって C-s は Incremental search forward (`isearch-forward') であって保存ではないので、あまり関係ないといえばないんだけれど、その気持ちは良くわかる (C-p で 印刷ダイアログが開くのうざい)ので、試しに実装してみることにした。

ただしいきなり Ctrl+S で保存はちょっとデンジェラスなので、プレビュー画面に移動するようにしてみる。

例によって Web ページ上の JavaScript におけるイベント処理は、Web ブラウザ依存バリバリなのね。 テストが面倒(自分でできない/自動化困難)なので、できるだけ近付きたくはないのだけれども。

とりあえず、Firefox 1.5.0.2 on Debian GNU/Linux と、Internet Explorer 6 on Windows 2000 では動くことを確認するところまできた。

喜べ松下君。

[ 4月29日全て ]

2006年5月24日 (水)

「s」文字をキー入力できない WikiEngine

昨日早速社内の WikiWiKicker 0.30 に上げておいたのだが、同僚からバグレポート。

「s」を入力できません。s を押すとプレビュー画面になっちゃいます。

あ。

Internet ExplorerJavaScript コードにバグあって、Ctrl+S でプレビュー画面に遷移するようにイベント処理していたつもりが、s キー一発でそう動いてしまっているらしい。

あわてて修正。

はやく WiKicker の修正リリースを出さねば。

[ 5月24日全て ]

2006年5月28日 (日)

WiKicker 0.31 リリース - s キー問題を修正

2006年5月22日以来、約1週間ぶりのリリース。

[ 5月28日全て ]

2006年6月1日 (木)

Hyper Estraier で社内 Web コンテンツ検索

昨日の自分のノート PCHyper Estraier の試用を踏まえて、社内のサーバに Hyper Estraier を設置する。

インストール

いまだ Red Hat Linux 8.0 であるサーバに、昨日と同様に Hyper Estraier 1.2.7 を /usr/local/hyperestraier-1.2.7 以下にインストール

この環境では ./configure 時に iconv が見つからないため、最初に libiconv 1.9.2 を /usr/local/hyperestraier-1.2.7 に入れ、続けて QDBM、Hyper Estraier の順にインストール

estwaver + estmaster でクローリング + 文書登録も問題なく完了。

search_ui がうまく動かない。

検索をしようと http://ホスト:1978/node/ノード名/search_ui にアクセスするも、検索フォームを含め何も表示されない。あれ? 他の管理ページは問題なく表示されるのに search_ui だけ駄目。

GNU Wget だときちんと HTML を GET できるのだけれど、FirefoxInternet Explorer からだと駄目である。

いろいろビルドしなおしてみたけれどやっぱり駄目なので、今回は結局 estmaster をやめて CGI プログラム版の UI を使うことにした。 こちらだとクローリング中は検索ができなくなってしまうけれど、夜中に cron で回すから別にかまわないか。

インデックスの方針

以下のような感じでクロールし、登録することにした。

  • 社内メイン Wiki、自分の社内 Blog、公開 Web サイトのトップページをクロールの種文書とする。
  • それと社内メイン Wiki の更新情報ページも種文書とする。
  • 社内のサーバ、および公開 Web サイトのみクロールするように allowrx、denyrx を設定。
  • Wiki の編集ページ等をクロールしないように denyrx を設定。
  • 1日1回深夜に cron でインデックスを更新。
  • revisit は3日に設定。
    • いくつかの種文書は -revcont 付きで estwaver を実行しても毎回巡回して欲しいのだけれど、それはいまのところできないようだ。

特定の WikiBlog 内のみを検索したい時は、検索インタフェースの方で URL を指定絞り込めば良いので、それほど規模も大きくないし全部ひとまとめにインデックス化することにした。

後は使いながら微調整していくこととしよう。

[ 6月1日全て ]

2006年6月10日 (土)

WiKicker における PageName 最長文字数

WiKicker では PageName を エンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。 このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。

今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。

WiKicker実装

WiKicker実装がらみとして最長を決める要素としては

がある。

仕様等による制約

  • HTTP では URI の長さには制限なし (RFC2616 3.2.1)
  • Web サーバは Request-URI が長いと 414 Request-URI Too Long を返す (RFC2616 10.4.15)。Apache は LimitRequestLine ディレクティブにより、URI を含むリクエスト行のサイズを制限することができる(配布時には 8190)。
  • Internet Explorer が扱える URL の長さは 2083文字。
  • ext2ファイル名は 255文字まで(増やすこともできる)。
  • 手元の Linux 2.6.15 で試したところ、パス名は 4095文字まで。

WiKicker で問題が出ない PageName 最長文字数

上記の中ではファイル名による制約が一番大きい。

WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。

WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。

PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。

ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。 日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。

そのうち、WiKicker に制約チェックを入れることにしよう。 そのうち。

[ 6月10日全て ]

2006年6月20日 (火)

WiKicker 0.35 リリース - 添付機能の修正など

添付機能を有効にすると、添付ファイルが無いページに対応するディレクトリが無条件に作られてしまう問題を修正。

それから日本語ファイル名のファイルを WikiPage に添付した際、Internet Explorer でそのファイルをダウンロードして保存しようとすると URI エスケープされた文字列がデフォルトの保存ファイル名になってしまいよろしくない。 このため、Content-Disposition ヘッダをつけてレスポンスを返すためのダウンロード用のリンクも追加。

Cotent-Disposition ヘッダでファイル名を指定する際、

ファイル名シフト JIS でエンコードしてしまうようにした。

ファイル名シフト JIS で表現できない文字があるかもしれないし、Accept-Language に ja があったからといって Windowsロケール日本語になっているという保証もないので、かなりいい加減なコードである。

なにか良い方法があったら修正したい。

[ 6月20日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.074652s / load averages: 0.77, 0.52, 0.50
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker