- From: Andrew Betts <andrew.betts@ft.com>
- Date: Fri, 21 Sep 2012 00:13:26 +0100
- To: public-fixing-appcache@w3.org
The app cache spec envisions the possibility of a captive portal (a WiFi hotspot login page) being returned by a network rather than the resource requested, and therefore considers an HTTP redirect response to be an indication that the connection is offline for the purposes of choosing to serve a fallback from cache rather than the response from the network. However, today we've been looking at the possibility that a captive portal simply returns a login page on the URL you requested rather than returning a redirect. It wouldn't be good practice, but it would be technically feasible. In that situation, potentially our user will get the captive portal page appearing in our app, and will have to - rather ironically - turn off their network connectivity in order to get the app to work. 1. Does anyone see a solution to this within the current app cache spec / implementation? 2. In practice has anyone ever encountered a captive portal that behaves like this? 3. Do we care about this use case? 4. If so, is it on the list (tobie?) Andrew Andrew Betts [skype:triblondon | @triblondon] Director, FT Labs [labs.ft.com | 0870 085 2038 | @ftlabs] -- ------------------------------ This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL. Registered in England and Wales with company number 53723.
Received on Thursday, 20 September 2012 23:13:49 UTC