人気ブログランキング | 話題のタグを見る

self memo

SoftBankキャリア試験不合格

2つ目の山場だったSoftBankのキャリア試験で不合格になった。
こちらの試験は、直接サービスのリリーススケジュールには(今のところ)影響しないとはいえ、かなりショック…。

不合格の理由は、下記2点。

1.Separate Delivery方式を利用したコンテンツ・キー課金を行うと、端末に"無効なコンテンツのためダウンロードできません"と表示され、課金、ダウンロードとも行えない。

こちらに関しては、今朝の時点でCPさんからも指摘されていた。
不可解なのが、昨日までテスト用に使っていたSoftBankの920Pでは再現しない事だ。
CPさんは、923SH、824SHでも同様の現象が発生したとの事。
世代(C型、P型、W型、3GC型)で挙動が異なる事は覚悟(そして対応)していたが、同じ3GC型でも挙動が異なるとなると、かなり辛い。

コンテンツのダウンロード部分は、DRMをかけているとはいえ直接抜かれる事を避けたいため、phpで認証の上、レスポンスヘッダとともにバイナリを出力するようにしていた。
やはりこの部分が怪しいので、取り急ぎコンテンツ自体をドキュメントルート配下に移動し、コンテンツのダウンロード部分はApacheに任せるように変更。
CPさんに再度確認を依頼すると、やはりうまくいったとの事。
セキュリティ的な理由と、コンテンツのダウンロード履歴をダウンロードphp内で行っている理由から、なんとか現状の作りで対応したいと考え、とりあえずうまくいく時とうまくいかない時のレスポンスヘッダを比較する事に。
モバイルサイトをPCで見るためのツールやFirefoxアドオンを参考にして、Proxomitronと、SwitchProxy Tool(FFのアドオン)をインストール

●うまくいく時のレスポンスヘッダ
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 04:16:49 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch11 mod_perl/2.0.2 Perl/v5.8.8
Last-Modified: Fri, 15 Aug 2008 02:52:36 GMT
ETag: "c038c-304dd-b6c3c500"
Accept-Ranges: bytes
Content-Length: 197853
Content-Type: application/vnd.oma.drm.message; boundary=boundary-1


●うまくいかない時のレスポンスヘッダ
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 04:07:09 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch11 mod_perl/2.0.2 Perl/v5.8.8
X-Powered-By: PHP/5.2.0-8+etch11
Pragma: no-cache
Content-Length: 197853
Content-Type: application/vnd.oma.drm.message; boundary=boundary-1


まずは、
"Accept-Ranges: bytes"
がないということで、ダウンロードphpに
header('Accept-Ranges: bytes');
を追加。

次に、"Etag"出してないということで、313.PHP で Apache 風 ETag の生成を参考にして、
$stats = stat( $_SERVER['SCRIPT_FILENAME'] );
$etag = sprintf( '"%x-%x-%x"', $stats['ino'], $stats['size'], $stats['mtime'] );
header('ETag: '.$etag);
を追加。

次に、うまくいかない時の"X-Powered-By: PHP/5.2.0-8+etch11"が鬱陶しいので、php.iniの中でexpose_phpをOnからOffに変更し、Apacheリスタート。

こうする事で、レスポンスヘッダは以下のように変わった。
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 05:27:12 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch11 mod_perl/2.0.2 Perl/v5.8.8
ETag: "c038c-304dd-b6c3c500"
Accept-Ranges: bytes
Pragma: no-cache
Content-Length: 197853
Content-Type: application/vnd.oma.drm.message; boundary=boundary-1

よし、"Pragma: no-cache"以外は同じになったという事で、再度CPさんに確認依頼。
すると、なんとまだ駄目だとの事…。
なぜだ!

ふとDRMかけたdm(drm.message)ファイルの中身を見ると、マルチバイト文字が含まれてる!
phpが出力時に変換している事が原因に違いないと考え、ダウンロードphpに、
mb_http_output("utf-8");
を追加し、再度CPさんに確認依頼。

すると、なんとまたもや駄目だとの事…。
なんだってんだ!!

やばい、時間が無い。
とりあえずdmファイルをドキュメントルート配下に配置する事によりダウンロードは出来るが、履歴が取れない。これも致命的。

ここで、ダウンロードphpでの対応を諦め、SoftBankからダウンロード完了通知を受け取るようにパラメータを追加し、受け口の履歴書き込み用phpを慌てて作成。

再々度CPさんに確認依頼すると、今度はOKとの事。
なんとか目的は達したが、かなりSoftBankに依存した作りになってしまった。
この対応を完了したのが今日の16時ぐらい。

後からログを見て分かったのだが、SoftBankが試験をしていたのは今朝の10時頃だったので、時既に遅し。


もう一つ試験に引っかかった点。

2.C型端末でアクセスすると、UIDを通知していても、"UIDを通知して下さい"とのエラーメッセージが表示される

あーーー、やっちまった。
そもそも今回のサービスの対応端末は、3GC型のみという仕様だったので、C型端末からUIDを取得する処理を入れていなかったのだが、エラーチェックする順番が、
1.UIDが取れるか?
2.対応端末(3GC型)か?
という順番にチェックしてたので、C型端末にて"対応端末ではありません"とのエラーを表示できていなかった。
これは、完全に俺のミスだ。
エラーチェックの順序を、
1.対応端末(3GC型)か?
2.UIDが取れるか?
に変更し、C型端末がUIDを通知してようがしてまいが、"対応端末ではありません"を表示するようにした。

何とか次の再試験で通ってくれー!

---------- 追記(2008/08/18 20:37) ----------
うまくいく時とうまくいかない時のレスポンスヘッダを改めて見てみたら、"Last-Modified"を出力してないじゃん!という事に気づいたので、
header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT');
を追記。
そうする事により、レスポンスヘッダは以下のようになった。
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 11:33:43 GMT
Server: Apache/2.2.3 (Debian) mod_perl/2.0.2 Perl/v5.8.8
Pragma: no-cache
Accept-Ranges: bytes
ETag: "bd04d-27b5-48a95dd1"
Last-Modified: Mon, 18 Aug 2008 11:33:43 GMT
Content-Length: 176819
Content-Type: application/vnd.oma.drm.message; boundary=boundary-1

希望を持って、再度テストするも、やはり駄目…。

お手上げっす。
by aratafuji | 2008-08-18 20:09 | つぶやき