Re: 300-500 status codes and fallback pages

@Patrick
> It appears as if cross-origin 3xx redirect responses work in Chrome and
Safari, but do not work in FireFox. I setup a quick test case:

I can explain why in Chrome and Safari the redirect you've setup is
followed. In a nutshell, because it's a frame navigation and not a
subresource load. There are subtle differences in how the those two cases
are specified to be handled. Main resource loads are described in
mind-numbing detail here....

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigating-across-documents
and subresource loads here...

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
Sounds to me like FireFox does not make this distinction and has a bug.

@Andrew
> How do you deal with this use case in browsers other than Chrome?

Afaik, I don't think you can. If a requested url is in a fallback namespace
an error response will trigger the fallback. There's no way to say some
errors trigger it and other don't.




On Wed, Oct 10, 2012 at 5:16 AM, Patrick Gillespie <patorjk@gmail.com>wrote:

> > ... but that mechanism does not currently apply to cross-origin 3xx
> redirect responses. Cross-origin 3xx redirects should always trigger the
> fallback behavior.
>
> It appears as if cross-origin 3xx redirect responses work in Chrome and
> Safari, but do not work in FireFox. I setup a quick test case:
>
> http://patrickgillespie.com/fallback-test-1/
>
> If you're using Chrome or Safari and you click the first link on that
> page, you'll be redirected to Google. If you're using FireFox and you click
> the first link on that page, you'll get the fallback page. The browsers
> appear to be handling this differently. I prefer how Chrome and Safari
> handle it, since bringing up the fallback page for a redirect would mess up
> sites that need to change domains in the future. However, if sending a
> special header would fix the issue, I'd be fine with that.
>
> best,
>
> - Pat
>
>
> On Wed, Oct 10, 2012 at 5:44 AM, Jake Archibald <jaffathecake@gmail.com>wrote:
>
>> On 10 October 2012 10:41, Tobie Langel <tobie@fb.com> wrote:
>> > This need to be captured in a use case and requirements.
>>
>> How's this as a use case (from a couple of posts ago)
>>
>> 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.
>>
>
>