nDiki : URI

WiKicker における PageName 最長文字数

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

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

WiKicker の実装

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

• PageName の UTF-8 表現を URI エスケープしてページ URI に含めている。→ URI、HTTP、HTML、Web サーバ、Web ブラウザの実装による最長の制約
• PageName を base64 にエンコードしてファイル名にしている。→ ファイルシステムのファイル名、パス名の最長の制約

がある。

各仕様等による制約

• 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 に制約チェックを入れることにしよう。 そのうち。

WiKicker 0.34 リリース - 添付機能のコードを追加

2006年6月8日以来、3日ぶりのリリース。

zakwa 氏からの要望により、WikiPage のコピー直後に編集画面に移れる edit now オプションを追加。

また大きな改良として「添付機能」を追加した。 まだ最初のコードなのでエラー処理等が甘いが、それなりに動いているのでコミット。 まだ権限設定がないので、公開サーバでは使用しない方が良い。

添付ファイルのダウンロードを WiKicker 本体の CGI プログラムから行わせるか、独立の CGI プログラムにするか迷ったが、結局別物にした。

• WiKicker の URI 体系の中に、末尾にダウンロードファイル名を持ってこれる形式を作成できなかった。

というのが大きな理由。

設定方法

WiKicker のページにまだ設定方法を書いていないので、こちらへ。

attachment CGI プログラムを設置

例えば attachment というファイル名で以下のような Perl CGI プログラムを作り、Web サーバから実行できるように設定を行う。

 #!/usr/bin/perl
 use strict;
 use warniings;
 use WiKicker::WikiCGI::AttachmentController;
 WiKicker::WikiCGI::AttachmentController
   ->new(properties_file => '対応する wiki の設定ファイル名')->run;

Wiki のプロパティに設定を追加

次に Wiki の設定ファイルに以下を追加。

 param.NormalPage.attachment: enable
 param.NormalPage.attachment.uri: attachment

param.NormalPage.attachment.uri には上で作った CGI プログラムの URI (相対/絶対)を指定する。

これで各ページに attachment (添付)というリンクが表示され、添付機能が使えるようになる。

WikiPage での参照の仕方

 # リンクを作成
 [[attachment:ファイル名]]
 [[attachment:ページ名/ファイル名]] <- 別のページの添付ファイル

 # 画像をインライン表示
 [[image:attachment:ファイル名]]
 [[image:attachment:ページ名/ファイル名]]

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

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

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

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

• HTTP_USER_AGENT を見て Internet Explorer っぽくて
• Accept-Language の最初に ja があった場合

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

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

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

Perl 5.8.8 の CGI.pm の PATH_INFO 処理の問題にぶつかる

手元の WiKicker (や DiKicker) で、「C++」という文字列を含む URI にアクセスしたらエラー。

 Nested quantifiers in regex; marked by <-- HERE in m//C++ <-- HERE .html$/ at (eval 27) line 7.

正規表現の一部として使う時には \Q...\E していたと思ったが抜けがあったか。 とコードをチェックしてみたが、それっぽいところなし。 そもそも、Perl 5.005_03 だと問題おきていないし。

確認したら CGI.pm の url() の中でのエラーだった。 quotemeta されていない。

Perl 5.8.8 に含まれている CGI.pm 3.15 で問題を確認。3.17 までは駄目で、3.19 以降だと \Q...\E するように修正されている (3.18 は CPAN にないので不明)。

標準 Perl ライブラリのバグを踏んだか……。 標準 Perl ライブラリのアップグレードはなにかと面倒なので、システム要件にはしたくはないんだよねぇ。

今日のさえずり: tweetbar より、TwitBin の方がコンパクトで1度に多くのログが見られるという点はいいな

• 08:06 起床。
• 09:47 Twitter API 復活? 洗濯物干している間に、tweetbar も表示されるようになった。
• 12:55 帰宅。
• 13:00 バナナガード、2本目のバナナもクリア。2/2
• 13:06 買ったバナナ1房4本までは調べてみる。バナナガード。
• 13:07 昼飯。エアコンのならしも兼ねて、冷房かけておく。
• 13:20 http://m.twitter.com/ iモードブラウザじゃ駄目なのね。D703i では駄目だった。
• 14:19 トイレ掃除完了。
• 17:04 母と妹が家に立寄って、今さっき帰った。Google Maps を堪能していった。
• 19:40 3度目の帰宅。
• 20:28 TBE の「同じURIのタブを複数開くことを禁止する」相当の機能を実現する Firefox 拡張機能ないのかなぁ。
• 21:28 晩御飯作り & 晩御飯終了。デジカメ画像の吸い出しでもするか。
• 21:31 TwitBin 入れてみる。
• 21:40 tweetbar より、TwitBin の方がコンパクトで1度に多くのログが見られるという点はいいな。
• 21:49 駄目だ。眠い。少しゴロ寝する。
• 25:49 寝すぎた! 起きて風呂はいらねば。
• 26:32 風呂。

今日のさえずり: 鏡といえばヤヌス

2011年06月16日

• 07:36 鏡といえばヤヌス。
• 10:15 Evernote for Windows 4.4 出てる。今回は機能追加てんこもりっぽい。期待(そしてデグレの不安)。
• 10:30 Wiki に書いているデイリーノートを最初から日報フォーマットにあわせて書いておくことにしよう。
• 12:13 Evernote for Windows 4.4 のノートリンク使ってみた。「evernote」 という URI scheme の URI が生成されるのか。そして Evernote for iPad では既に evernote: リンク先を開けるようになってた。
• 13:20 RT @s_harada: 皆そんなにFacebookが好きなら転職すりゃいいのに
• 13:27 mixi に新しく入った「先週の訪問者」、その他の一覧を見ると共通の友人が列挙される。ここんところ以前の「足あと」よりいいね。 #mixi
• 13:30 東京アメッシュ的には新宿で雨降ってるのか。傘持っていこう。
• 13:39 白身フライのり弁当 398円。 http://4sq.com/jGVz29
• 17:45 「仕事をする上で一番大切にしていることはどんなことですか?」という質問に回答・発表したら、「それ一言でいうと『ぽぽぽぽーん』ですね」って言われた。なお、ぽぽぽぽーんは1度も観たことございません。
• 18:04 そういえば昨日で入社から2カ月経ってた。
• 18:06 今日はこれからヨーロピアンビアカフェ。
• 18:29 ベルギービール! http://4sq.com/iO8pU9
• 18:40 ミュシャっぽい何か。 http://flic.kr/p/9TVAir
• 23:10 まさかのバッテリ切れでシャットダウンしてた。予備バッテリに交換したけどこちもほとんど残無し。
• 24:37 やはり企画・開発も目的と価値観からスタートしてアクションに落として行く、GTD でいうところのナチュラル・プランニングモデルで進めないと。

• ヤヌスの鏡

今日のさえずり: 昔、コビン・ケスナーって言ってて怒られたことある

• 09:42 ほっと。 (@ 株式会社ミクシィ (mixi, Inc.)) http://t.co/2UtVCPVF
• 11:44 Dropbox 絆創膏貼られてる。
• 11:52 iThoughtsHD、複数の Dropbox アカウント上のフォルダをクラウド同期先として指定できるのでイケてる。
• 18:13 ミーティング中に「加藤あい」と「阿藤快」思い出して苦悶。
• 18:23 昔、コビン・ケスナーって言ってて怒られたことある。
• 19:11 お、今日崖の上のポニョか。
• 22:51 Perl 5.14 + URI 1.59 で Encode::encode_utf8 してない文字列を query_param_append していくとガシガシエスケープされる。そういうことです。
• 22:58 ポニョまだやってますか?
• 23:20 うちの若いのが謎謎言ってたの解けたので帰る。
• 23:30 定期券をオフィスに忘れてきたことに駅で気がつくなど。タクシーで取りに戻りたい……。
• 23:37 出社。
• 23:39 退勤。

今日のさえずり: フチ子さんいなかったし、ヤバそうな人いた

