Re: 300-500 status codes and fallback pages

... but that mechanism does not currently apply to cross-origin 3xx
redirect responses. Cross-origin 3xx redirects should always trigger the
fallback behavior.

This was added to chrome to support a use case where an error response was
expected while online in the context of Google Docs. An attempt to do
something with a 'doc' that had been deleted or whose permissions had
changed such that the current user had no access would result in an error
response that should be shown to the user. The default fallback behavior
was getting in the way of that.

This half-measure with the extra header got us out of a bind, but it's not
very satisfying as a general solution.


On Tue, Oct 9, 2012 at 1:32 PM, Michael Nordman <michaeln@google.com> wrote:

> 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.
>>>
>>
As for "devs can choose when and how a particular request...", its
difficult to imagine a declarative syntax expressive enough to satisfy
that. I always come back to providing very fine grained control by way of
script execution that can inspect response status codes and header values
and either compose a response or pick a cached response as desired. Seems
like the inevitable conclusion.

As for "the fallback page should have knowledge of what happened", its
pretty easy to imagine an API that exposes info about the response that
triggered the fallback behavior to a resulting fallback page...
handwavvy.... applicationCache.fallbackReason.statusCode.



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