IETF Logo Mail Archive

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

Greg Wilkins <gregw@webtide.com> Mon, 10 January 2011 06:36 UTC

Return-Path: <gregw@intalio.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 C19E93A6A5C for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 22:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.929
X-Spam-Level:
X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 IaAwr-zTQ3JN for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 22:36:46 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0FF453A6A53 for <hybi@ietf.org>; Sun, 9 Jan 2011 22:36:45 -0800 (PST)
Received: by qwi2 with SMTP id 2so3731029qwi.31 for <hybi@ietf.org>; Sun, 09 Jan 2011 22:38:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.214.71 with SMTP id gz7mr13014164qab.349.1294641538734; Sun, 09 Jan 2011 22:38:58 -0800 (PST)
Sender: gregw@intalio.com
Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:38:58 -0800 (PST)
In-Reply-To: <4D2A592B.3000404@gmx.de>
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> <A76D8525-91F2-43E7-96E9-778113FB128C@gbiv.com> <4D2A592B.3000404@gmx.de>
Date: Mon, 10 Jan 2011 07:38:58 +0100
X-Google-Sender-Auth: bQQXemEb5eIr8js3c00ocJbvwm4
Message-ID: <AANLkTim=KwA2Spm5AdS=9prxPQd1Cz8Tw9noN9VYGevt@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "Roy T. Fielding" <fielding@gbiv.com>, 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 06:36:49 -0000

On 10 January 2011 01:56, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> For simplicity, the best *server* side choice IMHO is to treat Upgrade the
> same way for a given URI, no matter what what request method was.

+1

The client should use another method (eg GET), only if it is prepared
to accept a valid response to that method (or the consequences on the
server of a PUT/POST/etc.) if the upgrade is not accepted (or is
discarded by an intermediary).

WS will be used in situations where fall back transports (eg long
polling) will be used if ws is not supported.  To avoid extra round
trips it is desirable that a failed WS handshake be able to be used as
part of the initiation of such a fallback prototocol.

I fully understand that such a fallback would need support in the
browser API, an that will not be coming any time soon, but that is no
reason to deny this approach in the protocol for the future or for non
browser clients.

cheers

v2.23.0 | Report a Bug | By Email