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 IRC (such as one of these permanent autoconfirmed members).

Difference between revisions of "Fetch"

From WHATWG Wiki
Jump to: navigation, search
(Fetch: expand a bit on Fetch)
(Plan)
Line 2: Line 2:
 
== Plan ==
 
== Plan ==
  
Fetch is [http://fetch.spec.whatwg.org/ fetch.spec.whatwg.org] and will define [http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch 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:
+
Fetch is [http://fetch.spec.whatwg.org/ fetch.spec.whatwg.org] and will define [http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch HTML fetch] and CORS as a set of coherent algorithms rather than the intertwined mess we have now.
 
 
* 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 ==
 
== Model ==

Revision as of 15:51, 21 February 2013

The contents of this page, Fetch, and all edits made to this page in its history, are hereby released under the CC0 Public Domain Dedication, as described in WHATWG Wiki:Copyrights.

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.

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 specifics depends on the URL scheme. Where possible fetching happens incrementally. If it completely fails you get a network error. Otherwise a response. A response might be exposed from the moment status/headers are available and the entity body is still loading.

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

If the data URL fails to parse however return a network error.

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.

any other scheme

Network error.

Fetch

Basic Fetch deals with a single request/response whereas Fetch tackles the more complicated setups required by http/https:

  • Redirects
    • We want to follow them if the status code is 301, 302, 303, 307, 308 and there's a Location header (and if there's more than one Location header we need to pick probably), unless a flag is set to not follow redirects).
    • We need to carefully consider what happens if the new Location is not same-origin and especially what if it's not http or https. That might depend on the API.
  • Authentication (challenge request, prompt the user for certain legacy APIs)
  • CORS (preflight requests, marking the response as same-origin or not)

For everything else Fetch will simply defer to Basic Fetch, but Fetch will be the algorithm used by the whole platform.

Response

Both intermediate updates (progress, headers received, ...) and final. Also indicates network error / CORS error (exposed as network error), ...

More importantly, it expresses everything in terms of HTTP, regardless of whether the request was for file/blob/data/etc. For this we need to expose:

  • Status code
  • Status text
  • Headers
  • Entity body

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).