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 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
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. Obscure least-common-denominator rules baked into the user agent with even more obscure ways to override that least-common-denominator behavior just isn't working out very well. > In my opinion the UA should *always* use server returned... And in some other developers opinion, that would defeat efforts to make the client resilient to 5xx errors. On Thu, Dec 20, 2012 at 2:24 AM, Mikko Rantalainen < mikko.rantalai...@peda.net> wrote: > 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. >
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
Ian Hickson, 2012-12-17 23:30 (Europe/Helsinki): > On Tue, 11 Dec 2012, David Barrett-Kahn wrote: >> browser that the response is not to trigger the fallback entry, despite >> its response code. Something like it could be considered for > > 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? 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. If UA cannot connect to the server or server does not return any response in UA defined timeout, then use offline version automatically. For 4xx and 5xx online responses, perhaps provide UI to allow viewing stale offline copy instead of server response. For example, in case of Firefox, perhaps display the yellow bar at top-of-the-page saying that "An offline copy of this document is available" with a button "Show offline copy". I would be somewhat okay with 404 and 503 getting "fallback to offline copy silently" but any other response that UA receives should be used instead of offline copy. In both cases, I'd prefer being able to see the actual response. For example, a well made 503 would contain human readable information about when the service is available again. Redirecting 4xx and 5xx responses to offline copy silently would only work if a HTTP header such as Response-Origin: generic-http-server-error did exist. The idea is that if the error message is generated by Apache, IIS or some other non-application specific software, then fallback to offline copy. In all other cases, it's probably a good idea to display the server response. -- Mikko
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
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. -Dave On Mon, Dec 17, 2012 at 3:30 PM, Ian Hickson 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? > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- -Dave
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
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. For the time being, that header and the 'make everything a 200' solutions are the only ones I know of. https://bugs.webkit.org/show_bug.cgi?id=60493 -Dave On Mon, Dec 10, 2012 at 1:37 PM, Ian Hickson wrote: > On Fri, 24 Aug 2012, Josh Sharpe wrote: > > > > I have a manifest that looks something like this: > > > > CACHE MANIFEST > > # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a > > /a/application.js > > /a/application.css > > > > NETWORK: > > * > > > > FALLBACK: > > / /offline > > > > Notably, it has a "/ /offline" fallback section which is, obviously, a > > prefix for every page on my site. This is good, because the goal is to > > have my users redirected to what's at /offline when they navigate to > > www.mydomain.com while offline. > > Note that the Offline Application Cache feature is for Offline > Applications, not Offline Sites. What you're trying to do here is not what > appcache was designed to do. > > Also, it's not clear what you mean by "offline". For the record, in the > spec, "offline" includes "I'm on wifi but there's a captive portal" and > "I'm online but the server is broken". > > > > As the fallback section is a prefix for everything, it's a prefix for any > > url/path that results in an error condition such as a 404 or 500 > response. > > These are cases where it's assumed that the server is broken, i.e. > offline, and the cache is therefore used. > > > > It seems that the application cache, when it encounters an error state > > such as a 404 or 500, doesn't check to see if the browser is still in > > the 'online' state, and immediately falls over to the fallback section. > > It does check -- by definition, if it receives a 4xx or 5xx, it's assumed > that the server is offline (broken). > > > > While online, I would expect my 4xx and 5xx page to be rendered > > normally. > > Offline Application Cache doesn't have a "while online" mode, it just > always works as if you were offline and tries to get the data from the > server while the server is able to respond. > > This is an important facet of how appcache works: it doesn't "work online" > or "work offline". It always acts in "offline" mode (or rather, always > works in "internet connection is flaky" mode). > > > > Finally, the fallback section in my example is very typical of most > > examples I find in various docs, including the whatwg spec. I don't > > think I'm doing anything abnormal here. > > What's abnormal is having the user visit pages that return 4xx or 5xx > error codes when there's no problem. :-) > > > > Should I design this differently or is there something missing from the > > spec? > > It's hard to know exactly without understanding more about your use case. > Can you elaborate on what you're trying to do? > > > We could just exclude 4xx (and maybe 5xx? Though that seems less > reasonable) error codes from being considered "offline" for fallback- > supported resources, if people are commonly linking people to missing > pages intentionally (and don't want the problem hidden from users by > having it fall back to locally-generated pages). But that seems like a > weird thing to do... > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- -Dave
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
On Fri, 24 Aug 2012, Josh Sharpe wrote: > > I have a manifest that looks something like this: > > CACHE MANIFEST > # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a > /a/application.js > /a/application.css > > NETWORK: > * > > FALLBACK: > / /offline > > Notably, it has a "/ /offline" fallback section which is, obviously, a > prefix for every page on my site. This is good, because the goal is to > have my users redirected to what's at /offline when they navigate to > www.mydomain.com while offline. Note that the Offline Application Cache feature is for Offline Applications, not Offline Sites. What you're trying to do here is not what appcache was designed to do. Also, it's not clear what you mean by "offline". For the record, in the spec, "offline" includes "I'm on wifi but there's a captive portal" and "I'm online but the server is broken". > As the fallback section is a prefix for everything, it's a prefix for any > url/path that results in an error condition such as a 404 or 500 response. These are cases where it's assumed that the server is broken, i.e. offline, and the cache is therefore used. > It seems that the application cache, when it encounters an error state > such as a 404 or 500, doesn't check to see if the browser is still in > the 'online' state, and immediately falls over to the fallback section. It does check -- by definition, if it receives a 4xx or 5xx, it's assumed that the server is offline (broken). > While online, I would expect my 4xx and 5xx page to be rendered > normally. Offline Application Cache doesn't have a "while online" mode, it just always works as if you were offline and tries to get the data from the server while the server is able to respond. This is an important facet of how appcache works: it doesn't "work online" or "work offline". It always acts in "offline" mode (or rather, always works in "internet connection is flaky" mode). > Finally, the fallback section in my example is very typical of most > examples I find in various docs, including the whatwg spec. I don't > think I'm doing anything abnormal here. What's abnormal is having the user visit pages that return 4xx or 5xx error codes when there's no problem. :-) > Should I design this differently or is there something missing from the > spec? It's hard to know exactly without understanding more about your use case. Can you elaborate on what you're trying to do? We could just exclude 4xx (and maybe 5xx? Though that seems less reasonable) error codes from being considered "offline" for fallback- supported resources, if people are commonly linking people to missing pages intentionally (and don't want the problem hidden from users by having it fall back to locally-generated pages). But that seems like a weird thing to do... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
