[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

The server can not rely on client side *anything* with resource
negotiation. This is because clients now pre-fetch resources; as soon as
the node exists the resource is requested - before any script has had a
chance to run or cookies have been set. It's a tripping point that Filament
Group have written about as well as myself.

I agree that headers are expensive. But are they expensive compared to a
few hundred kilobytes of saved bandwidth because we were able
to successfully negotiate content? That's the thing people keep seeming to
miss. Also, as indicated, with SPDY this is much much less of a problem
than for HTTP.

"More to the point I thin it is clear that developers want to know how to
adapt their content to the user's device"

Absolutely, which is what this is about. There are two use cases - one is
client side and one is server side. They seem to answer the same equation
but they do not. We need both, and we can't do *reliable* sever adaption
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. None are bullet-proof, and all are merely ways of attempting to
*Guess* what a browser header could explicitly tell us. Which is why
headers are wanted.

To be honest I think this is more a browser thing than  anything. I don't
see any problem with browsers behaving exactly as they do now, but
listening out for a server response header that in turn requests the
browser to append certain headers with all requests to the domain. I.e.,

1) client asks for spdy://website.com
2) server responds with content and adds a "request bandwidth & device
screen size header"
3) client then appends these headers to all future requests on the domain.
4) server can push any amended content from 2) over SPDY without another
request (because SPDY can).

This way there are no additional overheads unless the server has requested
them specifically.


-Matt

On 6 February 2012 15:38, Charles McCathieNevile <chaals at opera.com> wrote:

> On Mon, 06 Feb 2012 14:50:03 +0100, Matthew Wilcox
> <mail at matthewwilcox.com> wrote:
>
>  I've asked Bruce Lawson (one of the Opera boys) about this, and it's not
>> likely to happen with HTTP. However, SPDY compresses headers as well as
>> multiplexes, and it's a much more realistic request to get useful headers
>> sent over a SPDY connection than it is over HTTP.
>>
>> As for how useful it is - it's very very useful. Traditionally I don't
>> think the requirement to adapt content assets to device capability has
>> been
>> that important, because other methods were available (including the
>> god-awful mess of the UA string). That's going to be less and less useful
>> as the variety of devices continues to balloon and the UA string becomes
>> less and less sane.
>>
>> We need the server to know about the device. We need headers.
>>
>
> I'm pretty sensitive to Henri's argument that it's easy to add headers we
> think will be useful, when they really won't. They are still a pretty
> expensive part of the transaction, especially for mobiles.
>
> If you want them anyway, you might like to look at the Device Description
> Repository work W3C did, building on the lessons learned from doing CC/PP,
> UAProf, WURFL, because "the mobile web [had/was about to] reached the
> point where this capability was really important".
>
> More to the point I thin it is clear that developers want to know how to
> adapt their content to the user's device (rather than trying to adapt the
> user to buy the device they coded for which I think many people here would
> agree is a really bad thing to encourage).
>
> There is also the approach of knowing what capabilities you have from
> within the page itself. Again there is a long history of this, including
> media queries, the generally loathed hasFeature in DOM and the more common
> if (navigator.something) approach that is widely used instead, and so on.
>
> cheers
>
> Chaals
>
> --
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>      je parle français -- hablo español -- jeg kan litt norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
>