Re: 300-500 status codes and fallback pages

Chrome has a non-standard mechanism to disable the fallback behavior that
is spec'd to happen on 4xx or 5xx error responses. If the error response
contains a particular header value, that response is not blocked and
replace with the fallback resource.

   "x-chromium-appcache-fallback-override: disallow-fallback"




On Mon, Oct 8, 2012 at 7:39 AM, Patrick Gillespie <patorjk@gmail.com> wrote:

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