I like how fetch is a small primitive right now. We should not overload it with 
more functionality, but instead create new APIs on top of it. It's important to 
be able to polyfill those APIs on top of fetch, instead of adding more stuff to 
the base substrate of fetch itself.
From: Ben Maurer<mailto:ben.mau...@gmail.com>
Sent: ‎2014-‎07-‎22 19:07
To: William Chan (陈智昌)<mailto:willc...@chromium.org>
Cc: whatwg@lists.whatwg.org<mailto:whatwg@lists.whatwg.org>; Boris 
Subject: Re: [whatwg] Fetch Objects and scripts/stylesheets

To follow this up with a concrete suggestion:

var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
myfetch.then(function(resp) {

You can only call asStyleShet if fetch-as=stylesheet. Passing this
parameter would cause the browser to do all the things it would do if it
were fetching a stylesheet. For example, it would specify an accept header
of text/css unless otherwise specified. It would request at the same
priority as the browser requests other stylesheets (again, unless
overridden with a yet-to-be-defined syntax). Rules around CORS and tainting
would be identical to a normal stylesheet fetch (namely that you could
call.asStyleSheet on a request to a different origin but it would have
whatever restrictions the browser has on stylesheets from different
origins). Links in the stylesheet would be interpreted relative to the URL
used to load it, etc.

Essentially, fetch-as=stylesheet would be the canonical definition of the
browser's behavior around loading stylesheets. It would define the behavior
if the proposals I suggested in the original email were implemented --
namely if the user chose to pass parameters to the fetch algorithm or if
the user accessed the result of a stylesheet's fetch.

Boris, Will -- would this setup address the concerns you have about the
problems websites that use XHR to load resources encounter?

On Tue, Jul 22, 2014 at 12:39 PM, Ben Maurer <ben.mau...@gmail.com> wrote:

> 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 (陈智昌) <
> willc...@chromium.org> wrote:
>> On Tue, Jul 22, 2014 at 12:03 PM, Boris Zbarsky <bzbar...@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

Reply via email to