- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 28 Jul 2014 19:51:26 +0000 (UTC)
- To: Ben Maurer <ben.maurer@gmail.com>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, William Chan (³ÂÖDzý) <willchan@chromium.org>
On Mon, 28 Jul 2014, Ben Maurer wrote: > > The idea is you could specify any parameter to fetch. For example, if > fetch allowed you to specify an HTTP/2 priority, you could specify that. > > As a concrete example of why passing a header might be useful, Facebook > uses an automated pipeline to decide what CSS/JS files to package > together. If we could pass a custom header in the request for a CSS file > (for example: what part of the page caused that file to be loaded) we > could use this information in our packaging system to make smarter > decisions. While we do have the referrer header, a piece of interactive > javascript on a page might be the cause of the CSS file being required. > A custom header would allow logging this. Ah, I see. Makes sense. Are there any cases where you'd know the headers you want to send at the time the markup is written, before JS is involved, or would you always be updating the fetch settings from script? Would this ever apply to things that are downloaded with the initial load, or even in the preloader, or is this only for loads that are triggered by script later? We can definitely expose the fetch settings in markup, e.g. in the trivialest sense just by embedding a JSON blob in an attribute, or maybe in a more friendly dedicated microsyntax. I just want to make sure that that's the right thing to do before we go down that path -- meaning, that it has sufficient use cases to justify it, rather than require consumers to set these settings from script. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 28 July 2014 19:51:50 UTC