W3C home > Mailing lists > Public > public-webapps-github@w3.org > September 2017

Re: [w3ctag/design-reviews] Request for review: Preload (#202)

From: Yoav Weiss <notifications@github.com>
Date: Thu, 28 Sep 2017 09:38:33 +0000 (UTC)
To: w3ctag/design-reviews <design-reviews@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <w3ctag/design-reviews/issues/202/332783920@github.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:36:15 UTC