Re: 300-500 status codes and fallback pages

It looks like Chrome and FireFox differ in their treatment of redirects to
different domains. FireFox will use a fallback page, while Chrome will do
the redirect. I think using a fallback page for redirects to different
domains is a bad idea, since it messes up web apps that need to switch
domains (the redirects on the old domain would instead trigger the fallback
pages), and it makes logging in via a different domain a pain.

best,

- Pat

On Mon, Oct 8, 2012 at 5:50 AM, Jake Archibald <jaffathecake@gmail.com>wrote:

> 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.
>