According to the application cache spec: -- Fetch the resource normally. If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the matched namespace. Abort these steps. -- We currently don't handle the "redirect to a resource with another origin" case.
Dave, what's the result of us not handling this properly here? Trying to figure out whether this needs to block or not...
If someone is connected to a captive portal, and the offline app relies on fallbacks for functionality, the user will get captive portal content instead of the intended fallback.
Fixed typo and perf hit.
Dcamp? Poke for review here.
Attachment #359392 - Flags: review?(dcamp) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #359392 - Attachment description: v1.1 → v1.1 [Check-in comment 6]
Comment on attachment 359392 [details] [diff] [review] v1.1 [Check-in comment 6][Checkin 1.9.1 comment 7] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/70b3cd0bc64f
Attachment #359392 - Attachment description: v1.1 [Check-in comment 6] → v1.1 [Check-in comment 6][Checkin 1.9.1 comment 7]
You need to log in before you can comment on or make changes to this bug.