- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Wed, 13 Feb 2013 14:28:32 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
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. -Eric
Received on Wednesday, 13 February 2013 21:29:06 UTC