Re: #428 Accept-Language ordering for identical qvalues

["Roy T. Fielding" <[e-mail]>]

On Feb 13, 2013, at 7:08 AM, Eric J. Bowman wrote:

> "Roy T. Fielding" wrote:
>> 
>> Regarding proactive negotiation in HTTP/2, I'll note that Waka
>> strips all negotiation fields.  I find the entire feature revolting,
>> from every architectural perspective, and would take the opportunity
>> of 2.x to remove it entirely.
>> 
> 
> That's a bold statement!  I'm surprised at the source --  I was under
> the impression that the late binding of representation to resource was
> a key feature of REST, and would therefore also be part of Waka?

That doesn't require proactive negotiation. Late binding is an
aspect of the server choosing what to send at the time a request
is received, not an indication that it needs the user agent's poorly
configured Accept* headers to make that choice.

It is a bad design trade-off to send a bunch of header fields on every
request just to tell the server all of the possible variations of
preference held by the user, particularly when there is a very small
chance that any of those dimensions are applicable to the target resource.
It has been a bad design trade-off ever since the very brief period
in 1993-94 when folks didn't know which image format would be
usable on all UAs and there was no CSS or javascript to allow
for client-side adaptation.

There are numerous ways to accomplish the same feature of HTTP
content negotiation without the horrific bandwidth waste and
privacy exposure of proactive negotiation. The caching impact of
proactive negotiation is far worse than the one extra round trip
per site for reactive negotiation, and even that round-trip isn't
necessary in formats that support client-side adaptation.
Defining protocol elements for reactive negotiation is one alternative.
Encouraging the use of media types with inherent content
selection/alternative abilities is another.
Responsive design (or progressive refinement) is probably the most
common example in practice today.

And there is no question that Content-Encoding should have been
replaced by transfer encodings long ago.  These are jumps in
progress that should be made when developers are deploying a
new protocol.

> This
> isn't the place for such a discussion, but I was hoping you'd enlighten
> us as to your thinking, either on your blog or here:
> 
> http://tech.groups.yahoo.com/group/rest-discuss/message/19269
> 
> What is on-topic here, is whether eliminating conneg in HTTP 2 amounts
> to a fundamental change to Web architecture, which exceeds the WG
> charter?

Proactive conneg is an optional feature of HTTP.

....Roy