Re: [hybi] OPTIONS (was Re: It's time to ship)

Willy Tarreau <w@1wt.eu> Sun, 09 January 2011 23:16 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030F23A6853 for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 15:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYfmMatqkHSi for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 15:16:08 -0800 (PST)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 16FCA3A6835 for <hybi@ietf.org>; Sun, 9 Jan 2011 15:16:02 -0800 (PST)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09NI8TT010275; Mon, 10 Jan 2011 00:18:08 +0100
Date: Mon, 10 Jan 2011 00:18:08 +0100
From: Willy Tarreau <w@1wt.eu>
To: Maciej Stachowiak <mjs@apple.com>
Message-ID: <20110109231808.GY5743@1wt.eu>
References: <AANLkTim2VGfH2FiJ4iH85wYiuXNKQ1Arh1C1Kg4M58Fs@mail.gmail.com> <20110109224228.GU5743@1wt.eu> <AANLkTimE-qOhYXO35nBqRWp9ipF-pk_CsO-YrotAjYqX@mail.gmail.com> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com>
User-Agent: Mutt/1.4.2.3i
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] OPTIONS (was Re: It's time to ship)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jan 2011 23:16:09 -0000

On Sun, Jan 09, 2011 at 03:06:12PM -0800, Maciej Stachowiak wrote:
> 
> On Jan 9, 2011, at 3:02 PM, Willy Tarreau wrote:
> 
> > On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote:
> >> On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau <w@1wt.eu> wrote:
> >>> On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote:
> >>>> 
> > 
> >>> At first glance, I'm noticing a few things :
> >>> 
> >>>  - you're using the OPTIONS method. The WG's consensus was voted as using
> >>>    GET. While technically working, OPTIONS limits some possibilities since
> >>>    no path is sent to the server.
> >> 
> >> Be that as it may.  OPTIONS is good enough.
> > 
> > But on what basis are you trying to change what was adopted as a consensus ?
> > I mean, I *know* that OPTIONS can evict more broken intermediaries than GET,
> > but the participants here have been working on the GET hypothesis with its
> > capabilities. Noone has had the opportunity to talk about their expectations
> > and the implications such a change would have for them.
> 
> Now seems like a fine time to discuss OPTIONS. What are the pros and cons? It seems to avoid the HTTP compliance issues that CONNECT had, at least.

Yes, OPTIONS+101 is equivalent for servers to what CONNECT is for proxies.
It has been evocated a bit in the past, but the discussion quickly ended and
nobody gave his opinion.

The pros is that some intermediaries unaware of the Upgrade mechanism will
respond themselves with 405, 501 or 200 depending on whether they support
it or not, which will cause a cleaner failure.

The cons is that it removes the ability to use any form of path in the
request, so you can only rely on the server name. Sure that's a lot better
than relying on its IP address, but it might not fit everyone's use. I can
live with it if required, as I've said several times in the last few months.
However, you once expressed concerns on this point about the ability to
forge OPTIONS requests using XMLHttpRequest (which I did not know were
possible).

The point is that it was said yesterday to one guy that once a consensus is
achieved, it must not be revisited, and now we're doing exactly that :-/

Willy