Anyone who’s done even a minimal web design task realizes how useful it is to know the capabilities of the client receiving the content. Chief amongst these is the User-Agent, which identifies the basic properties of the client’s web browsing environment: the web browser family and version, the layout engine, and the operating system. This is important for the server to serve content that is adequate to that particular client.
There is another set of information that is very handy for ensuring optimal web page rendering, which is the display capabilities. Information such as the screen size and resolution is used by many websites to customize page layout (design and stylesheets) and content (images, buttons, etc.). This is increasingly relevant considering the following:
- The proliferation of HTTP-enabled devices (mobiles, tablets, phablets, etc.) and their extremely varied display capabilities;
- The never-ending race to improve the display of these devices as well as that of “traditional” web-enabled devices (i.e. desktops and laptops); and
- The variance in HTTP-shipped multimedia (e.g. DASH).
To do this server-side is to save a round-trip. But previous attempts included a number of non-standard variants (UA-pixels, X-UP-devcap-screenpixels, X-Device-User-Agent, etc.) which cannot be relied upon. The alternative is to look at the User-Agent and Accept fields and try to guestimate the best screen size. This is obviously not very efficient but is surprisingly common.
Relinquishing one round trip is what most responsive web designers do. Either the server replies with a 300 Alternates list [RFC2295], and/or the web site employs client-side script to report client capabilities. This incurs additional traffic and an additional round trip, something especially expensive in mobile settings.
Solving this issue is not difficult. All it would take is for the user agent (i.e. browser) to provide some information about its display in a standard HTTP header. Such header information would have to be optional to avoid unnecessary overhead in cases where the user agent does not wish for the response to be optimized for it, as in the case of web services. Also, this header should refrain from giving away too much information that could compromise security or privacy (as is proposed by Device-Stock-UA which gives away detailed information about the user agent version). This is more pertinent if the next generation of HTTP is to have a Server Push feature like Google SPDY: It makes sense for the server to push content that it anticipates the client would need, but the purpose is defied if the server has to wait for more information from the client after its initial request.
Nevertheless, such proactive negotiation of client display capabilities is not naturally supported by HTTP/1.1 despite the issue being raised a long time ago. Others are also trying to solve this, albeit at a different level.
I was thus quite please to learn this week about Ilya Grigorik’s proposal dubbed Client Hints [draft, slides] which is very much along the lines of what is described above. Client Hints also has measures to avoid negative implications on caching efficiency caused by inability to reuse HTTP responses.
Update: Client Hints are now being implemented in Chrome.
I think it is high time this issue is discussed as the IETF Hypertext Transfer Protocol Bis working group are actively engaged in discussion to draft HTTP/2.0 (follow progress here). I guess pivotal to this discussion is whether HTTP should be concerned with solving this issue at all, and this is probably something the community would be divided upon. There already are concerns of HTTP/2.0 being too browser-centric. My personal opinion is that this is a session and presentation issue and hence falls within the domain of HTTP.