On Thu, Jul 23, 2015 at 6:32 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > I think this is a good idea in general, but I'm not sure how well the high > level fetch API would map to something internal.
1) fetch() is not exactly high-level. 2) We're not talking about fetch(), but about the fetch algorithm, which is reused by every single platform feature. > * Construct an nsIURI. Might need to take things such as the document base > URI and charset into account. For many APIs these days you need to parse the URL before you hand it off. That seems like a somewhat saner setup too, though in theory fetch() has access to this information through request's client. > There are some concepts here that do not exist in the current fetch spec > (for example, load groups) Load groups roughly matches the "fetch registry" I think. I should probably rename that "fetch group" as Ben suggested to me privately. Filed https://github.com/whatwg/fetch/issues/92 to do so. > Also, some of the existing concepts (such as streamed Responses) may > not be quite fleshed out yet. Well, they are specified. What is not specified there is the JavaScript API, but we figured out yesterday how to do it, so I expect we'll have everything updated somewhere next week. > I should also mention that in addition to the security concerns around fetch > interception through service workers, the above steps is *insanely* complex, > and almost every time that someone who is not deeply familiar with all of > the above steps tries to load something from the network, they're pretty > much guaranteed to forget something and as a result potentially open > security holes! I look forward to a future where mere mortals can load > stuff from the network in Gecko. :-) Yeah, my hope is that we'll eventually get some common abstractions that are safe-by-default and can be used by specifications to load resources without having to worry much about fiddling with all the settings. That still seems like a good bit of time away though. But who knows. -- https://annevankesteren.nl/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
