[13] Webブラウザーなどのクライアントは、プラットフォームによって提供されるネットワークを利用し、 適当な転送プロトコルを使って Webサーバーと通信します。 クライアントのハードウェアにより、あるいは直接接続するネットワークの構成や管理方針により、 利用するネットワークの設定は色々ですから、クライアントは相応の配慮を行わねばなりません。
[2] プラットフォームにより、または利用者エージェント自身により、 次の設定を保持する必要があります。
[4] プラットフォームがどこまで透過的に面倒を見てくれるかは、それぞれに異なります。 薄いプラットフォームで動作するアプリケーションは、色々と自前で実装する必要があります。
[9] プラットフォームといっても OS 自体に機能が組み込まれていることもあれば、 ネットワーク接続の設定を一括で管理する追加のソフトウェアが使われることもあります。 そうしたソフトウェアの中には、特定のクライアントソフトウェアの設定も合わせて切り替えられるものがあります。
[5] 次のような理由でネットワーク接続の状態が変化することがあります。
[1] プラットフォームからそうしたネットワーク接続の状態の変化が通知されたら、 次の処理を行う必要があります。
[22] watchPosition
の処理にネットワークの変化の情報を使うこともできます。
[16] 更に、実行中の HTTP などの下位層の接続があれば、 それも継続不能となって (通常はプラットフォームにより) 終了させられる可能性があります。
[20] IE は従量制課金のネットワーク接続の時、事前レンダリングを無効化します。
[12] WPAD により、または手動で指定された PAC は、 随時更新される可能性がありますから、 適当なタイミングで最新のものを取得し直す必要があります。
[14] ネットワークの接続性はそもそもクライアントとサーバーが通信できるかどうかの大前提ですから、 Webアプリケーションにとっての介入の余地もそれほど大きくはありません。
[15] navigator.onLine
や Service Workers のような機能を使うことで、
ネットワーク接続が得られない状況でもある程度動作する
Webアプリケーションを制作することは可能ですが、それほど一般的ではありません。
[3] draft-cooper-webi-wpad-00 - Web Proxy Auto-Discovery Protocol () https://tools.ietf.org/html/draft-cooper-webi-wpad-00#section-5.2
[17] 939318 – NetworkLinkService should be enabled so Necko can respond to network changes (not offline auto-detection) ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=939318
[18] Issue 566492 - chromium - Security: Previous DNS settings are still used even after changing networks - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=566492
[19] Issue 223876 - chromium - Built-in async DNS resolver needs a reliable equivalent to AI_ADDRCONFIG - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=223876