新規記事投稿

フォロー記事投稿

記事のキャンセル

12月26日に、Yasu.Fさんは書きました。

＞12月24日に、にあは書きました。
＞
＞＞逆にもともとPOSTには、"&"問題は存在しないわけで、';'に特別な意味を与えるのも
＞＞変ですし...
＞
＞わたしは逆に、「同じquery stringをrequest lineに書くとうまくいくのに、entity bodyとして
＞送るとうまくいかない」というのは、たとえばuser agentを実装する側にとって混乱の元に
＞ならないかなぁと思ったりもするのですが、どうなんでしょうね。

うーん、確かにwww-form-urlencodedされた文字列なら両者に共通に使えますが、そこでは
'&'や'='は特別な意味を与えられているし、逆に';'は書くことが出来ないわけです。

しかし、request lineではwww-form-urlencodedを使わねばならない、と言う規約はなく、
URLの一部として扱われるから、単にURL中に書けない文字だけがurlencodeされれば良いので、
';'が使えるわけですよね。

HTML中のURL中に "...?n+=i;&len(p=ptr);" と言う所があったとしても、それは
単に "n+=i;&len(p=ptr);" と言う文字列を渡したいだけで、その意味として、
項目"n "に値"i;"を、項目"len(p"に値"ptr);"を入れる、と言う意味が強制されている
わけでは無いですし、"n+=i;&len(p=ptr);"と言う文字列を渡すのに、必ず、
"n%2B%3Di%26len%28p%3Dptr%29"と書かなくてはいけないことも無いですよね。

また、FORMのエンコードに、と言うより、entity bodyのエンコードにwww-form-urlencoded以外
(multipartとか)のエンコードを使っても、別に構わないわけですよね。
＃ うぇぶ会議室的には、まだ実装されていないから大いに構いますが...(^^;

＞# そもそもuser agentが & の代わりに ; を生成するというのはやりすぎ?

www-form-urlencodedを使っているんなら、';'は書けないですし、そうじゃないなら
'&'は'&'として渡してほしいです。

ただし、ここからは実装上の話になるわけですが、request lineでも(www-form-urlencoded)な
entity bodyでも『区切り記号に'&'ないし';'を使い、項目と値の区切りに'='を使い、
文字はurlencodeされている可能性がある』という、緩いwww-form-urlencoded形式を入力に
仮定することは安全な選択かな、と言う気はします。

＃ まあ、どうせ、正しいwww-form-urlencoded中に';'は来ないので、あくまでもアルゴリズム上の
＃ 正しさ、と言うか、意味上はどうあるべきなのか、と言うことだけに尽きるのですが。(^^;
＃＃ あ、へぼなUserAgentからのfool proofをとるためにはどちらが良いのか、というのもあるな。


＞ちょっとびっくりしました:)  思ったより簡単に実現しそうですね。

＃ この頃サボって顔出していなかったので、少し強力な召喚呪文を唱える必要があるかしらと...(^^;;;

実は、プレヴューモードのソース表示を貼り付けて、ちょっと編集しただけなので、大して
手間はかからなかったのですが、実際に実装する場合には、Followup-To:先のCGIの
URLと部屋名を知らないと指定できないので、その辺をどうすれば良いのかがポイントですね。

今のユーザカスタマイズ設定の転送みたいに直書きさせたのでは使いづらいし、第一、
間違いが多くなって、フォローアップ先が見つからないことが多くなってしまうでしょうから、
複数会議室間の有機的リンク機構が働くようになった後の話かもしれませんね。(^^;
＃ って、いつの事やら。(^^;