A proposal to browser vendors; reliable feature detection via SPDY
Firefox and Chrome both now support SPDY, the new and far more capable replacement for HTTP. This is awesome news 
So, with Firefox and Chrome now supporting the SPDY protocol, can we revive the idea of browsers sending reliable and accurate device capability headers to the server, without the latency penalty HTTP inflicted on us?
I’ve now asked both Mozilla and Opera representatives, as well as the WHAT-WG to considered that SPDY now makes it much more realistic to send useful headers to the server to indicate device capabilities. Due to compression and multiplexing there is far less overhead in doing this than with HTTP, and it would be extremely useful:
I agree that headers are still ‘expensive’. But are they expensive compared to a few hundred kilobytes of saved bandwidth because we were able to successfully negotiate content?
We can’t do reliable sever adaption of content without reliable client feature-set reporting. Which we can’t get any way we try right now, and there are many approaches tried - JS, cookies, and UA sniffing for example. None are bullet-proof, and all are merely ways of attempting to guess what a browser header could explicitly tell us.
To shave off any ‘wastage’ I would love to see browsers behaving something like this: exactly as now, but listen out for a server response header that in turn requests the browser to append server-specified device capability headers with all requests to the domain. i.e.,
- Client asks for spdy://website.com
- Server responds with content and adds a “request [bandwidth] & [device screen size] headers”
- Client then appends these headers to all future requests on the domain.
- Server can push any amended content from 2) over SPDY without another request (because SPDY can).
This way there are no additional overheads in general browsing unless the server has requested them specifically. And with SPDY they’re all compressed anyway.
At last, reliable feature detection the server can get hold of?
NOTE: server negotiation is only one half of the required adaptation of content for different devices. We also need a HTML based solution. Why? Because the server version is all about supplying rescaled version of the same resource. The mark-up version is about sending different resources in response to device capabilities. For example: An About page with user profiles. High resolution devices get full body-length photo’s of people, smaller devices get head-shots instead. Because the semantic content is a recognisable image of the person. Simple re-scaling wouldn’t work in this example. Hence the need for a different resource that does the same semantic job. I have suggested this mark-up requirement to the WHAT-WG too, but the thread seems to have died.
Entry Information
- Posted:
- Mon, 6th Feb 2012 at 16:02 UTC
- Filed under:
- Tags: