PHP4.4.9のパッチを頼まれて書いた話 : iwamotのブログ
2012年04月21日17:37 カテゴリPHP PHP4.4.9のパッチを頼まれて書いた話 3月上旬、あるドイツ人から「PHP4.4.9のパッチを書いてくれないか」という相談メールが届いた。「2週間以内にPHPのあるバグをふさがなければならないのだが、Cの知識がないので、バグ報告者であるiwamotにパッチを書いてほしい」というのだ。 「私だってCの知識はないし、PHPのコーディングを工夫すればバグをふさぐ必要もない」などと返したのだが、どうしても書いてくれというので、「うまく書けるかどうか保証はできないし、そもそも期日に間に合うかどうかわからない」と断ったうえで、トライすることにした。どこの馬の骨だかわからない私に頼るぐらいだから、そうとう切羽詰まっているのだろう。 パッチはなんとか書けたので、先方に送り、テストしてもらった。「意図どおりに動いているので、これを使うことに決めた」との返
HTTPの仕様書に「副作用」の定義がないのは不親切じゃね？ - 岩本隆史の日記帳（アーカイブ）
『Webを支える技術』の101ページに、こう書かれています。 リソースの状態に変化を与えることを副作用（Side Effect）と言います 僕の読み落としでなければ、この定義の出典は同書には明記されていません。ただ、HTTPメソッドの冪等性や安全性を解説する文脈で紹介されているので、HTTP/1.1の仕様書であるRFC 2616が出典なのだろうと思います。 RFC 2616の本文には、「副作用」（side-effects あるいは side effects）という言葉が9回出てきます。最初に出てくるのは「9.1.1 Safe Methods」においてです。橋本英彦さんによる日本語訳を引用します（強調は岩本、以下同じ）。 本質的に、サーバが GET リクエストを実行した結果として副作用を起こさないという事を保証するのは不可能であり、事実、いくつかの動的なリソースはそれが特徴であると考えている
商品情報のJSON表現について考えた - 岩本隆史の日記帳（アーカイブ）
キープリストで提供するリソースのURI キープリストというWebアプリを作ろうとしています。気になる商品（Amazonで扱っているもの）を放り込んでおけるサービスです。 以前の日記では、URIの設計について考えました。それからも断続的に考えていて、現在は以下のようにしようと思っています。 リソースURI トップレベルリソースhttp://keeplist.in/ 商品検索結果リソースhttp://keeplist.in/amazonsearch?q={キーワード}&format={html または json} 商品リソースhttp://keeplist.in/Item:{ASIN}.{html または json} 本当はもっとたくさんのリソースが必要ですが、書き込み可能なWebサービスの設計は高難度なので、まずは読み取り専用部分のみ考えることにします。 さて、『Webを支える技術』で紹介さ
有効にしているGreasemokey一覧を晒してみる - 岩本隆史の日記帳（アーカイブ）
この記事の更新履歴 2010-03-04 この記事を随時アップデートしていくことに決めた。「Gmail Unread Message Count in Favicon」を追加。 本題 Firefox 3.6上で有効にしているGreasemokey一覧を晒してみます。珍しいものもあると思いますので、お役に立てば幸いです。 逆に「あれ入れてないの？」とか「こっちのほうが便利だよ」とかあれば、ぜひお教えください。喜びます。 全サイトで有効 AutoPagerize 定番。次ページを自動で読み込める。 LDRize 定番。livedoor Readerのショートカットキーが他のサイトでも使える。が、あまり活用していない。 Minibuffer 定番。いろんな便利コマンドがCUIで実行できる。が、あまり活用していない。というか、LDRizeのために入れているだけ。 Fast Look up Alc
スケーラビリティへの執着を断つ - 岩本隆史の日記帳（アーカイブ）
このところ、スケーラビリティについて私が考えても無駄ではないかと思い始めている。私が仕事で作っているのは小規模のWebアプリだし、転職する予定も今はない。趣味のほうはといえば、Webアプリ運営に使える予算などたかが知れていて、安いVPSが1台借りられる程度だ。大規模サービスなど作れない。 さらにいえば私は、数十万、数百万ユーザのためのサービスを作ろうと思ったことがない。ユーザが多ければ多いほど儲かる可能性はあるのだろうが、私の目的はカネ儲けではない。私が不便と感じている日々の作業は、この世でたぶん数十人ぐらいの人が同じように不便と感じているはずで、そんなちょっとした不便を解消するWebアプリが私は作りたいのだ。 グリーの社長は「みんな、そこそこの人生で、そこそこで楽しくて、そこそこの成長というのは目指してないよね。日本に失われつつある高度成長期を、この会社だけでやろうよ」といっているらしい
htmlspecialcharsに関する素敵なお知らせ - 岩本隆史の日記帳（アーカイブ）
外出のため確認が遅くなってしまったのですが、「htmlspecialcharsに関する残念なお知らせ」という記事で触れたバグレポートが、reopenされ、fixされました。 「改善される見込みは薄い」という私の予測は外れたわけで、申し訳ないと思うと同時に、htmlspecialcharsの挙動が改善され、嬉しく思っています。ご尽力いただいた皆様、ありがとうございました。 PHPのバグレポートを初めて書く方へ PHPのバグレポートには、再現コードや期待される結果、実際の結果を書く欄があります。私のレポートでも埋めました。 PHPのコミッタはそれらを読み、バグだと思えばコードを修正するでしょう。また、仕様だと思えば却下するでしょう。私のレポートでいえば、janiさんは仕様と判断され、moriyoshiさんはバグと判断されたわけです。「それでいいのか」という気もしますが、そうなのだから仕方がない
htmlspecialcharsのパッチ私案 - 岩本隆史の日記帳（アーカイブ）
PHPのhtmlspecialchars関数について、文字エンコーディングの妥当性チェックが不充分であること、また場合によってはXSS攻撃が可能になることが、下記ふたつの記事で指摘されています。 htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか | 徳丸浩の日記 Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記 徳丸さんの記事では、仕様変更も提案されています。 冗長なUTF-8は不正なエンコーディングとして扱う（出力を空にする） Shift_JIS、EUC-JPの2バイト目が不正な場合も、エラーとして出力を空にする htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか | 徳丸浩の日記 さらに、id:t_komuraさんの記事をうければ：
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
