XHR request fail if you have manifest with fallback only to subfolder
Reported by
nasc...@gmail.com,
May 20 2016
|
|||||||||||||||||
Issue description
Chrome Version : 51.0.2704.47 dev-m (64 bits)
URLs (if applicable) :
Other browsers tested:
Safari:
Firefox: OK
IE:
What steps will reproduce the problem?
(1) Create a HTML 5 manifest with fallback only for sub-folder in your website
CACHE MANIFEST
FALLBACK:
/Field/ /Field/offline.html
NETWORK:
(2) Create a XHR request from a page inside your subfolder with fallback url. We test with jquery and send get request to a page that returns json.
(3)
What is the expected result?
The XHR request receive response
What happens instead?
The XHR request fail.
Workarround: If you add a fallback for the root everything works as expected.
working example:
CACHE MANIFEST
FALLBACK:
/ /Home/PageNotFound
/Field/ /Field/offline.html
NETWORK:
,
Jun 10 2016
I'm able to replicate this only in ASP.NET project with WebAPI. See attached.
,
Jun 11 2016
Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 14 2016
@nascovt: Could you please provide us the screen-recording to repro this issue, which would help us in triaging it further. Since, there are many files in the attached .ZIP file. Thank you.
,
Jul 7 2016
,
Jul 12 2016
You can see how I recreate the issue in the video from the attachment. You can also download Visual Studio from https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx and replicate the issue by yourself. You can find the sample project, which I'm using in the video in my comment from June 10.
,
Jul 12 2016
Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 18 2016
@MTV: Team, could you please look into this issue, as this requires Visual Studio. Thank you.
,
Jul 28 2016
So far as I can tell, the repro reduces down to the following: If the manifest has: CACHE MANIFEST FALLBACK: / /fallback ... then an xhr/fetch of '/data' (a real resource) succeeds. If the manifest has: CACHE MANIFEST FALLBACK: #/ /fallback ... then an xhr/fetch of '/data' (again, a real resource) will fail. Attached.
,
Jul 28 2016
Behavior is the same in Firefox. Is this just a subtlety in the appcache behavior?
,
Jul 28 2016
Hrm, I'm not seeing it in the spec. It's as if the presence of a '/' FALLBACK entry sets the 'online safelist wildcard flag' to true.
,
Jul 28 2016
,
Jul 28 2016
Ah, found it. This is working as intended for fallback namespaces. The manifests described here alter whether or not / is a fallback namespace. https://html.spec.whatwg.org/multipage/browsers.html#changesToNetworkingModel Following the steps for '/data' 1. Keeps going (it's a GET, etc) 2. Keeps going (not in any of those lists) 3. Keeps going (there is no online safelist) 4a. If the manifest has / as a fallback: * Fetch the resource normally. There's no redirect or 4xx/5xx error, so cache is not used. Steps terminate. 4b. If the manifest does not have / as a fallback - does not apply. 5. Keeps going (online safelist wildcard flag is 'blocked') 6. Fail. So with / in FALLBACK, 4a happens. With / not in FALLBACK, 4b happens. The bit in the original bug report about subfolders is irrelevant; only the URL to be fetched matters, not the URL of the page doing the fetching. From watching the video, the resource fetches are against URLs starting with /WebApi/GetData.
,
Jul 29 2016
If firefox does the same thing, than it probably is one of those things the appcache is famous for. Hmmm, the 60MB repro is a bit much but i think the video is helpful. |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by rnimmagadda@chromium.org
, May 23 2016Labels: Needs-Feedback