iOS6 の safari の ajax POST のキャッシュを検証

iOS 6 Safari caches AJAX POST requests — Daniel15

上の記事などで、iOS6 の safari は ajax の POST リクエストをキャッシュしているという話を読んだので検証してみました。

まずは、以下のようなランダムな色を生成する API を作成。

<?php
echo 'hsl(' . rand(0, 360) . ',' . rand(0, 100) . '%, 50%)';

上の API を、$.get と $.post で取得してみて、
返ってきた色を並べるデモページを作成。

デモページ

結果

確かに、iOS6 の safari は ajax の post をキャッシュしているようでした。
しかも、なぜか、GET リクエストのキャッシュよりも強いポリシーで POST リクエストをキャッシュしている模様。

ちなみに、http ヘッダーで Cache-Control: no-cache を指定すれば、普通にキャッシュしなくなるようでした。

デモページ

その他, 細かい事:
- 全く同じ ajax POST リクエストをし続ける限り、ページをリロードしてもキャッシュを使い続ける。
- GET リクエストが挟まると、POST のキャッシュがリセットされる。(上のデモで POST → GET → POST とやるとキャッシュが使われない)


ということで、とりあえず、POST で叩かれる可能性のある API で、iOS6 の safari をサポートする必要がある場合には、Cache-Control ヘッダーを入れるのがほぼ必須かと思いました。

参考: iOS6 Safari Caching $.ajax Results - Stack Overflow

Accept-charset in IE

たとえば、API 経由で 何かを POST したいときなんかに、

フォームのあるページの文字コードと、POST の受け側の文字コードが

違うという場合があって、そういう時にそのままPOSTすると、日本語が文字化けする。

そういう時の為の HTML 属性があって、　たとえば、<form charset="utf-8">

とかすると、もとのページの文字コードに関係なく、utf-8 でエンコードしたデータ

を POST することが出来る。

はず、なのだけど、IE だと、なぜか上の指定が効かなかったりする。

web を眺めていると主に 2通りの解決方法が考えられていて、

一つは onclick などで、submit に対して、javascript をフックして、

document.charset = "utf-8";

などとして、ページの文字コードを変換してしまう方法。

もうひとつは、そもそも、accept-charset が無視されるのは、

form の input の中にそのページの文字コードで解釈できない文字がある場合だけだ

という、tips を利用し、ダミーで

<input type="hidden" name="dummyForIE" value="&#65533;">

というようなフォームを用意して、強制的に、accept-charset を解釈させるという方法。

元の文字コードで表示できなくて、POST 先の文字コードでは表示出来る文字がすぐに

分かるのであれば、後者のやり方の方が良さそう。

(上のダミー input は ecu-jp から、utf-8 の場合の例)

/etc/motd

Amazon EC2 で、RightScale 提供の CentOS イメージを
ベースにして、MoE のテスト/開発サーバーを作成中、
どうも、最初のログイン時の welcome メッセージが
しっくりこない。

     ___   _        __   __   ____            __
    / _ \ (_)___ _ / /  / /_ / __/____ ___ _ / /___
   / , _// // _ `// _ \/ __/_\ \ / __// _ `// // -_)
  /_/|_|/_/ \_, //_//_/\__//___/ \__/ \_,_//_/ \__/
           /___/

Welcome to a public Amazon EC2 image brought to you by RightScale!

********************************************************************
********************************************************************
***       Your EC2 Instance is now operational.                  ***
***       All of the configuration has completed.                ***
***       Please check /var/log/install for details.             ***
********************************************************************
********************************************************************

このメッセージは一体どこから出ているのだろうと思って、

~/.bash_profile
~/.bashrc
/etc/bashrc
/etc/profile
/etc/profile.d/*

あたりのファイルを端から見ていったけど、どうも、それらしいところが
見つからない。
読んだ感じだと、/etc/profile が一番最初に呼ばれていそうな感じがしたけど、
/etc/profile の先頭に echo test と書いても、
上のバナーの下に test と表示されてしまう。
その後すこし調べたところ、/etc/motd というのを発見。

Message Of The Day

の略で、その日のお知らせをユーザーに知らせるためのファイルらしい。
分かるか。

CodeIgniter 言語ファイル

デフォルトでインストールした状態だと、
system/language/japanese というディレクトリが出来てるのに、
動かそうとすると、なぜか
system/language/ja
というディレクトリにアクセスしようとして、言語ファイルが無いと言う。
system/language 以下に、ja という japanese への
シンボリックリンクを貼って解決。
なんでこんな風になっているのか？

default character set latin1

http://sourceforge.jp/projects/codeigniter/lists/archive/users/2008-February/000337.html
http://wota.jp/ac/?date=20061011
http://d.hatena.ne.jp/tueda_wolf/20080716/p7
http://www.abe-tatsuya.com/web_prog/mysql/mycnf_xampp_mysql_1.php

この辺を見ながら、mysql のデフォルトの文字コードを utf8 に変更。
latin1 とか誰が嬉しいんだろう・・・
freebsd の ports からのインストールだと、 /etc/my.cnf がデフォルトで
出来ていないという仕様もなんだか非常に分かりづらい気がする・・・

WP Security Scan でテーブルの prefix を書き換えたら、ログインできなくなった。

WP Security Scan という wordpress のプラグインによれば、
wordpress をインストールした時のデフォルトのデータベースのテーブルのプレフィクスの
"wp_" を、そのままで使うのは危険らしい。
で、そこをクリアしておいて、と橋場さんから頼まれたので、
そのままポチッと、WP Security Scan プラグインの機能の
テーブルプレフィクスを書き換えボタンを押してみたら、
見事に管理画面全体にログインできなくなった。

http://wordpress.org/support/topic/256981

http://beconfused.com/2007/08/28/how-to-solve-you-do-not-have-sufficient-permissions-to-access-this-page-in-wordpress/

上２つを見て、データベース内の wp_usermeta テーブル内の wp_capabilities というレコード
のプレフィクスをユーザー数分だけ、手で書き換えたら、入れるようになった。
メンテナンスされてないプラグインて怖い。

UINavigationBar の挙動が邪悪な件

Cocoa Touch フレームワークの UIKit の UINavigationBar の挙動が邪悪(=非論理的)な気がする。

View hierarchy を無視して、親ビューのサイズとかオフセットを無視して、
勝手な位置に固定サイズで勝手に表示される。どうにかコントロールできないものか・・・