search

igrigorik / http-client-hints

401 stars 24 forks source link

RQ hint should have defined semantics #43

Closed yoavweiss closed 9 years ago

yoavweiss commented 9 years ago

The meaning of the communicated value is deferred to the server

That means that Firefox's "low" may mean something different than Chrome's "low" (or Firefox may not have "low", but "LQ", or "highly compressed"), which will force servers to keep track of a map of RQ values to their actual semantics.

Of course the server should control what "low" means in terms of its compression parameters, but it should know that "low" means "low".

In other words, I think we should figure out a small set of keywords and stick with them.

yoavweiss commented 9 years ago

Ping! /cc @mdwelsh @igrigorik I also think that we need similar semantics to a network hint (possibly replacing MD) that would indicate "practically offline but some packets are getting through", "bad", "OK", "Great connectivity". I'm hesitating if we should have these hints be merged into RQ and if they need to be a separate indication sent to the server. (e.g. The user wants HQ images but they're on a shitty network. Who's decision it is on what resource to send them? The browser or the content provider?)

igrigorik commented 9 years ago

That scenario is equivalent to very low MD value - i.e. some packets are getting through.

igrigorik commented 9 years ago

Closing. Superseded by Save-Data, see: https://github.com/igrigorik/http-client-hints/pull/55