Re: 300-500 status codes and fallback pages

On 4 October 2012 21:39, Chris Wilson <cwilso@google.com> wrote:
> Hey Patrick,
> I'm a little surprised that 3xx codes trigger fallbacks;

They don't unless the redirect is to another domain. This is so
redirects to wifi portals are treated as failures. Although this
conflicts with sites such as mail.google.com, which redirect to
another origin to handle logins.

> I could understand
> 4xx or 5xx (although I can see the counter argument).  I think it would be a
> useful setting, but it's a bit esoteric; we'd have to try to define the
> difference between "server actually responded 404" and "no connection".

This wouldn't be too difficult, as it's the difference between a
status code being present and faily, to a failed request.

A "bug" in the current spec is the reason for FALLBACK cannot be
determined, meaning the site cannot provide meaningful feedback.

I agree with Patrick, I'd like to see a system where devs can choose
when and how a particular request should FALLBACK, and the fallback
page should have knowledge of what happened.

Here's a use-case for the fallback page & manifest update process
providing error feedback:

User is viewing a thread of posts.
User presses "refresh" (this could be the browser refresh, or a page
UI custom refresh)
Connection fails, resulting in a fallback
Page displays "No connection available", "Server error, please try
again later" or another relavent and informative message.

The point is, we don't want to suggest something is the user's fault
(they have no connection) when the fault lies with us (we're 500ing).

Jake.

Received on Monday, 8 October 2012 09:50:44 UTC