[webkit-dev] Client Hints

[Yoav Weiss]

+Ilya for spec related questions.

Also, I forgot to mention it, but my intention is to implement the RW and
DPR hints first, and see about the MD and RQ hints (which are newer to the
spec) later on.

On Thu, Apr 23, 2015 at 7:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> Additional spec concerns:
>
> (1) The RW header is unimplementable because image requests are sent
> before the display width of the image is known.
>

The intent is not to rely on actual display width for content images, but
to rely on HTML based info (mainly the sizes attribute), similar to srcset.
It might be better to clarify that in the spec.


> (2) The MD header is defined in a way that’s probably not useful to rely
> on; if I’m on 802.11g on a home WiFi network where the next hop is a cable
> modem, the nominal speed of 802.11g is not helpful for knowing how long it
> would take to load a large resource.
>

While the maximum downlink bandwidth does not provide the author with
accurate bandwidth information, it provides them a cap over the current
bandwidth. In other words, if that value is low, you can be certain that
the network is limited, but the contrary is not necessarily true.
While accurate bandwidth would have been better (both here and as part of
the NetInfo API), I don't think we have consensus on a decent way to expose
(heuristic) bandwidth measurements.


>
> (3) The MD header references a table of values in the W3C’s Network
> Information API spec, but that is a Working Group Note with no technical
> content and a warning that work has been discontinued because “while
> working on this specification the Device APIs Working Group encountered
> issues related to estimating network bandwidth and with providing useful
> information”. In other words, the WG concluded that there isn’t a sensible
> way to do what the MD header is trying to do.
>

The spec refers to the recent version of the Network Information API
<https://w3c.github.io/netinfo/#downlinkmax-attribute>, rather than the
outdated WG note.


> (4) The RQ header seems silly. It’s supposed to be a number 0-100, with
> fractional values allowed, that let the client specify it’s desired
> “resource quality”.  Why would you conceivably need this level of
> fine-grained selection? Will there really be a server with so many
> different versions of a resource that there’s a difference between quality
> 55.431 and 55.432? Furthermore, how is a client supposed to set this?
> Without knowing what the server will do or what value thresholds are
> important, is there anything useful WebKit could do other than always send
> 100?
>
>
I believe fractional values here are not intentional.

<snip>

>
> Is the Internet-Draft for this planned to become a standards-track RFC? Is
> there an IETF Working Group that has adopted it?
>
> Not sure. I'll let Ilya answer that.

>
> 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?
>
> For the legacy content use case: It's not about providing new higher
resolution images, but about adapting current images to smaller viewports,
and sending smaller images when the device doesn't need to full
desktop-sized image.

For the automated image conversion use case: The use case is about
optimizing the images at a separate layer, that's not necessarily HTML
aware.

>
> 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.
>
> I believe the intent with the short names was to minimize impact on the
network, since the headers will be sent with every sub-resource requests
once the server has opted-in. With that said, you're not the first to make
that comment, so I'm open to modify that, especially since HTTP/2 makes
this consideration irrelevant.

>
> 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.
>
> While true, this won't be the first header to extend that white list.
Looking at Document.cpp::processHttpEquiv I see that
x-dns-prefetch-control, x-frame-options and various variants of
Content-Security-Policy already have support for their meta equivalent.

- 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.
>
> True, but the preloadScanner can parse out these <meta> tags and add them
to its logic.

>
> Also, if a content author is able to add a <meta> header, that contradicts
> the use case assumption that
>
> True for legacy content, less so for automated image optimizers.
An example use case can be a site which HTML is hosted at a static location
(e.g. GitHub pages) while the images are served from an image-aware CDN.

>
> 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.
>
> Since the server has to opt-in to be sent with Client-Hints, it doesn't
suffer from ailments of previous content negotiation solutions.
The main criticism heard about past content negotiation attempts have been
that we have to keep sending these request headers even if no one uses
them. That won't be the case here.


> 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.
>
> Spec feedback is most welcome. The best place to send it is the GitHub
repo <https://github.com/igrigorik/http-client-hints/issues>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150423/b23387fb/attachment.html>