- From: Ben Maurer <ben.maurer@gmail.com>
- Date: Thu, 31 Jul 2014 10:44:31 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Thu, Jul 31, 2014 at 1:56 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Jul 30, 2014 at 8:43 PM, Ben Maurer <ben.maurer@gmail.com> wrote: > > On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson <ian@hixie.ch> wrote: > >> 1. Expose it on a "fetch" object available from all the places that can > >> do fetches. (HTMLImageElement, XMLHttpRequest, StyleSheet, etc) > >> > >> var img = new Image(); > >> img.src = 'foo.png'; > >> img.fetch.doWhateverWithTheAcceptHeader('foo'); > > > > At what point is the fetch actually being initiated? It's possible that > > fetch will offer some things which can be done post-request (eg, > dynamically > > changing the spdy priority), but the accept header may need to be > specified > > pre-request. > > Probably not before the end of the current task. The only exception to > that is EventSource and maybe WebSocket, but they can have a > constructor argument of sorts to make this work I guess. > > Otherwise you could not set attributes such as crossorigin either. > Ah, cool. If it's not already defined, it'd be great to have a clear definition of this behavior. I could imagine it being useful for a site to explicitly initiate the sending of the request (eg, if it was aware an expensive JS function was about to execute). I appreciate your guys' help in thinking out this use case. -b
Received on Thursday, 31 July 2014 17:44:58 UTC