2014年1月8日水曜日

Android標準ブラウザの不思議な挙動

Android標準ブラウザでダウンロードを行った際、なんかうまくいかなかったことがあった時の考察メモ。
8割あってる気はしてるけど確証が持てないそんなお話。

Android標準ブラウザは2度刺す

はい、Eカードネタです。

1. 事象

事象自体は単純。
【Android】の【標準ブラウザ】で【のみ】、【ダウンロードが失敗する】というお話。
Chromeであれば問題なくダウンロードできるし、iPhoneでは普通に表示される。標準ブラウザのみ、
こんな感じで、<無題>のままいつまでたってもダウンロードが終わらず、ダウンロードマネージャを見ると【失敗】となっている状態。(仮に【事象1】とする)
また、上記とは別に、
と、にべもなく瞬殺されるケースも。(こちらを【事象2】とする)

2. 前提

上記2つの事象に対して考察を行う前に、一つ前提としておきたい【仕様】がある。
それは、
【Android標準ブラウザは、表示用プロセスとダウンロードプロセスの2種類を持つ】ということである。
これにより、ダウンロードしながらブラウジングができる、というメリットはあるのだが…

3. 考察

実は【事象2】に関しては、いろいろな人がぶつかっているらしい。その原因は、【Basic認証】にあるという。
前提 の通り、【Android標準ブラウザ】は普段【表示プロセス】で表示、リクエストを行う。しかし、ダウンロードを行う段階に入ると、【ダウンロードプロセス】にそのダウンロードを委譲するが、【ダウンロードプロセス】が「ダウンロードさせてよ( ・ω・)」と投げるリクエストは、【表示プロセス】のリクエストとは異なるリクエストになるため、【Basic認証】を通ることができなくなる、らしい。

じゃあ【事象1】も同じか、と思うとそうでもない。そもそも事象が違うし、【事象1】が発生した環境では【Basic認証】もかかっていない。じゃあ何が【事象1】みたいにブロックしてるのかと考えた時浮かんだのが、

…【自己証明書】?('A`)

【事象1】の環境では、いわゆる【オレオレ証明】を持つhttps区間内での出来事。白で塗りつぶしている部分にはダウンロード対象のドメインが入っていたため、通信自体は通っているっぽい。
すると、
【オレオレ証明】を認めますか?という問いに返答しようにも、【ダウンロードプロセス】はUIを持たないため、ユーザーは答えることができないまま、【ダウンロードプロセス】は待機を続けていた
ということになるのだろうか…
過程がどうにしろ、少なくとも【オレオレ証明】でなくなった途端【事象1】は発生しなくなったので、【事象1】の犯人はこいつで間違いないと思われる。





でも確証が無いのがなぁ…('A`)

参考

0 件のコメント:

コメントを投稿

AWS CDKで立てたEC2インスタンスのTimeZoneとかいじりたかった話

EC2を立てることはできたけど、立てたインスタンスは UTCのままだし設定ファイルとかいちいちscpしてくるのはダルい。 当初UserDataでなんとかしようとしたものの、「書く量がヤバいしメンテしにくい」と悩んでいたところ見かけたのが  AWS::CloudFormation:...