IETF Logo Mail Archive

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

"Roy T. Fielding" <fielding@gbiv.com> Mon, 10 January 2011 00:40 UTC

Return-Path: <fielding@gbiv.com>
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 34DFB3A6855 for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 16:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.168
X-Spam-Level:
X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 4ZX+3Gl6mpuK for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 16:40:07 -0800 (PST)
Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 3FC333A6833 for <hybi@ietf.org>; Sun, 9 Jan 2011 16:40:07 -0800 (PST)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 7BC8A10062; Sun, 9 Jan 2011 16:42:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=qHjq3vW92AqsrBUJ nZx74XhYsZFpwvlpJeHOfjAQmIfoMRciInAiEb7dzdFhXm/hJn0aRAIFYOZyI1WX CEPcckmp3zXWVy9co3vlFTe9w0zOrOeZZGHlA834DQ2wmAa93kDsN6oE9A4PNXTW gso9Gy1ifF7gNAq/fck1qWO+/tI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=bXXhbY43lkCnShyodRhZN/apJis=; b=wZ0zVQqGPgnlR7vvEsOZ6sOqV9W0 g4cqv+OBW6MLlyrGHOsCAEEZxIWdI8aEvNXZ25tr7SItHjFye/5JKM8IpqP/Disr IokLJKa1vQC2FxzZA8glPr2yq4EdTd5JfSl1ucw+jVOgT9jz3CKqJf173shy5cT5 pyz4haAIgvt3f0g=
Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 3215C1005D; Sun, 9 Jan 2011 16:42:19 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <4D2A4738.2000500@gmx.de>
Date: Sun, 09 Jan 2011 16:42:28 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A76D8525-91F2-43E7-96E9-778113FB128C@gbiv.com>
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> <AANLkTinMo8xqhkB08bY8no1y5-7+7isCm97or6icH=r5@mail.gmail.com> <4D2A4738.2000500@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1082)
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: Mon, 10 Jan 2011 00:40:08 -0000

On Jan 9, 2011, at 3:39 PM, Julian Reschke wrote:

> On 10.01.2011 00:09, Adam Barth wrote:
>> ...
>> Whether we use OPTIONS or GET is much less than 1% of the value
>> proposition of the WebSockets protocol.  Rather than optimizing that
>> part of the protocol, it's more important to pick something and go
>> with it.
>> 
>> Honestly, I picked OPTIONS because it was the example given in
>> http://www.ietf.org/rfc/rfc2817.txt.
>> ...
> 
> OPTIONS isn't special with respect to Upgrade. (*)
> 
> My understanding is that the authors picked this example in order to avoid to let the server ignore the Upgrade request in GET, and then return the contents over an non-secured channel.
> 
> Unless there's a specific reason why people think OPTIONS is better than GET here, we should stick with what was discussed before.

OPTIONS is the appropriate method to use when the client
does not want the action taken to be retrieval of a
representation, especially when the resource might be
subject to hit counting (like an advertisement).

OPTIONS is preferred when you don't want the server to
provide an old-version response during an Upgrade, since
it has no negative implications for a compliant server.
Websocket should use OPTIONS for HTTP if it is not going
to mint a new method of its own.

....Roy

v2.23.0 | Report a Bug | By Email