- Deal with authentication (URLs containing username/password, servers responding with 401)
- Deal with URL processing
- Define HTTP context for data: URLs, about:blank, and file: URLs.
- Progress Events
The basic model is Request -> Fetch -> Response.
- Parsed URL (object)
- method (probably with restrictions as seen in XHR)
- UA headers
- author headers (maybe rename because people get upset with "author", with implicit restrictions as seen in XHR / CORS)
- entity body
- origin (object)
- referrer source (Document / URL)
- manual redirect flag
- omit credentials flag (will replace HTML fetch block cookies flag but also has other features)
- force preflight flag (set for upload progress notifications (to not reveal existence of server in case of POST I suppose; see bug 20322))
- synchronous flag
- force same-origin flag (looks identical to No CORS, fail, filed bug 20951
- CORS mode
- No CORS, taint (<link>, <script>, ...); still need to allow the server to opt in to CORS anyway to effectively make the resource CORS same-origin even if not requested as such (HTML does not have this feature
- No CORS, fail (<track>)
Have a case-switch on URL scheme. See also URL. Fetch results in a network error response unless the scheme is one of
- http / https
- CORS only has an effect here.
- Might result in nested Request -> Fetch -> Response chains due to redirects and CORS.
- This is legacy, but still works.
- This is by and large platform-specific.
- See URL schemes.
- Response object as per http://xhr.spec.whatwg.org/#data:-urls-and-http except that failing to parse needs to be added.
Both intermediate updates (progress, headers received, ...) and final. Also indicates network error / CORS error (exposed as network error), ...