Re: #428 Accept-Language ordering for identical qvalues

"Eric J. Bowman" <> Wed, 13 February 2013 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E1D021F8A98 for <>; Wed, 13 Feb 2013 13:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ae5C8GPvqQ+T for <>; Wed, 13 Feb 2013 13:30:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 12E6921F8A90 for <>; Wed, 13 Feb 2013 13:30:07 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U5jtB-0005hZ-Ng for; Wed, 13 Feb 2013 21:29:13 +0000
Resent-Date: Wed, 13 Feb 2013 21:29:13 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U5jt4-0005gl-D7 for; Wed, 13 Feb 2013 21:29:06 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1U5jt2-0003Xh-93 for; Wed, 13 Feb 2013 21:29:06 +0000
Received: from WINBISON (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D0407509B6; Wed, 13 Feb 2013 16:28:41 -0500 (EST)
Date: Wed, 13 Feb 2013 14:28:32 -0700
From: "Eric J. Bowman" <>
To: James M Snell <>
Cc: "Roy T. Fielding" <>, Mark Nottingham <>, "Julian F. Reschke" <>, HTTP Working Group <>
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Organization: Bison Systems Corporation
X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=-2.922, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1U5jt2-0003Xh-93 258adfcff4070d913d3b8ffbd0a3410a
Subject: Re: #428 Accept-Language ordering for identical qvalues
Archived-At: <>
X-Mailing-List: <> archive/latest/16598
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

James M Snell wrote:
> 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 :-) ...

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.