Re: Badly behaved captive portals

On 9/24/12 11:11 AM, "Jake Archibald" <jaffathecake@gmail.com> wrote:

>Ahh yes, I follow now...
>
>On 24 September 2012 00:23, Andrew Betts <andrew.betts@ft.com> wrote:
>> I suspect the web solution is some form of the INTERCEPT idea.  But I
>>still
>> don't see any way within the current proposal that a root URL could be
>> intercepted while other URLs on the same domain are not, because the
>> INTERCEPT syntax would treat '/' as a prefix.
>
>Good point. We need a case where...
>
>1. User hits http://app/path/to/something/*
>2. Cached page displays instantly, showing either cached data or
>custom loading screen
>3. Page makes XHR request to
>http://app/api/path/to/something/whatever.json
>4. Page is updated with fresh data from API response
>
>As you point out, this would require something like a global intercept
>that excludes /api/*

Let's not get hung-up on syntax here.

There are multiple way an INTERCEPT-like solution could allow a subset of
requests to reach the network no matter what.

For example, it an intercept-like solution was to be built in JavaScript
(e.g. in a SharedWorker):

self.addEventListener('request', function(e) {
  var pathname = e.url.pathname;
  if (pathname === "/" || !(/$api\/.*/).test(pathname)) {
    var responseBody = appCache.get(pathname);
    if (responseBody) {
      self.postResponse(responseBody);
      // The default behavior is to get the resource from the
      // network, so prevent it here as we found one.
      e.preventDefault();
    }
  }
}, false);

If the intercept solution was to be built using AppCache manifest
semantics, it could be decided to create new semantics for prefix matches,
e.g.:

NETWORK:
/  # matches / only
/* # matches everything

etc.

--tobie

Received on Monday, 24 September 2012 11:36:41 UTC