Re: [whatwg] Accept header
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
something.
--
http://annevankesteren.nl/
Re: [whatwg] Accept header
On Thu, Jul 31, 2014 at 1:56 AM, Anne van Kesteren ann...@annevk.nl wrote:
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.
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
[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 img. 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/
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 img. 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:
img src=foo.png fetchoptions={whatever:{accept:'foo'}}
...or some nicer dedicated syntax:
img src=foo.png fetchoptions=accept: foo; whatever: bar
3. Have multiple dedicated attributes:
img src=foo.png accept=foo whatever=bar
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Accept header
On Wed, Jul 30, 2014 at 8:35 PM, Ian Hickson i...@hixie.ch 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/
