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
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
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 i...@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? -- 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
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 i...@hixie.ch 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. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
Cross posted to h...@whatwg.org two days, but forwarding here since I think this might be a problem with the spec/implementation. As it stands now, I think the only way I see out of this pinch is to make my 404 and 500 error pages return 200 response codes. Thanks! Josh -- Forwarded message -- From: Josh Sharpe josh.m.sha...@gmail.com Date: Wed, Aug 22, 2012 at 11:06 AM Subject: fallback section taking over for 4xx and 5xx responses while online To: h...@lists.whatwg.org 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 / /online 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. 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. Since there is an error, and the url matches, the fallback section is triggered, displaying the contents of /offline and not the response from the given URL. 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. While online, I would expect my 4xx and 5xx page to be rendered normally. 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. Should I design this differently or is there something missing from the spec? Thanks, Josh
