search

igrigorik / http-client-hints

402 stars 24 forks source link

viewport-based selection use case and caching #59

Closed waldbaerkoch closed 9 years ago

waldbaerkoch commented 9 years ago

Given the following example:

<img srcset="wolf-480.jpg 480w, ..., wolf-1920.jpg 1920w" sizes="...">

The same wolf-1920.jpg would be selected e.g. for

A cache could respond with the same cache entry for all these requests.

If the HTML is reduced to

<img src="wolf.jpg" sizes="100vw">

the same image would be selected or created for requests with client hint headers

The server responds with

Vary: DPR, Width

But although it's the same image, a cache would have to create separate cache entries because the DPR and Width header values differ. If the client sent a client hint with the needed instrinsic width (e.g. Instrinsic-Width: 1920) (the client has to calculate it in the srcset-w case anyway to compare it to the w descriptors), the server would respond with

Vary: Instrinsic-Width

A cache could respond to all the requests above with the same entry.

waldbaerkoch commented 9 years ago

An alternative could be a way to use a Key header (http://mnot.github.io/I-D/http-key/draft-fielding-http-key-03.html) with the partition parameter based on the product of two header values, like

Key: DPR*Width;partition=480:...:1920

which is not (yet :-) defined.

igrigorik commented 9 years ago

Hmm, that's a good suggestion - thanks. It does seem that reporting the intrinsic width would ease the implementation on the server: reduces fragmentation with Vary and does not require any acrobatics for Key. We'd still want to report DPR though.

@yoavweiss any thoughts on this one?

yoavweiss commented 9 years ago

I agree that in most cases, you'd want your server to respond to DPR+Width, which means redundant variance, and will be hard to cache.

Replacing Width with a Width*DPR value would provide the server side the same information that it can receive today, while reducing the variance of the major use-case.

I don't like Intrinsic-Width as that value's name, since in the browser we're using that to mean Width rather than Width*DPR (The incoming resource's intrinsic width is being corrected as a function of its srcset descriptor or the Content-DPR header).

Maybe Physical-Width? (`Resource-Width' might have been a good fit as well, but our past use of it may cause confusion...)

igrigorik commented 9 years ago

@yoavweiss as a slightly more radical version: what about changing current definition of Width? Granted, M46 is starting its rollout now, but I don't think it's too late... if we act fast? :)

In terms of history: we specced CSS px values because we were using Width to describe both the resource and viewport width's. However, now that we've split those cases into separate headers, I think we can revisit that.

yoavweiss commented 9 years ago

Yeah, we can try to get a semantics change in before M46 hits stable. Usage is still at 0