This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It would be great if each API that fetches exposes its Request object for further manipulation. Something along these lines: let img = new Image() img.request.headers.append(...) What we need to figure out is how scenarios such as img.request... img.crossOrigin = "" would work. Perhaps accessing the underlying Request object should go through a method that locks certain bits, such as request's mode, in place. See e.g. http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0219.html for more context.
My thinking on this (based on our IRC discussion): - When the browser triggers a "fetch" for something on an element, it passes in both the URL (from src='') and the request init options (from src-settings='' or some such) and any additional legacy stuff (like crossorigin=''). This creates a Request object and immediately calls fetch() on it. - The src-options='' or whatever is a JSON string that is parsed into a RequestInit object. - Once the Request object is ongoing, it's made immutable, and is accessible from the element's .request IDL attribute. - That object lets you change stuff HTTP2 lets you change, whatever that is. If you change src='' or crossorigin='', a new request is made. If HTTP2 or ServiceWorkers needs any dependency tree information, let me know. I can probably provide that once I have the ES6 module integration specced out. (cc'ing simonp, since for <img> in particular this will be all kinds of messy)
(In reply to Ian 'Hixie' Hickson from comment #1) > My thinking on this (based on our IRC discussion): > > - When the browser triggers a "fetch" for something on an element, it > passes in > both the URL (from src='') and the request init options (from > src-settings='' or > some such) and any additional legacy stuff (like crossorigin=''). This > creates a > Request object and immediately calls fetch() on it. Would we also need a href-settings for <link> and others? Or, can we agree on a common attribute name to pass these settings for all elements? fetch-settings perhaps?
Messy because with <img> there's multiple requests in-flight at once. (It's going to be even worse when you see what I have in mind for .loaded and .ready promises...) Yes, one attribute would be better. I was intentionally just making up a new name each time I mentioned it so as to encourage bikeshedding. :-)
Do you want .request to return a new Request object at the top of "update the image data"? (This runs when the element is created plus "relevant mutations".) The "update the image data" algorithm doesn't always end up doing a new fetch. If there is no candidate it doesn't fetch anything. If the image is in "list of available images" it doesn't fetch anything. If an img element has a fetch in flight and the image has known dimensions, then the script sets src="" to a new value, it will start a new fetch in parallel without aborting the old one until the new one has been fully loaded. When the new one is fully loaded it replaces the old image and the old request gets aborted (if still active). If the old request finished before the new image you get a load event for that one and later another load event for the new image (IIRC). How should this work with .request? What should happen when the environment changes? https://html.spec.whatwg.org/multipage/embedded-content.html#img-environment-changes This fetches an image in the background without giving JS any notice until the new image is fully loaded (if it fails nothing happens). Do you want settings thing to be per URL? (crossorigin="" is per <img>.) Should I set any extra information along with the Request, like the candidate's density?
If <img> does at most two fetches it might make sense to expose two properties. When exactly we expose request I'm not sure about. Ideally synchronous so we do not make any timing attacks easier. > Should I set any extra information along with the Request, like the > candidate's density? I think there's a proposal for a header of sorts that you would have to append, yes. That seems like something to track separately though.
The referrer policy spec (https://w3c.github.io/webappsec/specs/referrer-policy/) is currently considering a proposal (https://github.com/w3c/webappsec/pull/175) in which many of the elements that trigger fetches would be able to control the contents of the Referer request header. Anne pointed out that the mechanism described in this bug might be a better fit long-term.
Closing this since it never really got off the ground. It's probably too complicated to make work. If anyone comes up with a good processing model for how to do this, please don't hesitate to propose it here: https://github.com/whatwg/fetch/issues/new. (We'll also need implementer interest.)