Re: [whatwg] Accept header
On Thu, Jul 31, 2014 at 1:56 AM, Anne van Kesteren wrote:
> On Wed, Jul 30, 2014 at 8:43 PM, Ben Maurer wrote:
> > On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson 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
Re: [whatwg] Accept header
On Wed, Jul 30, 2014 at 8:43 PM, Ben Maurer wrote:
> On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson 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
something.
--
http://annevankesteren.nl/
Re: [whatwg] Accept header
On Wed, Jul 30, 2014 at 8:35 PM, Ian Hickson wrote: > I would avoid adding the non-API sugar versions (content attributes, > especially the dedicated ones) for anything that didn't have significant > compelling use cases. Agreed. > Note that "Accept" _should_ probably be set by the UA for images, since > the author can't know what image types are supported. This was actually my main point phrased somewhat awkwardly I realize now. Specifications that define APIs that use Fetch need to invoke the fetch algorithm and say whether Accept / Accept-Language should be included. Perhaps even recommend values as XMLHttpRequest does. That means Fetch will expose those headers to service workers. That means if we add a "Fetch" object of sorts they can be manipulated. That also means Fetch will forbid UAs from setting them at the network-level, giving e.g. fetch() full control over them. -- http://annevankesteren.nl/
Re: [whatwg] Accept header
On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson wrote:
> On Wed, 30 Jul 2014, Anne van Kesteren wrote:
> >
> > it would be desirable to have Accept / Accept-Language be set by APIs,
> > such as . XMLHttpRequest already does this (unless a developer
> > added those headers), see http://xhr.spec.whatwg.org/
> >
> > If we are eventually going to expose something like a "Fetch" object for
> > each API that can issue a fetch it would seem best if these details were
> > defined at the API-level.
> >
> > I guess for now I'll add some notes to the network-level bits of Fetch
> > to indicate Accept / Accept-Language cannot be set at that point by the
> > user agent.
>
> There's three ways that I see:
>
> 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.
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.
Re: [whatwg] Accept header
On Wed, 30 Jul 2014, Anne van Kesteren wrote:
>
> it would be desirable to have Accept / Accept-Language be set by APIs,
> such as . XMLHttpRequest already does this (unless a developer
> added those headers), see http://xhr.spec.whatwg.org/
>
> If we are eventually going to expose something like a "Fetch" object for
> each API that can issue a fetch it would seem best if these details were
> defined at the API-level.
>
> I guess for now I'll add some notes to the network-level bits of Fetch
> to indicate Accept / Accept-Language cannot be set at that point by the
> user agent.
There's three ways that I see:
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');
2. Expose a dedicated attribute on relevant elements, that sets the
default fetch settings, either using some generic syntax:
...or some nicer dedicated syntax:
3. Have multiple dedicated attributes:
These are not mutually exclusive.
I would avoid adding the non-API sugar versions (content attributes,
especially the dedicated ones) for anything that didn't have significant
compelling use cases.
Note that "Accept" _should_ probably be set by the UA for images, since
the author can't know what image types are supported.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Accept header
The way service workers work is that only headers set at the API-level will be exposed to service workers. E.g. Host is not exposed as the network-level takes care of that (and you can simply use request.url for it). Per https://github.com/slightlyoff/ServiceWorker/issues/303 https://github.com/slightlyoff/ServiceWorker/issues/348 it would be desirable to have Accept / Accept-Language be set by APIs, such as . XMLHttpRequest already does this (unless a developer added those headers), see http://xhr.spec.whatwg.org/ Any idea how to best define this Ian? If we are eventually going to expose something like a "Fetch" object for each API that can issue a fetch it would seem best if these details were defined at the API-level. I guess for now I'll add some notes to the network-level bits of Fetch to indicate Accept / Accept-Language cannot be set at that point by the user agent. -- http://annevankesteren.nl/
