iPhone の NSURLRequest で gzip 使ってみた

http://stackoverflow.com/questions/2682483/nsurlconnection-nsurlrequest-gzip-support

こちらに記載があるとおり、 Cocoa の NSURLConnection はgzip圧縮されたコンテンツを自動的に解凍して扱ってくれるみたいです。gzipでリクエストを受け取るには、以下のように NSURLRequest のヘッダに値を追加します。

[urlReq setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"];

これだけで後はすべて自動的にやってくれます。もちろんサーバー側がきちんとgzip圧縮して返すように設定されていなければなりません。


■パフォーマンスを試してみる

サーバーと通信を行い、レスポンスとして1000行程度のXMLを取得して解析するアプリで実験してみました。iPhone 3GS, Wifi回線を使用。

圧縮無しの時の結果はこちら。

API①
16:11:58.822 開始
16:12:04.126 レスポンス受信
16:12:04.184 データ受信
16:12:05.322 パース完了

API②
16:11:58.838 開始
16:12:04.118 レスポンス受信
16:12:04.433 データ受信
16:12:07.276 パース完了

API③
16:11:58.847 開始
16:12:04.718 レスポンス受信
16:12:05.822 データ受信
16:12:08.299 パース完了

圧縮ありの時の結果はこちら。

API①
16:03:43.056 開始
16:03:46.349 レスポンス受信
16:03:46.414 データ受信
16:03:48.473 パース完了

API②
16:03:43.080 開始
16:03:46.326 レスポンス受信
16:03:46.671 データ受信
16:03:49.905 パース完了

API③
16:03:43.088 開始
16:03:46.308 レスポンス受信
16:03:46.371 データ受信
16:03:47.532 パース完了

一回しか試していないのでムラはありそうですが、通信自体は確実に早くなっている気がします。3Gで計測すればさらに顕著な違いになると思うのでおすすめです。

iPhoneやiPhoneシミュレータ上でNSURLCacheクラスを使う

• NSURLConnectionやNSURLDownloadを利用すると自動的にNSURLCacheにキャッシュデータを蓄える
• iPhoneシミュレータは/private/var/folders/XX/XXXXXXXXXXXXXXXXXXXXXXX/-Caches-/iPhoneのアプリ名/Cache.dbの中にキャッシュデータを蓄えている
• iPhone実機では、メモリ上へのキャッシュは働くがファイル上へのキャッシュは行われない。したがってアプリを終了するとキャッシュはすべて消える。
• NSURLCacheクラスについて参考 http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/863005881931/p/5
• [NSURLRequest setCachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData];を使って、意図的にNSURLCacheクラスへのキャッシュを止めることもできる
• キャッシュを停止する方法の例 http://github.com/takuma104/ntlniph/tree/master/Classes/models/NTLNHttpClient.m 76行目

HTTP通信を行う際にキャッシュを使いたい場合があると思います。
特に通信状況の良くないiPhoneプログラムでは、キャッシュを利用したいと思う機会が多いはずです。
Cocoaフレームワーク上でHTTP通信を行う場合には、NSURLConnectionクラスやNSURLDownloadクラスを利用するのが一般的だと思いますが、
これらの通信クラスを利用すると、自動的にNSURLCacheクラスのShared Instanceに通信結果がキャッシュされていくようなしくみになっています。

キャッシュされた結果は以下のようなコードで取り出せます。

  NSURL *url = [NSURL URLWithString: urlStr];
NSURLRequest *request = [NSURLRequest requestWithURL:url];
//キャッシュされたURLレスポンスを、NSURLCacheのshared instanceから取得します
NSCachedURLResponse *cachedData = [[NSURLCache sharedURLCache] cachedResponseForRequest:request];

こうして取得されたNSCachedURLResponseは通常のNSURLResponseと同じように扱うことができます。

で、問題になってくるのはここからです。
このNSURLCacheクラスは2種類のキャッシュを内部的に持っています。メモリキャッシュとファイルキャッシュです。
メモリキャッシュの方はもはや説明不要だと思うのですが、やっかいなのはファイルキャッシュのほうです。再起動しても結果が消えないため、以前の結果が表示されると言うことが起こりえます。
iPhoneシミュレータ上で実行された場合、どこにこのURLレスポンスのキャッシュが保存されているかを調べてみたところ、

/private/var/folders/XX/XXXXXXXXXXXXXXXXXXXXXXX/-Caches-/iPhoneのアプリ名/Cache.db

の中にキャッシュが生成されていることがわかりました。（XXの部分は実行するマシンによって異なります。）
従って、キャッシュが不要になった場合はこのファイルを消してください。

Cocoa（iPhone）で、日本語を含むURLを開く方法

• 基本的にはCore FoundationのC関数を利用する
  CFURLCreateStringByAddingPercentEscapes()
• ただし、一部問題のあるケースがある
  URL中に&を含む場合などは正しく作れないので別の方法が必要

プログラマをやっていると、だんだんと日本語が嫌いになってきます。
いや、嫌いというのはおかしいのですが、とにかく英語以外の言語はトラブルが多いです。
コンピューターというのはつくづく英語を処理するためだけに作られているのだと思います。
（だからこそ、プログラムの「国際化」で飯を食える人がいる訳ですけど！）

すみません、前置きが愚痴っぽくなってしまいました。
iPhoneプログラミングにおいてももちろん、日本語を使う際に罠があります。
たとえばNSURLRequestなどがそうです。
日本語の含まれるURLを開こうとすると、うまく解釈してくれないんです。
（といいますか日本語が含まれるURLはURLエンコードしなくちゃいけないんです。・・・当たり前ですね）

例えばこんな感じです：

http://s3.amazonaws.com/twitter_production/profile_images/65140989/るーみゃ_normal.jpeg

自分の画像だけ出ないぞ！

そこでURLエンコーディングを行う関数を探してみたところ、ありました。
Cocoaで日本語のGETを飛ばそう！

早速真似してやってみました。
CFURLCreateStringByAddingPercentEscapes()関数を使うのがポイントらしいです。

            NSString *originalUrl = [userDict objectForKey:@"profile_image_url"];
           NSString *encodedUrl = (NSString *) CFURLCreateStringByAddingPercentEscapes
           (NULL, (CFStringRef) originalUrl, NULL, NULL, kCFStringEncodingUTF8);
           person.profile_image_url = encodedUrl;

たったのこれだけでうまくいきました！



ところが、有頂天になってTwitter上で騒いでたら、
@psychsさんから突っ込みが。

JavaScriptでいうencodeURI相当なんで、
日本を適当にエスケープしたいときにはいいんだけど、
たとえばパラメタに「&」を入れたい場合とかは、
ちゃんとencodeURIComponent 相当のやつを使って組み立てなきゃだめだよ

なんと具体的なアドバイス！（ありがとうございます！）ちょっと調べてみました。
javascript: escape(), encodeURI(), encodeURIComponent() 比較

細かいところはわかりませんが、とにかく一部の文字がエンコーディングされないみたいなのです。
深刻なのは?とか=とかでしょうか。気をつけないとトラブルに巻き込まれそうですね。

ちなみにiPhoneでencodeURIComponent相当のエンコーディングを行うためにはどうすればよいのかですが、
リファレンスを引いてみても特にそれらしきものは見当たりませんでした。
ひょっとしたら自分でやるしかないかもしれません。

■2008/12/29 22:00追記
Twitter上で、@norio_nomuraさんにencodeURIComponent相当のエンコードを行う方法を教えていただきました！ありがとうございました！
http://twitter.com/norio_nomura/status/1083641557

CFURLCreateStringByAddingPercentEscapes(NULL, string, NULL, CFSTR (";,/?:@&=+$#"), kCFStringEncodingUTF8);

最大のポイントは、第4引数のCFSTRです。ここで指定した文字列はエンコードされずにそのまま残るようです。
第4引数をNULLのまま使うと標準のencodeURL相当になり、
この例のように指定すると、encodeURLComponent相当のエンコードが可能になります！

NSURLConnection使用中にbad server certificationエラーが出たときの対処法

• 1203, NSURLErrorDomain, bad server certificate
• このエラーはSSL使用時に証明書の内容が不正なときに発生する
• 要するに自己認証証明書（オレオレ証明書）警告
• 標準APIにはこのオレオレ証明書警告をオフにする機能がない
• NSURLRequestのallowsAnyHTTPSCertificateForHost:をオーバーライドすることで回避可能

皆さんも、自宅に自分用のサーバーをお持ちだったり、会社のサーバーに業務でアクセスしたりということがあると思います。
こういうちょっとしたサーバーでは、たいていの場合正式な認証局が発行したものではない、自己認証による証明書、
いわゆる「オレオレ証明書」によるSSH認証が行われています。

便利だし、正式な認証局に頼むとお金が必要になったりでついついやってしまいますよね。
ブラウザからアクセスすると警告が出ますが、無視してしまえばなんてことはありません。

ところが。
iPhoneのアプリからこうした「オレオレ証明書」を利用しているサーバーに対して、
NSURLConnectクラスを用いてアクセスしようとすると

1203, NSURLErrorDomain, bad server certificate

というエラー（NSErrorのインスタンス）が発生し、処理が中断されてしまいます。
Appleさんちょっと厳しいですって。
（たとえば、Pythonでliburlを利用してアクセスしたときはたとえオレオレ証明書でも一切怒られません）
しかも困ったことに、このエラーを回避する方法が標準APIに用意されていません。
対策はただひとつ、「オレオレ証明書なんて使うな、Verisignにお金払え」ということらしいです。

オレオレ証明書なんて許さないぞという決意は大変良く分かりますが、
自宅のサーバーならともかく、会社のサーバーでは自分が勝手に証明書取るわけにもいかず。
困りました。

そこで先人たちがNSURLRequestクラスのprivateなメソッドを利用する回避手段を編み出してくださいました。
http://lists.apple.com/archives/Macnetworkprog/2006/Nov/msg00020.html
http://www.phapper.com/Default.aspx?g=posts&m=8


この方法に従って、NSURLConnectionクラス（およびNSURLRequestクラス）を利用する箇所で、以下のようなクラスカテゴリ実装を行います。

@implementation NSURLRequest(NSHTTPURLRequest)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
 return YES; // Or whatever logic
}
@end

これで全てのオレオレ証明書の認証を回避することが出来ます。
もし特定のホストのみを回避したいのであれば、以下のように適当なロジックを組んでやればいいと思います。

@implementation NSURLRequest(NSHTTPURLRequest)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
 return [@"ba-tyan.oreore.com" isEqual:host];
}
@end

iPhoneではAdHocによって100人までは自由にアプリを配布することが出来ますので、
App Storeを利用しない、自分専用・内輪向けのハックアプリなんかをこうして作っても面白いですね。
でも、せっかくiPhoneで開発するならApp Storeに挑戦しなければ損！もちろん、そのうち挑戦しますよ？