[webkit-dev] Client Hints

Maciej Stachowiak mjs at apple.com
Thu Apr 23 09:46:17 PDT 2015

> On Apr 23, 2015, at 12:48 AM, Yoav Weiss <yoav at yoav.ws> wrote:
> Hi,
> As I've discussed during my session at the contributor's meetup, I'm interested in implementing Client-Hints <http://igrigorik.github.io/http-client-hints/> in WebKit.
> For those unfamiliar with it, Client-Hints is a standard destined to improve content negotiation, and enable the browser to advertise various characteristics to the server along with resource requests, so that the server can adapt its responses to these characteristics in a cache friendly way.
> It was conceived to enable and facilitate server-side based responsive images solutions. The main use-cases for that are automatic optimization of legacy Web content, where it's not always easy to go back and modify the HTML, as well as external image optimization solutions that prefer content negotiation over HTML modification.
> I'd like to emphasize that this effort is orthogonal to the <picture> effort. (and the use-cases covered by each are orthogonal as well)
> Since I intend to go ahead with implementation soon, I wanted to share my intentions with the wider WebKit community and gather feedback at this early stage.

Is the Internet-Draft for this planned to become a standards-track RFC? Is there an IETF Working Group that has adopted it?

On the use cases: is there really anyone who is able to provide new higher resolution versions of their images, but cannot modify the HTML that references them?

On the spec contents: I’m wary of the fact that the header names are very opaque. That’s not in the HTTP tradition, where header names are generally human-readable. I am skeptical that the HTTP WG would be satisfied with these header names as-is.

The <meta> requirement is problematic for two reasons:
- Most <meta http-equiv> values are not processed as the equivalent http header. HTML5 limits it to a whitelist. It doesn’t seem like a good idea to extend this legacy facility.
- Browser engines may issue image requests before actually parsing the document (e.g. WebKit’s preloading feature) so it doesn’t seem safe to rely on <meta> being processed before image requests are sent.

Also, if a content author is able to add a <meta> header, that contradicts the use case assumption that 

Finally, content negotiation has mostly been a giant failure on the Web, so I’m not sure why we would want to expand it. Is there a reason to believe this spec will be less of a failure than existing content negotiation.

I know spec feedback may be off-topic for an implementation thread, but I’m not sure where else to send it since it’s not clear if this Internet-Draft is associated with a working group.

These issues make me wonder if the spec is really mature enough to implement.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150423/755d09ee/attachment.html>

More information about the webkit-dev mailing list