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
No edit summary |
(→Fetch) |
||
Line 31: | Line 31: | ||
** Anonymous | ** Anonymous | ||
** Credentialed | ** Credentialed | ||
=== Basic Fetch === | |||
See also [[URL]]. Fetch depends on the URL scheme. Unless it is a scheme listed below the response is a network error. | |||
==== about ==== | |||
See [[URL schemes]]. | |||
==== blob ==== | |||
http://dev.w3.org/2006/webapi/FileAPI/#processingModel | |||
==== data ==== | |||
Response object as per http://xhr.spec.whatwg.org/#data:-urls-and-http except that failing to parse needs to be added. | |||
==== file ==== | |||
This is by and large platform-specific. | |||
==== ftp ==== | |||
Construct the request per the FTP specification, do the request, and expose the response. | |||
==== http and https ==== | |||
Construct the request per the HTTP specification, do the request, and expose the response. | |||
=== Fetch === | === Fetch === | ||
Fetch defers to Basic Fetch except for http and https. It has the ability to handle redirects automatically (and somehow hide this redirecting happening from the caller). And deals with more complicated preflight requests if CORS is opted into and if CORS is not opted into it still examines the response to see if it can be marked CORS same-origin after all. | |||
So basically Basic Fetch deals with a single request/response whereas Fetch tackles the more complicated setups required by most platform APIs. | |||
=== Response === | === Response === |
Revision as of 15:37, 20 February 2013
Plan
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; 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>)
- Anonymous
- Credentialed
Basic Fetch
See also URL. Fetch depends on the URL scheme. Unless it is a scheme listed below the response is a network error.
about
See URL schemes.
blob
http://dev.w3.org/2006/webapi/FileAPI/#processingModel
data
Response object as per http://xhr.spec.whatwg.org/#data:-urls-and-http except that failing to parse needs to be added.
file
This is by and large platform-specific.
ftp
Construct the request per the FTP specification, do the request, and expose the response.
http and https
Construct the request per the HTTP specification, do the request, and expose the response.
Fetch
Fetch defers to Basic Fetch except for http and https. It has the ability to handle redirects automatically (and somehow hide this redirecting happening from the caller). And deals with more complicated preflight requests if CORS is opted into and if CORS is not opted into it still examines the response to see if it can be marked CORS same-origin after all.
So basically Basic Fetch deals with a single request/response whereas Fetch tackles the more complicated setups required by most platform APIs.
Response
Both intermediate updates (progress, headers received, ...) and final. Also indicates network error / CORS error (exposed as network error), ...
Notes
Algorithm: "fetch"
- Sets up the request. Methods, headers, etc.
- Then branches based on specifics.
Actually fetching: "do the fetch"
- Should probably branch on URL scheme first.
- Gets the data.
- Needs to queue tasks unless suppressed (sync / CORS prefetch)
- Needs to be able to automatically follow redirects (http/https only).