Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online

On Mon, 17 Dec 2012, David Barrett-Kahn wrote:
> On Mon, Dec 17, 2012 at 3:30 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Tue, 11 Dec 2012, David Barrett-Kahn wrote:
> > >
> > > We ran into this same problem on Google Docs offline.  Our solution 
> > > was to add a proprietary response header to Chrome which instructs 
> > > the browser that the response is not to trigger the fallback entry, 
> > > despite its response code.  Something like it could be considered 
> > > for standardization. I know there are some people on the Chrome team 
> > > looking to advance some new appcache features, and that this use 
> > > case is on their list.
> >
> > Can you elaborate on the need for this feature? Why would you ever 
> > send the user to a 404 page intentionally (i.e. when the server isn't 
> > broken)? Similarly, why would you not consider the server returning 
> > 500 a good indication that the cache should be used?
>
> Generally speaking, this feature is useful where the error page is 
> somewhat routine and contains information comprehensible and actionable 
> by the user, which would otherwise be lost in the fallback.
> 
> This was mainly about 404s, which docs will serve when a requested 
> document id doesn't exist, which includes cases where it was deleted.  
> All our offline application could say (once triggered) was that the 
> document was not present in our local storage.  It couldn't say the 
> document didn't actually exist.  We therefore wanted the server's 
> version of the error page to be displayed.  401/403 were also of 
> interest, mainly for cases where the user had previously had access to a 
> document, but that access had been rescinded.  Whether it's a good idea 
> to divert 500s kind of depends on what they are, especially whether the 
> served error page contains user-actionable information.
> 
> The current generation of docs offline attempts to only engage the 
> browser's offline machinery when truly offline.  For example, the 
> regular docs pages one interacts with when online do not bind appcaches.  
> We have a fallback entry covering the entire origin which engages this 
> machinery, loading a 'controller' style application which decides how to 
> handle whatever URL was provided.  We have this strict separation for 
> two reasons. First, we were very keen to ensure that instability in the 
> new offline technologies we were using never lead to disruption of the 
> online solution, especially during early development.  Second, the 
> online start-up procedures used by our applications are complex and 
> highly optimized, and fundamentally incompatible with appcache due to a 
> 'blending' of the document and the application.  We wanted to preserve 
> those optimizations online and have a different startup procedure when 
> offline.

Interesting.

The AppCache API was really designed more around a model where the editor 
and the data were completely separate, and the data was obtained by the 
script using XHR or WebSocket and cached locally manually using IndexDB or 
Web Storage or some such. So yeah, the above use case isn't handled.

I've filed a bug to track this, but in pracrice I expect that Service 
Workers will subsume most of the appcache feature requests.

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25525


On Thu, 20 Dec 2012, Mikko Rantalainen wrote:
> 
> I'm not sure about 404 but if the UA is able to connect the server and 
> gets HTTP 410 Gone, I'd be pretty upset if cached offline copy would be 
> used automatically. The server has clearly responded that the requested 
> document is intentionally removed. End user seeing cached (stale) copy 
> instead is very far from intented result in this case.
>
> In my opinion the UA should *always* use server returned response if 
> server responded at all.

The original thinking here was that the server here might not be the 
original server, but might instead be a captive portal. It's far worse to 
start clearing appcaches because you happened to be connected to a captive 
portal than it is to display the old offline file instead of saying the 
file is now gone. After all, if the file is gone, why is it listed in the 
manifest?


On Thu, 20 Dec 2012, Michael Nordman wrote:
>
> It'd be loads better if application logic were directly responsible for 
> making these sort of policy decisions regarding what cached resource to 
> use under what circumstance.

I believe that's the approach that Service Workers will provide.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 30 April 2014 22:36:06 UTC