Subject: Re: #428 Accept-Language ordering for identical qvalues

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 13 Feb 2013 08:08:45 -0700

"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?  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?

-Eric

---

From: James M Snell <[email-masked]>
Date: Wed, 13 Feb 2013 07:59:02 -0800

Well, considering that the http/2 discussion has already touched on
the introduction of stateful compression, a potential switch to
binary-header values, elimination of various elements such as response
status-text and the host header, and so on, a discussion of
eliminating conneg wouldn't be too extreme :-) ... The one thing to
consider is that it ought to be at least possible to deprecate conneg
without removing it entirely. We'll need to keep the mechanism around
for http/1 interop and passthrough but we can say instruct developers
that conneg ought to be avoided and we can discuss and highlight the
appropriate alternatives.

- James

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Feb 2013 10:39:53 -0800

> appropriate alternatives.

Dropping those other things is largely possible because they are
either invalid, or are being replaced by an analogue.  I think it
unlikely that conneg can be safely dropped.  There are just too many
people using it.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 13 Feb 2013 14:28:32 -0700

James M Snell wrote:
> eliminating conneg wouldn't be too extreme :-) ...
>

Nor would updating the WG charter to account for such changes ;-) ...

>
> The one thing to consider is that it ought to be at least possible to
> deprecate conneg without removing it entirely. We'll need to keep the
> mechanism around for http/1 interop and passthrough but we can say
> instruct developers that conneg ought to be avoided and we can
> discuss and highlight the appropriate alternatives.
> 

Which is exactly why I'd like to see this discussed further on the REST
list.  If the "solution" to conneg is to either require an extra round-
trip per request to indicate "compressed representation, please," or to
make compression stateful, then it's harder for me to buy into the
notion of server-driven negotiation as a "revolting feature."

IOW, I can't participate in a discussion about the way forward, if I
don't understand the problem with the status quo.  What am I missing?
I do think such theoretical architectural discussion belongs elsewhere;
at least as I see it, this list should be nuts-and-bolts protocol
writing.  I'm told this has been discussed before, links would help.

-Eric

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 13 Feb 2013 15:04:25 -0800

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

> 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

Proactive conneg is an optional feature of HTTP.

....Roy

---

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 13 Feb 2013 18:38:22 -0700

"Roy T. Fielding" wrote:
>
> 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

Well, that explains it!  That's when I got my start as a Web developer,
I think the rest of my career may be summed up as trying to un-learn
those bad habits...

> Defining protocol elements for reactive negotiation is one
> alternative. Encouraging the use of media types with inherent content

OK, thanks for elaborating.

-Eric

---

From: Nicholas Shanks <[email-masked]>
Date: Sat, 16 Feb 2013 00:40:56 +0000

> Proactive conneg is an optional feature of HTTP.

will Accept-* be demoted to appendices and Alternates & Link get higher
prominence in the updated HTTP 1.1 specs?
I would love it if browsers automatically selected from provided alternates
based on device-specific heuristics when receiving a 406.

— Nicholas.

-- 
Nicholas.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 16 Feb 2013 09:53:16 +0100

> prominence in the updated HTTP 1.1 specs?

No.

As a reminder: we are past WGLC with these documents.

> I would love it if browsers automatically selected from provided
> alternates based on device-specific heuristics when receiving a 406.

Best regards, Julian