On Wed, Jul 30, 2014 at 8:43 PM, Ben Maurer <ben.mau...@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson <i...@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.

>> Note that "Accept" _should_ probably be set by the UA for images, since
>> the author can't know what image types are supported.
> It's possible a site could want to *remove* headers. For example, maybe a
> site wants to A/B test the performance of using webp. I don't think this is
> an important use case -- there are many other ways a site could accomplish
> this task.

Yeah, the way I'm thinking about this now is that we probably want to
expose the Request object from the Fetch Standard. It will have the
headers set at the API-level such as Accept, and allow for
manipulation of those, and have the ability to add new headers,
depending on the mode.

It's not quite as straightforward as that as the capabilities greatly
depend on whether you use CORS or not, but we can probably think of


Reply via email to