A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Fetch: Difference between revisions
Jump to navigation
Jump to search
(→Request: merge CORS in) |
(→Fetch: cleanup) |
||
| Line 34: | Line 34: | ||
Have a case-switch on URL scheme. See also [[URL]]. Fetch results in a network error response unless the scheme is one of | Have a case-switch on URL scheme. See also [[URL]]. Fetch results in a network error response unless the scheme is one of | ||
* http | * http / https | ||
* | ** CORS only has an effect here. | ||
** Might result in nested Request -> Fetch -> Response chains due to redirects and CORS. | |||
* ftp | * ftp | ||
** This is legacy, but still works. | |||
* file | * file | ||
** This is by and large platform-specific. | |||
* about | * about | ||
** See [[URL schemes]]. | |||
* data | * data | ||
** Response object as per http://xhr.spec.whatwg.org/#data:-urls-and-http except that failing to parse needs to be added. | |||
* blob | * blob | ||
** http://dev.w3.org/2006/webapi/FileAPI/#processingModel | |||
=== Response === | === Response === | ||
Revision as of 15:44, 11 February 2013
Fetch is fetch.spec.whatwg.org and will define HTML fetch and CORS as a set of coherent algorithms rather than the intertwined mess we have now. It will also deal with the following:
- 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
Model
The basic model is Request -> Fetch -> Response.
Request
- 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; I should know...))
- synchronous flag
- force same-origin flag
- 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>)
- Anonymous
- Credentialed
Fetch
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.
- ftp
- This is legacy, but still works.
- file
- This is by and large platform-specific.
- about
- See URL schemes.
- data
- Response object as per http://xhr.spec.whatwg.org/#data:-urls-and-http except that failing to parse needs to be added.
- blob
Response
Both intermediate updates (progress, headers received, ...) and final. Also indicates network error / CORS error (exposed as network error), ...