- From: Ben Maurer <ben.maurer@gmail.com>
- Date: Tue, 22 Jul 2014 12:39:20 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
I'm pretty new to this spec overall, so please tell me if I'm totally off track here -- the fetch spec states that it's goal is "To unify fetching across the web platform" by providing "consistent handling" of things such as CSP or priorities. It seems like the ultimate goal here is that the specification for something like script loading should be able to be explained in the terminology of Fetch. A corollary of this seems to be that a user should be able to simulate the behavior of a fetch initiated by the browser upon seeing a script or stylesheet. This could mean passing custom parameters to the fetch api (eg, asking for a specific priority or asking for CSP to be applied to the element). I understand that these things aren't there today -- and any site using a fetch based system might face the same poor interactions as an XHR based system would today. But in the long term, wouldn't the goal be to have parity between the parameters a user can pass to the fetch api and the parameters the browser passes internally to the fetch API? If the fetch api offers the same set of functionality available to the browser internally, users could experiment with different types of dependency management APIs. On Tue, Jul 22, 2014 at 12:13 PM, William Chan (陈智昌) <willchan@chromium.org> wrote: > On Tue, Jul 22, 2014 at 12:03 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > >> On 7/22/14, 2:57 PM, Ben Maurer wrote: >> >>> Nothing prevents a website from downloading content via fetch/XHR and >>> simply inserting that text into the DOM. >>> >> >> Yes, I know that. But we're trying to develop a better API so sites >> won't need/want to do that anymore, right? All I'm saying is that we >> should make the new API play nicer with CSP and extensions than the "XHR >> and stick it in" approach does. This won't stop _malicious_ sites, >> obviously, but it'll help with user control for normal sites who actually >> want to play nice with the user's settings. > > > +1 > > Also, I'd like to note that, at least for now without a better > prioritization system (I know you'd like to do client<=>server prior > knowledge based prioritization mechanism, smuggling prioritization metadata > via opaque-to-the-UA HTTP headers, using the headers attribute), browsers > rely on resource type as a key input to their prioritization heuristics. > Gmail and G+ both found that this interacted poorly with their XHR based > resource loading [1] [2] since XHRs hide the true resource type. > > >> >> >> This API seems strictly >>> better than a site that fetches text and just inserts it into the DOM. >>> >> >> Sure. >> >> >> Also, it seems like CSP or extensions could still hook into this API, >>> maybe not as early as before. For example, CSP would still know the URL >>> of the resource that had been loaded as a script / stylesheet. While it >>> wouldn't be able to block the loading, it could block the document from >>> being turned into a script or stylesheet element. >>> >> >> Again, sure. >> >> >> One could also imagine a flag passed to fetch saying "fetch this >>> document as if it were the src of a script tag". >>> >> >> Right, exactly. >> >> That would actually simplify things for UAs as well; for example they >> have to do different kinds of sniffing on different request types, so >> knowing ahead of time what sort of thing you're requesting is quite helpful. >> >> -Boris >> > > [1] - https://insouciant.org/tech/spdy-prioritization-case-study-gmail/ > [2] - https://plus.google.com/+ShubhiePanicker/posts/Uw87yxQFCfY >
Received on Tuesday, 22 July 2014 19:39:45 UTC