• 13:31 I'm at 日高屋 渋谷宮下公園前店 (渋谷区, 東京都) http://4sq.com/18uAkle
• 13:54 フチ子さんいなかったし、ヤバそうな人いた。 (@ タイトーステーション 渋谷店) http://4sq.com/1cPjqLu
• 14:59 Google アラートどうなるんだろうと思ってたんだけれど、フィードで受け取っていた(Feedly でも読めていた)のは全部メールへ要変更だった。残念。
• 15:51 午後の部中。 (@ 株式会社ミクシィ (mixi, Inc.)) http://4sq.com/12kYIhz
• 18:05 HTTP/1.0 414 Request-URI Too Large
• 20:54 おにぎりとカルピスウォーターがジワジワきている(ちょっとした満腹感的に)。

Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon

LINE株式会社で開催された Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon 「秋のPlack/PSGI祭り」に参加してきた。今回は YAPC::Asia Tokyo でもよくトークされている masartz 氏とご一緒させていただいた。ここの会場にくるのは「第3.5回 データ構造と情報検索と言語処理勉強会」「PerlCasual #05」に続き3回目。

• http://atnd.org/events/45276

開催を知った時には定員60人すでに埋まっていて補欠だったんだけれど、その後定員80人に増やしてくれたようで参加できるようになった。当日時点ではキャンセル等で定員切っていてきたい人はこれるようになってたよ。

普通に使う Plack/PSGI Server @fujiwara 氏

会場アンケートをとりつつ、必須な/便利なモジュールや Plack::Middleware の紹介。

• だいたい Starlet か Sterman を使っている。
• リバースプロキシ使っている時には Plack::Middleware::ReverseProxy が便利。
• Server::Starter の start_server では plackup を実行するシェルスクリプトを作ってそれを指定するようにするとパラメータ変更できるのでいいよ。
• Devel::NYTProf する時には if $$ % 11 == 0 などで一部のプロセスだけでプロファイリングするようにすると不運な人は遅くなるけど、全体の影響抑えつつできるよ。

『How to build a High Performance PSGI/Plack Server』のその後と ISUCON3 を受けての話題 @kazeburo 氏

YAPC::Asia Tokyo 2013 の発表の続き。

Plack/PSGI のパフォーマンス向上の取り組みが進めば Perl の適用領域を広がるし(リアルタイムな広告系とか)、Perl 使いの仕事も増えるよ。

Plack::BodyParser の話 @tokuhirom 氏

• 最近のサーバーサイドの開発は JSON API の開発と管理画面の開発だよね。
• HTTP ステータスコードの使い方をシンプルに。アクセス自体が成功したら 200 を返して、API の結果の方に API 処理自体のステータスを入れる方がシンプルだし、アクセスログ処理なども楽だよと。
• JSON API のボディ内で返すステータスも HTTP ステータスコードと同じにしたら覚えることが少なくて楽。
• URI の /v1/ とか入れたりするけど /v2/ とか出たためしがない。

など。プラクティカルなトーク。

Plack::Request with Encoding @moznion 氏

リクエスト中のパラメータの decode を Plack で一箇所でやってしまう話。

Mojolicious の知りたい 10 のコト @yusukebe 氏

• morbo と hypnotoad。それほどパフォーマンス悪くない。
• Mojo::Base は使わなくていい。それほど機能無いし、Web 系以外では Mojo に依存したくないし。

「YAPC::Asia 2014 やります!」とのことです。

LT

@bayashi 氏の plackup -e でちょっとしたこといろいろできて便利だよという話や、@azumakuniyuki 氏の Haineko の話や、 @hkoba 氏のコントローラを書く人がいないプロジェクト向けのテンプレートエンジンの話や、@songmu 氏の .psgi からの卒業の話とか、@tasukuchan 氏のきまぐれオレンジ☆ロードについてのラジオみたいなビデオ LT とか。

空気を読まない(読めない)一方通行なビデオ LT は新しく。

Obsidian URI に JavaScript location リダイレクトする

Remember The Milk のタスクに Obsidian ノートを関連付けたいのだけれど、 Remember The Milk は URL フィールドに Obsidian URI を指定できない。

ノート名を document.location.search で受け取って Obsidian URI を組み立て document.location.href を更新する小さな HTML ファイルを配置し、そこを経由させることにした。