I think you both are talking about different things. What @igrigorik is saying is that when preload is used as a browser signal, the browser will send the appropriate `Accept` headers based on the `as` value. (so `as=image` will send out e.g `Accept: image/webp,image/*,*/*;q=0.8` in Chromium) IIUC, @triblondon is talking about using preload as a push signal, and lack of content-negotiation in that case. That's not a problem with preload, as no markup or server side mechanism could have helped here). HTTP/2 push cannot perform content negotiation, as by definition the client does not take part in the generation of the request. That's one of the [advantages](https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#doesnt-http2-push-cover-those-same-use-cases) of preload over push. Maybe we can add that as a note saying that when a server plans to use content negotiation to serve a resource, it should not attempt to push it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/202#issuecomment-332783920
Received on Thursday, 28 September 2017 09:38:55 UTC