From Gabriel.Montenegro@microsoft.com Wed Feb 2 08:43:08 2011 Return-Path: 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 C43353A6D88 for ; Wed, 2 Feb 2011 08:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VOzeLIS1M27T for ; Wed, 2 Feb 2011 08:43:07 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E73AB3A6D7B for ; Wed, 2 Feb 2011 08:43:05 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Feb 2011 08:46:25 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 2 Feb 2011 08:46:25 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.102]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 2 Feb 2011 08:46:26 -0800 From: Gabriel Montenegro To: Julian Reschke Thread-Topic: [hybi] straw-poll on GET vs OPTIONS vs new method Thread-Index: AQHLuUoQ3oNzz/PaKUq0SFj3SnFkQpPnkhtggACoaYCABkJ88A== Date: Wed, 2 Feb 2011 16:46:23 +0000 Message-ID: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> In-Reply-To: <4D43D80B.7010903@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:43:08 -0000 Hi Julian, Sorry for the delay. You say you're "not convinced". Perhaps I can't convin= ce you as ultimately it might be a matter of taste. I can try to explain wh= y my distaste for OPTIONS. The issue with OPTIONS is that it is different in nature than GET. In both = cases there is processing that must deal with existing code paths and usage= . However, OPTIONS is meant for querying capabilities of the server. These = capabilities are ever expanding by adding modules to your server. OPTIONS p= rocessing is typically farmed out to those modules since they are the only = ones authoritative about the capabilities available via that particular mod= ule. So there's significant OPTIONS processing not just at the server, but = at random modules that happen to be added at that server (which may happen = even in the presence of a path). Mixing in what random modules will do as = part of their processing and how that might or might not affect OPTIONS pro= cessing, and in what mix of random modules, etc, is too much randomization= into the Upgrade processing. It's also the method to use to find out if th= e server supports websockets, except it is being proposed also as the metho= d to use to actually invoke them. It would be best from simplicity point of= view to keep those two roles separate.=20 We've been taking into consideration the enormous variability of infrastruc= ture and proxies in our decisions so far, I think ignoring the ever expandi= ng processing of OPTIONS due to random modules or plug-ins at servers, and = how that will interact with websockets is inconsistent with that concern. That's why I think it is the worst of all methods being discussed. Gabriel > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Saturday, January 29, 2011 1:04 AM > To: Gabriel Montenegro > Cc: Salvatore Loreto; hybi@ietf.org; Joe Hildebrand; SM > Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method >=20 > On 29.01.2011 08:03, Gabriel Montenegro wrote: > > ... > > The point that previous uses of OPTIONS can lead to confusion with prev= ious > usage was made in reference to its use in CORS (http://www.w3.org/TR/cors= /). > There's also WEBDAV (http://tools.ietf.org/html/rfc4918) and others. Thi= s point > argues for WEBSOCKET (a brand new method with no other previous usage) > over either GET or OPTIONS. > > ... >=20 > I don't think there's a problem with OPTIONS and WebDAV. WebDAV uses > OPTIONS just the way it's designed for, and I'm not aware of any > potential problems using OPTIONS in other protocol exchanges as well. If > you do, you need to elaborate. >=20 > OPTIONS and CORS is a slightly different story because of the stupid > requirement CORS makes on OPTIONS not to require authentication. That's > a design flaw in CORS. I'm not sure how it would affect usage of OPTIONS > over here, though. >=20 > > +1 WEBSOCKET > > > > Even though both GET and OPTIONS have existing usage, they are not equa= lly > safe. GET and POST (which are by far the most used) undergo much more > scrutiny than other lesser-known or completely arbitrary methods. Lesser > methods can be used to exploit vulnerabilities in faulty ACL checking: > > > http://www.owasp.org/index.php/Testing_for_HTTP_Methods_and_XST_(OWA > SP-CM-008)#Arbitrary_HTTP_Methods >=20 > Not convinced. The linked text correctly reports that some frameworks do > only ACL on certain methods, but then fallback to execute unknown > methods as GET. That's a bug, indeed. Do we have evidence that > Websockets is going to be deployable on frameworks like these anyway? > Also, these frameworks are vulnerable already, how does Websockets > change the situation? >=20 > > ... > > Another point against GET and OPTIONS is that both are supposed to be > idempotent. This has been misconstrued as a requirement to cause no chang= es > at the server. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics= - > 12#section-7.1.2 clarifies: > > > > ... It is important to > > note that idempotence refers only to changes requested by the clien= t: > > a server is free to change its state due to multiple requests for t= he > > purpose of tracking those requests, versioning of results, etc. > > > > Since the Upgrade effects a change on the connection, not on the resour= ce, I > don't see idempotence as an argument against GET, OPTIONS or any other > idempotent method. > > ... >=20 > That's correct. >=20 > Best regards, Julian From julian.reschke@gmx.de Wed Feb 2 08:57:28 2011 Return-Path: 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 787803A6CEC for ; Wed, 2 Feb 2011 08:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.103 X-Spam-Level: X-Spam-Status: No, score=-104.103 tagged_above=-999 required=5 tests=[AWL=-1.504, 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 ioZOp9QGaox6 for ; Wed, 2 Feb 2011 08:57:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 33A123A6C0B for ; Wed, 2 Feb 2011 08:57:26 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2011 17:00:45 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.134]) [217.91.35.233] by mail.gmx.net (mp053) with SMTP; 02 Feb 2011 18:00:45 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19lkfdqgCplBde6hGa1euLHKDePHjqvXsZJmPeI2G RN+A0h8PcuvcYy Message-ID: <4D498DB8.703@gmx.de> Date: Wed, 02 Feb 2011 18:00:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gabriel Montenegro References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 16:57:28 -0000 On 02.02.2011 17:46, Gabriel Montenegro wrote: > Hi Julian, > > Sorry for the delay. You say you're "not convinced". Perhaps I can't convince you as ultimately it might be a matter of taste. I can try to explain why my distaste for OPTIONS. > > The issue with OPTIONS is that it is different in nature than GET. In both cases there is processing that must deal with existing code paths and usage. However, OPTIONS is meant for querying capabilities of the server. These capabilities are ever expanding by adding modules to your server. OPTIONS processing is typically farmed out to those modules since they are the only ones authoritative about the capabilities available via that particular module. So there's significant OPTIONS processing not just at the server, but at random modules that happen to be added at that server (which may happen even in the presence of a path). Mixing in what random modules will do as part of their processing and how that might or might not affect OPTIONS processing, and in what mix of random modules, etc, is too much randomization into the Upgrade processing. It's also the method to use to find out if the server supports websockets, except it is being proposed also as the method to use to actually invoke them. It would be best from simplicity point of view to keep those two roles separate. > > We've been taking into consideration the enormous variability of infrastructure and proxies in our decisions so far, I think ignoring the ever expanding processing of OPTIONS due to random modules or plug-ins at servers, and how that will interact with websockets is inconsistent with that concern. > > That's why I think it is the worst of all methods being discussed. > > Gabriel Hi Gabriel, clarifying: are you talking about "OPTIONS *" or about "OPTIONS /path"? I agree that the former is a non-starter (because you'd need to collect information from many modules), but I'm not sure how the latter is different from any other method -- the path identifies a module handling the resource, and that module should be able to give a reply about its communications options... BR, Julian From Gabriel.Montenegro@microsoft.com Wed Feb 2 11:44:13 2011 Return-Path: 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 F2F3C3A6D8E for ; Wed, 2 Feb 2011 11:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 eR40ltH23Y1N for ; Wed, 2 Feb 2011 11:44:12 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id F2A6B3A6C0B for ; Wed, 2 Feb 2011 11:44:11 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Feb 2011 11:47:32 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 2 Feb 2011 11:47:32 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.102]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 2 Feb 2011 11:47:31 -0800 From: Gabriel Montenegro To: 'Julian Reschke' Thread-Topic: [hybi] straw-poll on GET vs OPTIONS vs new method Thread-Index: AQHLuUoQ3oNzz/PaKUq0SFj3SnFkQpPnkhtggACoaYCABkJ88IAAi/gA//+YipA= Date: Wed, 2 Feb 2011 19:47:33 +0000 Message-ID: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> In-Reply-To: <4D498DB8.703@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:44:13 -0000 Because of the extensible nature of OPTIONS, even with a path things may no= t be as predictable. We don't know for sure that a path will strictly limit= processing to a given module. There's too much variability out there in te= rms of modules, much greater than that inherent in base servers themselves. For example, "/" may be answered by both the HTTP server or the WebDAV modu= le (and there may be others). RFC2518 was revised by RFC4918 and that now i= ncludes some warning about that (section 10.1), but there is existing pract= ice along these lines: http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic=3D/c= om.ibm.wp.zos.doc_v615/admin/webdav_http_options.html=20 It would be best to avoid usurping OPTIONS for the websocket handshake (but= it should be reusable to query about WS support). > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, February 02, 2011 9:01 AM > To: Gabriel Montenegro > Cc: Salvatore Loreto; hybi@ietf.org; Joe Hildebrand; SM > Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method >=20 > On 02.02.2011 17:46, Gabriel Montenegro wrote: > > Hi Julian, > > > > Sorry for the delay. You say you're "not convinced". Perhaps I can't co= nvince > you as ultimately it might be a matter of taste. I can try to explain why= my > distaste for OPTIONS. > > > > The issue with OPTIONS is that it is different in nature than GET. In > > both cases there is processing that must deal with existing code paths > > and usage. However, OPTIONS is meant for querying capabilities of the > > server. These capabilities are ever expanding by adding modules to > > your server. OPTIONS processing is typically farmed out to those > > modules since they are the only ones authoritative about the > > capabilities available via that particular module. So there's > > significant OPTIONS processing not just at the server, but at random > > modules that happen to be added at that server (which may happen even > > in the presence of a path). Mixing in what random modules will do as > > part of their processing and how that might or might not affect > > OPTIONS processing, and in what mix of random modules, etc, is too > > much randomization into the Upgrade processing. It's also the method > > to use to find out if the server supports websockets, except it is > > being proposed also as the method to use to > actually invoke them. It would be best from simplicity point of view to k= eep > those two roles separate. > > > > We've been taking into consideration the enormous variability of > infrastructure and proxies in our decisions so far, I think ignoring the = ever > expanding processing of OPTIONS due to random modules or plug-ins at serv= ers, > and how that will interact with websockets is inconsistent with that conc= ern. > > > > That's why I think it is the worst of all methods being discussed. > > > > Gabriel >=20 > Hi Gabriel, >=20 > clarifying: are you talking about "OPTIONS *" or about "OPTIONS /path"? >=20 > I agree that the former is a non-starter (because you'd need to collect > information from many modules), but I'm not sure how the latter is differ= ent > from any other method -- the path identifies a module handling the resour= ce, > and that module should be able to give a reply about its communications > options... >=20 > BR, Julian From julian.reschke@gmx.de Wed Feb 2 12:07:51 2011 Return-Path: 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 7134C3A6CDC for ; Wed, 2 Feb 2011 12:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.836 X-Spam-Level: X-Spam-Status: No, score=-103.836 tagged_above=-999 required=5 tests=[AWL=-1.237, 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 oOR5cQbTRQyv for ; Wed, 2 Feb 2011 12:07:49 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 2D2F73A6BA9 for ; Wed, 2 Feb 2011 12:07:48 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2011 20:11:07 -0000 Received: from p508FDB5B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.219.91] by mail.gmx.net (mp013) with SMTP; 02 Feb 2011 21:11:07 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19uK+NINr5u728JktODroGPGBTtSLZmd7apTj8awh FoEN77pumOcKHZ Message-ID: <4D49BA55.3050808@gmx.de> Date: Wed, 02 Feb 2011 21:11:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Gabriel Montenegro References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:07:51 -0000 On 02.02.2011 20:47, Gabriel Montenegro wrote: > Because of the extensible nature of OPTIONS, even with a path things may not be as predictable. We don't know for sure that a path will strictly limit processing to a given module. There's too much variability out there in terms of modules, much greater than that inherent in base servers themselves. OK, but if that is the case, *any* method will have the same problem, unless you just define a new one for websockets. > For example, "/" may be answered by both the HTTP server or the WebDAV module (and there may be others). RFC2518 was revised by RFC4918 and that now includes some warning about that (section 10.1), but there is existing practice along these lines: Ah, finally somebody reading RFC 4918 :-) > http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic=/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html The only client I know that has this problem is the Microsoft WebDAV Mini-Redirector. The problem was reported around when it came out (over 7 years ago), and as far as I know hasn't been fixed. () So, yes, this is a problem when clients do the wrong thing and aren't properly maintained. (Sorry if this sounds like a cheap shot, but Microsoft's unwillingness to fix their WebDAV clients has frustrated me for a long long REALLY long time). > It would be best to avoid usurping OPTIONS for the websocket handshake (but it should be reusable to query about WS support). Now I'm confused. If you can make OPTIONS respond to a query for WS support then why can't you also make it respond to Upgrade for WS? Best regards, Julian From ifette@google.com Wed Feb 2 15:53:21 2011 Return-Path: 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 0090D3A6CA1 for ; Wed, 2 Feb 2011 15:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.457 X-Spam-Level: X-Spam-Status: No, score=-105.457 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 80l-yKewW4BP for ; Wed, 2 Feb 2011 15:53:19 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 94EB73A6C91 for ; Wed, 2 Feb 2011 15:53:18 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p12NucQH003641 for ; Wed, 2 Feb 2011 15:56:39 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296690999; bh=qto7274qw3U1PTb0BDrkWBnQkj8=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=k97t0wJCMJWxYAoSHSBk+W0AZKv4Or5AqbEg1cm4YeO15NKv16eQxmoV3/RTmLVqj 5nmsnqEwmR/mwriMZJovg== Received: from iye19 (iye19.prod.google.com [10.241.50.19]) by kpbe14.cbf.corp.google.com with ESMTP id p12NuO7Q031340 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 2 Feb 2011 15:56:37 -0800 Received: by iye19 with SMTP id 19so523787iye.18 for ; Wed, 02 Feb 2011 15:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TGlkyuJMkmsyMhrqhkYzd/zr35DDnP/I02/JanTdfEM=; b=gVHY+JCGtAnQcbikMLsWJg2dTTgxvlgsp0KEaD/h9twXaheTx6o6IzJHkM1F2BxAWy zss1IzTCfCpsRInjxEoQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=US8xnsAzJm22nvyLWRDR4ZLt4ZRm23f5g85/5UH0KyX2ZQXRSGI9W5jMgfdjewqKuO RaanhJnT+BYOphENQEdA== MIME-Version: 1.0 Received: by 10.231.14.74 with SMTP id f10mr10820666iba.119.1296690996650; Wed, 02 Feb 2011 15:56:36 -0800 (PST) Received: by 10.231.13.66 with HTTP; Wed, 2 Feb 2011 15:56:36 -0800 (PST) In-Reply-To: <4D49BA55.3050808@gmx.de> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> Date: Wed, 2 Feb 2011 15:56:36 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Julian Reschke Content-Type: multipart/alternative; boundary=00221532cb383d2520049b5566a6 X-System-Of-Record: true Cc: Joe Hildebrand , "hybi@ietf.org" , Gabriel Montenegro , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 23:53:21 -0000 --00221532cb383d2520049b5566a6 Content-Type: text/plain; charset=UTF-8 I also prefer OPTIONS + PATH and don't believe there's any significant confusion that will arise out of this, but more than anything at this point I would like to get some call from the chairs and move on. I thought this was supposed to close on the 31st? On Wed, Feb 2, 2011 at 12:11 PM, Julian Reschke wrote: > On 02.02.2011 20:47, Gabriel Montenegro wrote: > >> Because of the extensible nature of OPTIONS, even with a path things may >> not be as predictable. We don't know for sure that a path will strictly >> limit processing to a given module. There's too much variability out there >> in terms of modules, much greater than that inherent in base servers >> themselves. >> > > OK, but if that is the case, *any* method will have the same problem, > unless you just define a new one for websockets. > > > For example, "/" may be answered by both the HTTP server or the WebDAV >> module (and there may be others). RFC2518 was revised by RFC4918 and that >> now includes some warning about that (section 10.1), but there is existing >> practice along these lines: >> > > Ah, finally somebody reading RFC 4918 :-) > > > >> http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic=/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html >> > > The only client I know that has this problem is the Microsoft WebDAV > Mini-Redirector. The problem was reported around when it came out (over 7 > years ago), and as far as I know hasn't been fixed. (< > http://greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-server-discovery > >) > > So, yes, this is a problem when clients do the wrong thing and aren't > properly maintained. > > (Sorry if this sounds like a cheap shot, but Microsoft's unwillingness to > fix their WebDAV clients has frustrated me for a long long REALLY long > time). > > > It would be best to avoid usurping OPTIONS for the websocket handshake >> (but it should be reusable to query about WS support). >> > > Now I'm confused. If you can make OPTIONS respond to a query for WS support > then why can't you also make it respond to Upgrade for WS? > > Best regards, Julian > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --00221532cb383d2520049b5566a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also prefer OPTIONS + PATH and don't believe there's any signific= ant confusion that will arise out of this, but more than anything at this p= oint I would like to get some call from the chairs and move on. I thought t= his was supposed to close on the 31st?

On Wed, Feb 2, 2011 at 12:11 PM, Julian Resc= hke <julian.r= eschke@gmx.de> wrote:
On 02.02.2011 20:47, Gabriel Montenegro wrote:
Because of the extensible nature of OPTIONS, even with a path things may no= t be as predictable. We don't know for sure that a path will strictly l= imit processing to a given module. There's too much variability out the= re in terms of modules, much greater than that inherent in base servers the= mselves.

OK, but if that is the case, *any* method will have the same problem, unles= s you just define a new one for websockets.


For example, "/" may be answered by both the HTTP server or the W= ebDAV module (and there may be others). RFC2518 was revised by RFC4918 and = that now includes some warning about that (section 10.1), but there is exis= ting practice along these lines:

Ah, finally somebody reading RFC 4918 :-)


http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?t= opic=3D/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html

The only client I know that has this problem is the Microsoft WebDAV Mini-R= edirector. The problem was reported around when it came out (over 7 years a= go), and as far as I know hasn't been fixed. (<http://greenbytes.de/tech/webdav/webdav-redirector-list.h= tml#issue-server-discovery>)

So, yes, this is a problem when clients do the wrong thing and aren't p= roperly maintained.

(Sorry if this sounds like a cheap shot, but Microsoft's unwillingness = to fix their WebDAV clients has frustrated me for a long long REALLY long t= ime).


It would be best to avoid usurping OPTIONS for the websocket handshake (but= it should be reusable to query about WS support).

Now I'm confused. If you can make OPTIONS respond to a query for WS sup= port then why can't you also make it respond to Upgrade for WS?

Best regards, Julian

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--00221532cb383d2520049b5566a6-- From Gabriel.Montenegro@microsoft.com Wed Feb 2 16:00:09 2011 Return-Path: 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 9FCB33A6DB7 for ; Wed, 2 Feb 2011 16:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8m6r7+f84W2j for ; Wed, 2 Feb 2011 16:00:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DC2F53A6D79 for ; Wed, 2 Feb 2011 16:00:04 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Feb 2011 16:03:24 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 2 Feb 2011 16:03:24 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.102]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 2 Feb 2011 16:03:23 -0800 From: Gabriel Montenegro To: 'Julian Reschke' Thread-Topic: [hybi] straw-poll on GET vs OPTIONS vs new method Thread-Index: AQHLuUoQ3oNzz/PaKUq0SFj3SnFkQpPnkhtggACoaYCABkJ88IAAi/gA//+YipCAAJylgP//fWdQ Date: Thu, 3 Feb 2011 00:03:23 +0000 Message-ID: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> In-Reply-To: <4D49BA55.3050808@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:00:09 -0000 Hi Julian, You are reinforcing my point that there are legacy issues with OPTIONS. I h= ave no comments on your info as to who's at fault for introducing some of t= hose issues, but the fact is that now we have them. Relying on such a metho= d for websockets is asking for trouble. These legacy issues can be avoided= by using a new method. I tend to think that the issue is worse for OPTIONS= than for GET as I've said, but that is how I worded it: this reuse is bad = for any existing method (which you also agree to). Again: If I had to choose between GET and OPTIONS, I would choose GET. At least wi= th GET there are some pros, like being able to reuse widely implemented sem= antics. If you see this as a pro, then you can issue queries as usual, and = instead of (or in addition to) having the option to respond to them within = HTTP as usual, we would now have the option to switch into websockets and t= hen respond. With OPTIONS I only see the cons.=20 If the choice is between WEBSOCKET (a new method) and OPTIONS (perhaps beca= use the pros on the GET side are actually deemed to be a cons) then I would= choose WEBSOCKET to avoid legacy issues and for other advantages as noted = by others.=20 At this point, it seems like the debate has come down to this choice betwee= n WEBSOCKET and OPTIONS, so in this case I'll clearly state my preference f= or WEBSOCKET (a new method). Either case, I would avoid OPTIONS. Gabriel > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: 02 February, 2011 12:11 > To: Gabriel Montenegro > Cc: Salvatore Loreto; hybi@ietf.org; Joe Hildebrand; SM > Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method >=20 > On 02.02.2011 20:47, Gabriel Montenegro wrote: > > Because of the extensible nature of OPTIONS, even with a path things ma= y > not be as predictable. We don't know for sure that a path will strictly l= imit > processing to a given module. There's too much variability out there in t= erms of > modules, much greater than that inherent in base servers themselves. >=20 > OK, but if that is the case, *any* method will have the same problem, unl= ess > you just define a new one for websockets. >=20 > > For example, "/" may be answered by both the HTTP server or the WebDAV > module (and there may be others). RFC2518 was revised by RFC4918 and that > now includes some warning about that (section 10.1), but there is existin= g > practice along these lines: >=20 > Ah, finally somebody reading RFC 4918 :-) >=20 > > http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic > > =3D/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html >=20 > The only client I know that has this problem is the Microsoft WebDAV Mini= - > Redirector. The problem was reported around when it came out (over > 7 years ago), and as far as I know hasn't been fixed. > ( discovery>) >=20 > So, yes, this is a problem when clients do the wrong thing and aren't pro= perly > maintained. >=20 > (Sorry if this sounds like a cheap shot, but Microsoft's unwillingness to= fix their > WebDAV clients has frustrated me for a long long REALLY long time). >=20 > > It would be best to avoid usurping OPTIONS for the websocket handshake = (but > it should be reusable to query about WS support). >=20 > Now I'm confused. If you can make OPTIONS respond to a query for WS suppo= rt > then why can't you also make it respond to Upgrade for WS? >=20 > Best regards, Julian From derhoermi@gmx.net Wed Feb 2 16:44:48 2011 Return-Path: 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 27B153A6359 for ; Wed, 2 Feb 2011 16:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599] 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 yRBqF6+iITac for ; Wed, 2 Feb 2011 16:44:47 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A375B3A6405 for ; Wed, 2 Feb 2011 16:44:46 -0800 (PST) Received: (qmail invoked by alias); 03 Feb 2011 00:48:05 -0000 Received: from dslb-094-223-191-191.pools.arcor-ip.net (EHLO hive) [94.223.191.191] by mail.gmx.net (mp026) with SMTP; 03 Feb 2011 01:48:05 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+KFdB2qHuK0ZKYAy5wfaWL7BIMMmB41lym+AxSRS ZWHNzYW+MdpfyL From: Bjoern Hoehrmann To: ifette@google.com Date: Thu, 03 Feb 2011 01:48:04 +0100 Message-ID: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:44:48 -0000 * Ian Fette wrote: >I also prefer OPTIONS + PATH and don't believe there's any significant >confusion that will arise out of this, but more than anything at this point >I would like to get some call from the chairs and move on. I thought this >was supposed to close on the 31st? It's just a straw poll, and the Working Group does not seem to lean in any particular direction; that leaves us somewhere between "this does not seem to matter much" and "more discussion is needed". As far as I am concerned, I am willing to accept that "GET" has short-term benefits, while "WEBSOCKET" has long-term benefits. I haven't seen an argument why "OPTIONS" is better than both of those alternatives. If you, or others, have a good one, that would make it easier for our chairs to assess what the rough consensus looks like. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ifette@google.com Wed Feb 2 17:12:11 2011 Return-Path: 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 B2D763A6768 for ; Wed, 2 Feb 2011 17:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 gE5YIDt+4SqL for ; Wed, 2 Feb 2011 17:12:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id AB3463A6403 for ; Wed, 2 Feb 2011 17:12:09 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p131FTjE023410 for ; Wed, 2 Feb 2011 17:15:29 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296695729; bh=Slcqr7XE4bePbG/Z6iAD/XggJoc=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=jgD13XU/WP/2eze8AHVsHYTzj4op3kLvxetphFKD+x2LWLiPHL7owMWHtUS6l3kFe Y7xESt06n2Mtx0HHnZd2w== Received: from iyi20 (iyi20.prod.google.com [10.241.51.20]) by wpaz29.hot.corp.google.com with ESMTP id p131FJKx009894 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 2 Feb 2011 17:15:28 -0800 Received: by iyi20 with SMTP id 20so590039iyi.14 for ; Wed, 02 Feb 2011 17:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tHGdUHS8qqSAECVldgGVzGR8GxSrTtTVfg8jzx7S9ok=; b=SqGwQSLak2EXapvIsWBl59RJtI/hhcFguFqYAFC6WioMGfSwjK/y1SAMKi3pRexzS5 rBq0XlPCwhC0gM/pITVg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=WA+KV2DQmtjHpxltbLoX4ztNJ/ucJa2QBCLhtDqLmgbTi7ItJRByc+fwr4HSCsxU5f uFlIMQR5DPiuaKD8wJsw== MIME-Version: 1.0 Received: by 10.231.10.76 with SMTP id o12mr10882735ibo.144.1296695727618; Wed, 02 Feb 2011 17:15:27 -0800 (PST) Received: by 10.231.13.66 with HTTP; Wed, 2 Feb 2011 17:15:27 -0800 (PST) In-Reply-To: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> Date: Wed, 2 Feb 2011 17:15:27 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=0022152d614d39fb6a049b568075 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 01:12:11 -0000 --0022152d614d39fb6a049b568075 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 2, 2011 at 4:48 PM, Bjoern Hoehrmann wrote: > * Ian Fette wrote: > >I also prefer OPTIONS + PATH and don't believe there's any significant > >confusion that will arise out of this, but more than anything at this > point > >I would like to get some call from the chairs and move on. I thought thi= s > >was supposed to close on the 31st? > > It's just a straw poll, and the Working Group does not seem to lean in > any particular direction; that leaves us somewhere between "this does > not seem to matter much" and "more discussion is needed". As far as I > am concerned, I am willing to accept that "GET" has short-term benefits, > while "WEBSOCKET" has long-term benefits. I haven't seen an argument why > "OPTIONS" is better than both of those alternatives. If you, or others, > have a good one, that would make it easier for our chairs to assess what > the rough consensus looks like. > It's not clear to me why WEBSOCKET actually adds anything over OPTIONS, eve= n after this whole thread. If something wants to look for websocket traffic it's not hard to do so regardless of what is used. OPTIONS has some advantages as demonstrated in other threads re: reducing the number of "confused" intermediaries, beyond that I really don't care. I don't get any of the "query" use cases, as I can't fathom connecting to some random endpoint without already knowing that it's a ws endpoint... As for the issue with multiple modules, if there is existing code out there that would actually be broken by our use of OPTIONS, then I am fine with WEBSOCKET -- this would be the only compelling argument in my mind. (That said, if we deployed WEBSOCKET and found that it had a lower connect rate than OPTIONS, I would want to reserve the right to change my mind...). Some posts have raised potential issues but it wasn't clear to me whether these were theoretical possibilities or actual deployments that would have issues= . > -- > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://= bjoern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2= =B7 > http://www.bjoernsworld.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w= ebsitedev.de/ > --0022152d614d39fb6a049b568075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 2, 2011 at 4:48 PM, Bjoern H= oehrmann <derhoer= mi@gmx.net> wrote:
* Ian Fette wrote:
>I also prefer OPTIONS + PATH and don't believe there's any sign= ificant
>confusion that will arise out of this, but more than anything at this p= oint
>I would like to get some call from the chairs and move on. I thought th= is
>was supposed to close on the 31st?

It's just a straw poll, and the Working Group does not seem to le= an in
any particular direction; that leaves us somewhere between "this does<= br> not seem to matter much" and "more discussion is needed". As= far as I
am concerned, I am willing to accept that "GET" has short-term be= nefits,
while "WEBSOCKET" has long-term benefits. I haven't seen an a= rgument why
"OPTIONS" is better than both of those alternatives. If you, or o= thers,
have a good one, that would make it easier for our chairs to assess what the rough consensus looks like.

It'= s not clear to me why WEBSOCKET actually adds anything over OPTIONS, even a= fter this whole thread. If something wants to look for websocket traffic it= 's not hard to do so regardless of what is used. OPTIONS has some advan= tages as demonstrated in other threads re: reducing the number of "con= fused" intermediaries, beyond that I really don't care.

I don't get any of the "query" use cases,= as I can't fathom connecting to some random endpoint without already k= nowing that it's a ws endpoint...

As for the i= ssue with multiple modules, if there is existing code out there that would = actually be broken by our use of OPTIONS, then I am fine with WEBSOCKET -- = this would be the only compelling argument in my mind. (That said, if we de= ployed WEBSOCKET and found that it had a lower connect rate than OPTIONS, I= would want to reserve the right to change my mind...). Some posts have rai= sed potential issues but it wasn't clear to me whether these were theor= etical possibilities or actual deployments that would have issues.

=C2=A0
--
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415= 681 =C2=B7 htt= p://www.bjoernsworld.de
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/

--0022152d614d39fb6a049b568075-- From gregw@intalio.com Wed Feb 2 17:55:59 2011 Return-Path: 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 1FFAC3A679F for ; Wed, 2 Feb 2011 17:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, 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 ECkL7yK0ZPLS for ; Wed, 2 Feb 2011 17:55:58 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3EA7E3A659A for ; Wed, 2 Feb 2011 17:55:58 -0800 (PST) Received: by vws7 with SMTP id 7so362455vws.31 for ; Wed, 02 Feb 2011 17:59:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.81.5 with SMTP id v5mr2703853vck.74.1296698357071; Wed, 02 Feb 2011 17:59:17 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.98.9 with HTTP; Wed, 2 Feb 2011 17:59:16 -0800 (PST) In-Reply-To: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> Date: Thu, 3 Feb 2011 12:59:16 +1100 X-Google-Sender-Auth: 7UJR0M73TMdtTK_KydsLwI6_FFo Message-ID: From: Greg Wilkins To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 01:55:59 -0000 On 3 February 2011 11:48, Bjoern Hoehrmann wrote: > * Ian Fette wrote: > It's just a straw poll, and the Working Group does not seem to lean in > any particular direction; that leaves us somewhere between "this does > not seem to matter much" and "more discussion is needed". Which matches perfectly one of the options: Make the handshake work with any method with a note saying the client should expect a non WS return if the path and/or server does not support WS. Of course the browsers will still have to make a choice of a method, but they could experiment with a few methods and then choose the best one without needing to have the servers and intermediaries re implemented. regards From w@1wt.eu Wed Feb 2 21:55:19 2011 Return-Path: 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 CF66E3A6876 for ; Wed, 2 Feb 2011 21:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 k1-4b5e20se8 for ; Wed, 2 Feb 2011 21:55:18 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 750AC3A6872 for ; Wed, 2 Feb 2011 21:55:17 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p135wRWD020408; Thu, 3 Feb 2011 06:58:27 +0100 Date: Thu, 3 Feb 2011 06:58:27 +0100 From: Willy Tarreau To: Gabriel Montenegro Message-ID: <20110203055827.GB18511@1wt.eu> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 05:55:20 -0000 Hi Gabriel, On Thu, Feb 03, 2011 at 12:03:23AM +0000, Gabriel Montenegro wrote: > Hi Julian, > > You are reinforcing my point that there are legacy issues with OPTIONS. I have no comments on your info as to who's at fault for introducing some of those issues, but the fact is that now we have them. Relying on such a method for websockets is asking for trouble. These legacy issues can be avoided by using a new method. I tend to think that the issue is worse for OPTIONS than for GET as I've said, but that is how I worded it: this reuse is bad for any existing method (which you also agree to). > > Again: > > If I had to choose between GET and OPTIONS, I would choose GET. At least with GET there are some pros, like being able to reuse widely implemented semantics. If you see this as a pro, then you can issue queries as usual, and instead of (or in addition to) having the option to respond to them within HTTP as usual, we would now have the option to switch into websockets and then respond. With OPTIONS I only see the cons. > > If the choice is between WEBSOCKET (a new method) and OPTIONS (perhaps because the pros on the GET side are actually deemed to be a cons) then I would choose WEBSOCKET to avoid legacy issues and for other advantages as noted by others. > > At this point, it seems like the debate has come down to this choice between WEBSOCKET and OPTIONS, so in this case I'll clearly state my preference for WEBSOCKET (a new method). > > Either case, I would avoid OPTIONS. As long as we use any method + Upgrade, I don't care much which one we use, what I don't want to see is a new method without Upgrade which implies a tunnel as we once expected it. I don't like much adding new methods, hence the reason why I'm not much in favor of WEBSOCKET and preferred OPTIONS, but if you say there are known issues with OPTIONS, even if they're rare, I agree we'd better avoid them. I'd still rather avoid GET to get rid of false positives on caches, though it's not a strong desire. Also, if we create a new method because we did not find one which matches our needs, maybe we should be less selfish and not call it WEBSOCKET. After all, if we're forced to create another new method, it's precisely because we did not find the perfect one among existing ones. It would be stupid that another WG in 5 years has the exact same requirement and has to use WEBSOCKET for another purpose because of its semantics. What we need is just something that upgrades the connection to a tunnel. We could very well call it TUNNEL or UPGRADE. At least, the last one clearly implies what the method is intended for and other projects will be able to use it too. Regards, Willy From andy@warmcat.com Thu Feb 3 02:44:21 2011 Return-Path: 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 516363A68F7 for ; Thu, 3 Feb 2011 02:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 RdO3WltOK4CA for ; Thu, 3 Feb 2011 02:44:20 -0800 (PST) Received: from warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by core3.amsl.com (Postfix) with ESMTP id 1AFC03A68F0 for ; Thu, 3 Feb 2011 02:44:20 -0800 (PST) Received: from warmcat.com (warmcat.com [127.0.0.1]) by warmcat.com (Postfix) with ESMTP id 3C90054A0A3 for ; Thu, 3 Feb 2011 10:37:46 +0000 (GMT) Message-ID: <4D4A8576.9060205@warmcat.com> Date: Thu, 03 Feb 2011 10:37:42 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Testing 04 on a paranoid proxy X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 10:44:21 -0000 Hi - I am visiting a semiconductor company in France at the moment and their guest network uses a quite aggressive proxy, I never had the opportunity to be behind such a thing before; maybe it is commonplace for other list members but I thought I would see what 04 websockets fared like with it. Here are the results of being an 04 client behind a "NetCache appliance (NetApp/6.0.5)". In each case the remote server is configured to the matching port and mode. Port: 7681 Mode: ws or wss Result: FAIL (port closed) Port: 80 Mode: ws Result: FAIL ("BAD GATEWAY") [1] Port: 80 Mode wss Result: FAIL (SSL HELLO broken) [2] Port 443: Mode ws Result: Worked fine Port 443: Mode wss Result: Worked fine I was a bit surprised that ws worked on 443 OK even though this proxy has been configured so aggressively as to kill IMAP on 993. This proxy configuration anyway seems to allow websocket funny business so long as it is 443. -Andy [1] $ libwebsockets-test-client warmcat.com --port 80 libwebsockets test client (C) Copyright 2010 Andy Green licensed under LGPL2.1 libwebsocket_client_handshake missing required header(s) HTTP/1.1 502 Bad Gateway Via: 1.0 BBSM53 Content-Length: 338 Date: Thu, 03 Feb 2011 10:31:05 GMT Content-Type: text/html Server: NetCache appliance (NetApp/6.0.5) 502 Bad Gateway

Bad Gateway

The following error occurred:

[code=DNS_HOST_NOT_FOUND] The host name was not found during the DNS lookup. Contact your system administrator if the problem is not found by retrying the URL.

Please contact the administrator. libwebsocket dumb connect failed [2] $ libwebsockets-test-client warmcat.com --ssl --port 80 libwebsockets test client (C) Copyright 2010 Andy Green licensed under LGPL2.1 SSL connect error error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol libwebsocket dumb connect failed From mnot@mnot.net Thu Feb 3 03:19:38 2011 Return-Path: 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 D7F633A68FE for ; Thu, 3 Feb 2011 03:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.663 X-Spam-Level: X-Spam-Status: No, score=-104.663 tagged_above=-999 required=5 tests=[AWL=-2.064, 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 iWVG16FNudhd for ; Thu, 3 Feb 2011 03:19:37 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 9DADD3A68FA for ; Thu, 3 Feb 2011 03:19:37 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.1.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB553509EB; Thu, 3 Feb 2011 06:22:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4D4A8576.9060205@warmcat.com> Date: Thu, 3 Feb 2011 22:22:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4A8576.9060205@warmcat.com> To: Andy Green X-Mailer: Apple Mail (2.1082) Cc: hybi@ietf.org Subject: Re: [hybi] Testing 04 on a paranoid proxy X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 11:19:38 -0000 FYI some background -- That's an old-ish version of netcache, IIRC. It = was a general proxy/cache solution (and a very very good one) that was = bought by a security-focused appliance company (BlueCoat) a few years = back. It'd be interesting to make the same requests from behind a BC box, but = I don't have access to any... Cheers, On 03/02/2011, at 9:37 PM, Andy Green wrote: > Hi - >=20 > I am visiting a semiconductor company in France at the moment and = their guest network uses a quite aggressive proxy, I never had the = opportunity to be behind such a thing before; maybe it is commonplace = for other list members but I thought I would see what 04 websockets = fared like with it. >=20 > Here are the results of being an 04 client behind a "NetCache = appliance (NetApp/6.0.5)". In each case the remote server is configured = to the matching port and mode. >=20 >=20 > Port: 7681 Mode: ws or wss Result: FAIL (port closed) >=20 > Port: 80 Mode: ws Result: FAIL ("BAD GATEWAY") [1] >=20 > Port: 80 Mode wss Result: FAIL (SSL HELLO broken) [2] >=20 > Port 443: Mode ws Result: Worked fine >=20 > Port 443: Mode wss Result: Worked fine >=20 > I was a bit surprised that ws worked on 443 OK even though this proxy = has been configured so aggressively as to kill IMAP on 993. This proxy = configuration anyway seems to allow websocket funny business so long as = it is 443. >=20 > -Andy >=20 >=20 > [1] > $ libwebsockets-test-client warmcat.com --port 80 > libwebsockets test client > (C) Copyright 2010 Andy Green licensed under = LGPL2.1 > libwebsocket_client_handshake missing required header(s) > HTTP/1.1 502 Bad Gateway > Via: 1.0 BBSM53 > Content-Length: 338 > Date: Thu, 03 Feb 2011 10:31:05 GMT > Content-Type: text/html > Server: NetCache appliance (NetApp/6.0.5) >=20 > > 502 Bad Gateway > >

Bad Gateway

>

> The following error occurred:

> [code=3DDNS_HOST_NOT_FOUND] The host name was not found during the DNS = lookup. Contact your system administrator if the problem is not found by = retrying the URL. >

>
> Please contact the administrator. > > > =7Flibwebsocket dumb connect failed >=20 > [2] >=20 > $ libwebsockets-test-client warmcat.com --ssl --port 80 > libwebsockets test client > (C) Copyright 2010 Andy Green licensed under = LGPL2.1 > SSL connect error error:140770FC:SSL = routines:SSL23_GET_SERVER_HELLO:unknown protocol > libwebsocket dumb connect failed > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Mark Nottingham http://www.mnot.net/ From ferg@caucho.com Thu Feb 3 11:53:16 2011 Return-Path: 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 4FC673A6A4F for ; Thu, 3 Feb 2011 11:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 4xWTDXIrcuj4 for ; Thu, 3 Feb 2011 11:53:15 -0800 (PST) Received: from nm19-vm0.bullet.mail.ne1.yahoo.com (nm19-vm0.bullet.mail.ne1.yahoo.com [98.138.91.59]) by core3.amsl.com (Postfix) with SMTP id DFBB43A6A07 for ; Thu, 3 Feb 2011 11:53:14 -0800 (PST) Received: from [98.138.90.56] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 03 Feb 2011 19:56:35 -0000 Received: from [98.138.89.173] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 03 Feb 2011 19:56:35 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 03 Feb 2011 19:56:35 -0000 X-Yahoo-Newman-Id: 99889.59577.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 65671 invoked from network); 3 Feb 2011 19:56:34 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 03 Feb 2011 11:56:34 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: SiXCQ4oVM1nwq8OiUWxqY.2hTfH4hi.LLKcO1RLOWEgvUfN loXW2QjEBuQ57RgByte3dxA5zi6G_hE2aA39MfImJsX7GwKM147kh06DXGEG OFpwNG81uMRaZdYO0_kqyvoOdokgBEFh0ILAkfcht6ZMlq5cJR71mwnzNExb qyBXUE_uhSDBOOe1o5ClEWnAwkYlK8IR..zaPd9amCrt7lqCJnYmubPdud2v rimAIvYrOK8FU.c7kzZF1CLRZCJwzswXbKdI_eoiROov0Df7rVvoKS7QB0UG E.FbPPGKf8hTReQueBuQfW5gKXvZjYUgMrT2z6KpSw1RumKzxDkSswJmk0YP jbNtjr4N8PWXYjctc.t_MXFoZfS4UQZQTcOnHnA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4B086B.7000901@caucho.com> Date: Thu, 03 Feb 2011 11:56:27 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Willy Tarreau References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> In-Reply-To: <20110203055827.GB18511@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , "hybi@ietf.org" , Gabriel Montenegro , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 19:53:16 -0000 Willy Tarreau wrote: > I don't like much adding new methods,... Method names in HTTP are not expensive. It's not like adding a keyword to a programming language, it's just an identifier. I've never been clear why anyone would think HTTP method names are some scarce resource that need to be carefully rationed and overloaded. > Also, if we create a new method because we did not find one which matches > our needs, maybe we should be less selfish and not call it WEBSOCKET. After > all, if we're forced to create another new method, it's precisely because > we did not find the perfect one among existing ones. It would be stupid > that another WG in 5 years has the exact same requirement and has to use > WEBSOCKET for another purpose because of its semantics. What we need is > just something that upgrades the connection to a tunnel. We could very > well call it TUNNEL or UPGRADE. At least, the last one clearly implies > what the method is intended for and other projects will be able to use > it too. > UPGRADE would be fine, too. As long as it clearly expresses what the request is doing, the exact name is less important. "TUNNEL", for example, would be a poor choice because it's not an accurate description of what the protocol is doing (for the endpoints at least), but would still be better than "GET" or "OPTIONS", which have totally different semantics. -- Scott > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > > From w@1wt.eu Thu Feb 3 13:09:03 2011 Return-Path: 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 351523A6AC8 for ; Thu, 3 Feb 2011 13:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 ADxmOnCk+ECL for ; Thu, 3 Feb 2011 13:09:02 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 178FB3A6A53 for ; Thu, 3 Feb 2011 13:09:00 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p13LC9ww025678; Thu, 3 Feb 2011 22:12:09 +0100 Date: Thu, 3 Feb 2011 22:12:09 +0100 From: Willy Tarreau To: Scott Ferguson Message-ID: <20110203211209.GC18511@1wt.eu> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4B086B.7000901@caucho.com> User-Agent: Mutt/1.4.2.3i Cc: Joe Hildebrand , "hybi@ietf.org" , Gabriel Montenegro , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:09:03 -0000 On Thu, Feb 03, 2011 at 11:56:27AM -0800, Scott Ferguson wrote: > Willy Tarreau wrote: > >I don't like much adding new methods,... > > Method names in HTTP are not expensive. It's not like adding a keyword > to a programming language, it's just an identifier. It's mainly that some products support a finite set of known methods, and eventhough adding one more is inexpensive in general, it at least requires a minor upgrade to support the new ones. Also sometimes the security impacts of crossing new methods with other URLs and conversely have to be qualified in some complex setups. For instance, when you know that nothing but GET/HEAD/POST/OPTIONS passes through your front component and all URLs are known to safely behave in such conditions, you might have to recheck that when the front component lets a new method pass. As I said it's not a big deal, but when not necessary I prefer to avoid it. Now, Gabriel has explained why we'd better go for a new method. In fact he's one of the only ones who have brought real arguments instead of just opinion as we almost all did. For this reason I tend to value his choice better than mine. (...) > UPGRADE would be fine, too. As long as it clearly expresses what the > request is doing, the exact name is less important. > > "TUNNEL", for example, would be a poor choice because it's not an > accurate description of what the protocol is doing (for the endpoints at > least), but would still be better than "GET" or "OPTIONS", which have > totally different semantics. Right. Regards, Willy From jmason@rim.com Thu Feb 3 14:09:50 2011 Return-Path: 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 841953A6B1D for ; Thu, 3 Feb 2011 14:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 MVdtEIiZVnqA for ; Thu, 3 Feb 2011 14:09:49 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 8DFDF3A6A00 for ; Thu, 3 Feb 2011 14:09:49 -0800 (PST) X-AuditID: 0a666446-b7ba6ae0000051d3-06-4d4b28782c7b Received: from XHT110CNC.rim.net ( [10.65.22.55]) by mhs04ykf.rim.net (RIM Mail) with SMTP id AB.A7.20947.8782B4D4; Thu, 3 Feb 2011 17:13:12 -0500 (EST) Received: from XCH117CNC.rim.net ([fe80::b8df:541f:9d85:9909]) by XHT110CNC.rim.net ([fe80::d0e9:e16f:525b:55f5%11]) with mapi; Thu, 3 Feb 2011 17:13:11 -0500 From: Joe Mason To: Willy Tarreau , Gabriel Montenegro Date: Thu, 3 Feb 2011 17:13:11 -0500 Thread-Topic: [hybi] straw-poll on GET vs OPTIONS vs new method Thread-Index: AcvDZ2ubV5NPCPYMSFKA5JjIivIMwgAh/Fqg Message-ID: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> In-Reply-To: <20110203055827.GB18511@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAZEXVOHb Cc: Joe Hildebrand , "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:09:50 -0000 > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Willy Tarreau > > Also, if we create a new method because we did not find one which > matches > our needs, maybe we should be less selfish and not call it WEBSOCKET. > After > all, if we're forced to create another new method, it's precisely > because > we did not find the perfect one among existing ones. It would be stupid > that another WG in 5 years has the exact same requirement and has to > use > WEBSOCKET for another purpose because of its semantics. What we need is > just something that upgrades the connection to a tunnel. We could very > well call it TUNNEL or UPGRADE. At least, the last one clearly implies > what the method is intended for and other projects will be able to use > it too. +1 Still not convinced on the need or desirability of a new method, but if we d= o use one it should be descriptive of what the method does, not what protoco= l it's used in. Joe ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ferg@caucho.com Thu Feb 3 14:27:40 2011 Return-Path: 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 C7A073A6B1D for ; Thu, 3 Feb 2011 14:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] 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 NRmQyYJWCyHz for ; Thu, 3 Feb 2011 14:27:38 -0800 (PST) Received: from nm24-vm0.bullet.mail.ac4.yahoo.com (nm24-vm0.bullet.mail.ac4.yahoo.com [98.139.53.222]) by core3.amsl.com (Postfix) with SMTP id 727BC3A687A for ; Thu, 3 Feb 2011 14:27:37 -0800 (PST) Received: from [98.139.52.191] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 03 Feb 2011 22:30:58 -0000 Received: from [98.139.52.155] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 03 Feb 2011 22:30:58 -0000 Received: from [127.0.0.1] by omp1038.mail.ac4.yahoo.com with NNFMP; 03 Feb 2011 22:30:57 -0000 X-Yahoo-Newman-Id: 989891.40668.bm@omp1038.mail.ac4.yahoo.com Received: (qmail 57658 invoked from network); 3 Feb 2011 22:30:54 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 03 Feb 2011 14:30:54 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: E0O25HMVM1lMUM_WZ_o_xglRYe__DsSA29NtB5NdHo0uGZ4 9OxVnDCAfzeh1z2v1NGna0ugxTt0jktJRZ6zPTYngeyUKv9Ww.JgR8WTaKTJ CqDeumFTic9I_yO3P1drfiHpbwJyk_ZiG4X0BE6RV82PlqVfUIrLtA1mAj6B HinGVo4WKRBx_0kyZc7ZUINDs4IP2C_U5K4RLV6DSbCH0o2cNfsgOLP9L_PO jUa0jsR0CUV6cBSGps5H0I2oO__pucHT3aM2V9aYk2bB_kQ81Q8tqkb.Vv.F 1SHaZIVMp7JBdLNz8cfLMWUfLvUSKrRGPIl73QQbCIiv15OpP5rJprdoIF_A oBpUMySWdYBjxCd4H1DDmLuqwi_eLIIKjYnX6RLEa X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4B2C9D.2090807@caucho.com> Date: Thu, 03 Feb 2011 14:30:53 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Willy Tarreau References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <20110203211209.GC18511@1wt.eu> In-Reply-To: <20110203211209.GC18511@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , "hybi@ietf.org" , Gabriel Montenegro , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 22:27:41 -0000 Willy Tarreau wrote: > On Thu, Feb 03, 2011 at 11:56:27AM -0800, Scott Ferguson wrote: > >> Willy Tarreau wrote: >> >>> I don't like much adding new methods,... >>> >> Method names in HTTP are not expensive. It's not like adding a keyword >> to a programming language, it's just an identifier. >> > > It's mainly that some products support a finite set of known methods, and > eventhough adding one more is inexpensive in general, it at least requires > a minor upgrade to support the new ones. > But any product that supports websockets needs to be upgraded anyway (with the possible exception of passthrough proxies.) Compared to supporting the non-HTTP websockets protocol, the work needed to add a whitelist string is trivial. It's not like a servlet filter, for example, will automatically work with websockets just because the HTTP method name happens to be "GET". Not that websockets is all that complicated, but adding one string to a whitelist is about as trivial as possible. > Also sometimes the security impacts of crossing new methods with other URLs > and conversely have to be qualified in some complex setups. For instance, > when you know that nothing but GET/HEAD/POST/OPTIONS passes through your > front component and all URLs are known to safely behave in such conditions, > you might have to recheck that when the front component lets a new method > pass. > You'd want to do that with websockets anyway. Having a distinct method would reduce confusion, and if nothing else would let you blacklist websockets requests until you could upgrade. -- Scott > As I said it's not a big deal, but when not necessary I prefer to avoid it. > Now, Gabriel has explained why we'd better go for a new method. In fact > he's one of the only ones who have brought real arguments instead of just > opinion as we almost all did. For this reason I tend to value his choice > better than mine. > > (...) > >> UPGRADE would be fine, too. As long as it clearly expresses what the >> request is doing, the exact name is less important. >> >> "TUNNEL", for example, would be a poor choice because it's not an >> accurate description of what the protocol is doing (for the endpoints at >> least), but would still be better than "GET" or "OPTIONS", which have >> totally different semantics. >> > > Right. > > Regards, > Willy > > > > > From buskanaka@gmail.com Thu Feb 3 15:06:22 2011 Return-Path: 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 5E7BF3A6AC3 for ; Thu, 3 Feb 2011 15:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 7udVv8Hs9aGH for ; Thu, 3 Feb 2011 15:06:21 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 46D413A6A17 for ; Thu, 3 Feb 2011 15:06:21 -0800 (PST) Received: by ewy8 with SMTP id 8so1099880ewy.31 for ; Thu, 03 Feb 2011 15:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=BN9KwLbvmHDTOrWjuB4wYSd84wYjMpdHyXFfvuOOXRs=; b=x44tJ9MyaPANCTMQJlU/WyHb0UHEhCJWgbbVDGfC/yr9xwaND79La0JGMmeEsPKdzE 6Q6rQ8pNsdsHM6WZcZicHPU4pFqrakv1GLSqn3HnijE1eytJM6gVJsx8d7u8sS3G7MuS roC7JW2y2xJt/cTVhdp8GCoq/UZDh2m/QaMQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=gYHBTGf1N6EM2tTwsP2vIhBINW7u7ZXHtLu2oW8NiEyevikav8SpN1vSRCm5fpSGVh CDVJoYR5UyJiSlmCZk336E8fURUF48Qp15PbiqurOc/pN1AddWJok/Mg+ls7Q4b4F0dQ 84XWwgo7fdWfx8XQqU2BDo58eRKz+YVTldOA8= Received: by 10.14.11.226 with SMTP id 74mr794404eex.5.1296774583888; Thu, 03 Feb 2011 15:09:43 -0800 (PST) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.119.136 with HTTP; Thu, 3 Feb 2011 15:09:23 -0800 (PST) In-Reply-To: <4D4B2C9D.2090807@caucho.com> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <20110203211209.GC18511@1wt.eu> <4D4B2C9D.2090807@caucho.com> From: Joel Martin Date: Thu, 3 Feb 2011 17:09:23 -0600 X-Google-Sender-Auth: vW9_pxlr7YKdWKt6pLQrAV2qRBI Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=0016364d1e116d2db6049b68dcf1 Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 23:06:22 -0000 --0016364d1e116d2db6049b68dcf1 Content-Type: text/plain; charset=ISO-8859-1 There has already been a suggestion of allowing the client to pick a method (but still sending Upgrade: websocket). I would like to propose a variation on that: 1) The client should initially send: NEWMETHOD /path HTTP/1.1 ... Upgrade: websocket where NEWMETHOD is whatever new method is decided on by the working group whether TUNNEL, UPGRADE, WEBSOCKET or something else. 2) If server responds with 405 [Method not allowed] then the client may try again with GET as the method (with new keys/nonces but otherwise the same). Perhaps other 40X in addition to 405 should trigger a re-request. The important part is that the "Upgrade: websocket" header is sent in both cases. The purpose would be to encourage browser and server developers to use the new method (since there are advantages) but permit fall-back to GET when something along the path hasn't been updated to support the new method. Eventually the fall-back could be eliminated once it is no longer deemed useful. Regards, Joel Martin (kanaka) --0016364d1e116d2db6049b68dcf1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There has already been a suggestion of allowing the client to pick a method= (but still sending Upgrade: websocket). I would like to propose a variatio= n on that:

1) The client should initially send:

=A0=A0 =A0NEWMETHOD /path HTTP/1.1
=A0=A0 =A0...
=
=A0=A0 =A0Upgrade: websocket

where NEWMETHOD is whatev= er new method is decided on by the working group whether TUNNEL, UPGRADE, W= EBSOCKET or something else.

2) If server responds with 405 [Method not allowed] the= n the client may try again with GET as the method (with new keys/nonces but= otherwise the same). Perhaps other 40X in addition to 405 should trigger a= re-request.

The important part is that the "Upgrade: websocket= " header is sent in both cases. The purpose would be to encourage brow= ser and server developers to use the new method (since there are advantages= ) but permit fall-back to GET when something along the path hasn't been= updated to support the new method. Eventually the fall-back could be elimi= nated once it is no longer deemed useful.

Regards,
Joel Martin (kanaka)

<= /div>
--0016364d1e116d2db6049b68dcf1-- From julian.reschke@gmx.de Fri Feb 4 02:17:30 2011 Return-Path: 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 86CFB3A68D5 for ; Fri, 4 Feb 2011 02:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.81 X-Spam-Level: X-Spam-Status: No, score=-103.81 tagged_above=-999 required=5 tests=[AWL=-1.211, 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 k1jQ7f00BLsB for ; Fri, 4 Feb 2011 02:17:29 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A393F3A68CD for ; Fri, 4 Feb 2011 02:17:28 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2011 10:20:51 -0000 Received: from p508FDB1C.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.219.28] by mail.gmx.net (mp020) with SMTP; 04 Feb 2011 11:20:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18NLVsu/owNhSXn2cWBufMax30n3zKibjc4rKv6yS P89DB/A75E29j0 Message-ID: <4D4BD2FB.7060900@gmx.de> Date: Fri, 04 Feb 2011 11:20:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Scott Ferguson References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> In-Reply-To: <4D4B086B.7000901@caucho.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Joe Hildebrand , "hybi@ietf.org" , Gabriel Montenegro , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 10:17:30 -0000 On 03.02.2011 20:56, Scott Ferguson wrote: > Willy Tarreau wrote: >> I don't like much adding new methods,... > > Method names in HTTP are not expensive. It's not like adding a keyword > to a programming language, it's just an identifier. > > I've never been clear why anyone would think HTTP method names are some > scarce resource that need to be carefully rationed and overloaded. > >> Also, if we create a new method because we did not find one which matches >> our needs, maybe we should be less selfish and not call it WEBSOCKET. >> After >> all, if we're forced to create another new method, it's precisely because >> we did not find the perfect one among existing ones. It would be stupid >> that another WG in 5 years has the exact same requirement and has to use >> WEBSOCKET for another purpose because of its semantics. What we need is >> just something that upgrades the connection to a tunnel. We could very >> well call it TUNNEL or UPGRADE. At least, the last one clearly implies >> what the method is intended for and other projects will be able to use >> it too. > > UPGRADE would be fine, too. As long as it clearly expresses what the > request is doing, the exact name is less important. > > "TUNNEL", for example, would be a poor choice because it's not an > accurate description of what the protocol is doing (for the endpoints at > least), but would still be better than "GET" or "OPTIONS", which have > totally different semantics. > ... I'm not totally convinced that we can't use OPTIONS. If we *do* define a new method, we should be clear on its semantics (independently of Websockets) and other properties (safe, idempotent, cacheability). "UPGRADE" seems to be a poor choice, because what causes the upgrade is the header, not the method. So, if the method really is a No-Op designed just to carry the Upgrade header, then maybe it should be called "NOP". Also note: "HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, "type" of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific to a single application, so that this is clear." -- (note that's an ID only so the HTTPbis WG is looking for feedback on this) BR, Julian From tailhook@yandex.ru Fri Feb 4 02:44:06 2011 Return-Path: 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 D138A3A68F4 for ; Fri, 4 Feb 2011 02:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_05=-1.11] 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 CWos1+gM4caC for ; Fri, 4 Feb 2011 02:44:05 -0800 (PST) Received: from forward16.mail.yandex.net (forward16.mail.yandex.net [95.108.253.141]) by core3.amsl.com (Postfix) with ESMTP id 9988D3A68E6 for ; Fri, 4 Feb 2011 02:44:05 -0800 (PST) Received: from web25.yandex.ru (web25.yandex.ru [95.108.253.234]) by forward16.mail.yandex.net (Yandex) with ESMTP id 480036C6800D for ; Fri, 4 Feb 2011 13:47:26 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1296816446; bh=s3wbWjnPLrqPWyaGVAkjAXStGtdumioMTcXUp3ZoBrU=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=TAJoGEr5FBeblZMC0xq71QEBao3P7igE1XM8CLRqgGjYV27yZaT0TSzcXkKNV3DW4 moBNpW10uJxLRirCd25u3R91lds8VNaB5HMstsRLtSkw9p8DhErZ3NqGoXMwkJv6/x pQ7RxhRSjrx69+x0+7wZrmS2+vG4osmaks9WtnMA= Received: from localhost (localhost.localdomain [127.0.0.1]) by web25.yandex.ru (Yandex) with ESMTP id 3D8E36BF0015 for ; Fri, 4 Feb 2011 13:47:26 +0300 (MSK) Received: from pptp-dm2008070092.domashka.kiev.ua (pptp-dm2008070092.domashka.kiev.ua [91.203.48.31]) by mail.yandex.ru with HTTP; Fri, 04 Feb 2011 13:47:25 +0300 From: Paul Colomiets Envelope-From: tailhook@yandex.ru To: hybi@ietf.org In-Reply-To: <4D394B51.2060105@ericsson.com> References: <4D394B51.2060105@ericsson.com> MIME-Version: 1.0 Message-Id: <547161296816445@web25.yandex.ru> Date: Fri, 04 Feb 2011 12:47:25 +0200 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 10:44:06 -0000 Hi, I would prefer WEBSOCKET (or maybe other new method), because: 1. It's easier to reason that it's websocket by first few bytes, it's probably important for those serving multiple protocols on single connection, but not real HTTP 2. It's easier to make that pluggable in some servers. If you want to make plugin for OPTIONS, and some other plugin will need to plug into OPTIONS (e.g. WebDAV), the plugin system logic would be much more complicated I world also argue against allowing client to choose method, because probably some lazy server implementors will implement only one used by most browsers, and we will be locked to single method anyway. These points are actually miserable ones, but if most of us thinks method doesn't matter by important reasons, they could be taken in account. -- Paul 21.01.2011, 11:01, "Salvatore Loreto" : > Hi there, > > after the result of the first straw-poll on GET+Upgrade+Masking, > there were a discussion about GET not being the only method to "Upgrade" > the connection; > other methods such as OPTIONS > (http://www.ietf.org/mail-archive/web/hybi/current/msg05721.html) > and perhaps a completely new method could be used (as proposed months ago). > > All the possibilities have pro and cons. > > The mail thread(s) started to discuss the alternatives, > convinced Joe and myself, as HyBi wg co-chairs, that it make sense to > run a straw-poll > to get as much information as we can šfrom people about technical reason > (pro and cons) > for their preference(s). > > So please provide your choices (if more then one, please rank them or if > only one specify > "I can live only with") among the following > > #1 - GET > #2 - OPTIONS > #3 - a complete new method (e.g. WEBSOCKET) > > This poll will run until January 31st > > cheers > /Sal > > -- > Salvatore Loreto > www.sloreto.com > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Paul From ferg@caucho.com Fri Feb 4 09:47:57 2011 Return-Path: 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 995323A69FA for ; Fri, 4 Feb 2011 09:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] 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 WFNy3S1GNwpm for ; Fri, 4 Feb 2011 09:47:56 -0800 (PST) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by core3.amsl.com (Postfix) with SMTP id 193893A69E3 for ; Fri, 4 Feb 2011 09:47:56 -0800 (PST) Received: from [98.139.91.64] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 04 Feb 2011 17:51:19 -0000 Received: from [98.139.91.33] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 04 Feb 2011 17:51:19 -0000 Received: from [127.0.0.1] by omp1033.mail.sp2.yahoo.com with NNFMP; 04 Feb 2011 17:51:19 -0000 X-Yahoo-Newman-Id: 242883.27334.bm@omp1033.mail.sp2.yahoo.com Received: (qmail 76463 invoked from network); 4 Feb 2011 17:51:18 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 04 Feb 2011 09:51:18 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: _cL3PlEVM1loOXv8_dwhKYFmy25EMvwfRIfIV96Bxj6IzCC J0Dhgwsn3rw5f1qnA3h4bxqVIFtF_n6gFPKA1LMbB0jDt1XHTRr7ZisS81HI oRJvBibpH2y9gGW0Ivvm4aLHVNmL2kZOGjpoXW3PfCBheNs8qeoyB4K39Pl9 jZcrzzpe4gzP4oaKfSnJoNRZeGi7GY_DV9KuvoqcKhrZFBWe_dZ7wIRsc7Zr 3xdCHKqQhE364_PBMQZ3c22R.ipIr7nYLICOWVIHvBVmb6DqGNqE9BoVApE2 hU3Hj0.qvxA2cECT3Bodg7p7VvGA9mgg4c2jqdCQRkmNLEnNyJaIeyjws5G_ XOhReApCMad3sSizzx.P3KiZQ8Yutq2k- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4C3C95.2000701@caucho.com> Date: Fri, 04 Feb 2011 09:51:17 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Julian Reschke References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <4D4BD2FB.7060900@gmx.de> In-Reply-To: <4D4BD2FB.7060900@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , "hybi@ietf.org" , Gabriel Montenegro , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:47:57 -0000 Julian Reschke wrote: > On 03.02.2011 20:56, Scott Ferguson wrote: > > I'm not totally convinced that we can't use OPTIONS. > > If we *do* define a new method, we should be clear on its semantics > (independently of Websockets) and other properties (safe, idempotent, > cacheability). > > "UPGRADE" seems to be a poor choice, because what causes the upgrade > is the header, not the method. That's a good point. Paul's point of identifying the protocol by the first bytes is good as well. > > So, if the method really is a No-Op designed just to carry the Upgrade > header, then maybe it should be called "NOP". > > Also note: > > "HTTP methods are generic; that is, they are potentially applicable to > any resource, not just one particular media type, "type" of resource, > or application. As such, it is preferred that new HTTP methods be > registered in a document that isn't specific to a single application, > so that this is clear." -- > > Right, but it's not a media/resource type we're defining. It's an entirely different framing protocol: GET - unidirectional/cacheable (media-typed) byte array using chunked/content-length framing POST - request/response pair of (media-typed) byte arrays using chunked/content-length framing WEBSOCKET - the websocket framing, which is unrelated to either of the above. OPTIONS - entirely different concept (primarily metadata, not framed payload) To Paul's point, if there was a FooBar protocol with a new framing protocol (using upgrade), then it would be logical to have a FOOBAR method. UPGRADE - doesn't identify the framing protocol, but does say that it's not HTTP framing TUNNEL - unframed TCP (I'm okay with any of the above, just putting out why a WEBSOCKET method would make sense.) -- Scott > > (note that's an ID only so the HTTPbis WG is looking for feedback on > this) > > BR, Julian > > > From julian.reschke@gmx.de Fri Feb 4 09:56:27 2011 Return-Path: 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 9CDAD3A6968 for ; Fri, 4 Feb 2011 09:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.157 X-Spam-Level: X-Spam-Status: No, score=-104.157 tagged_above=-999 required=5 tests=[AWL=-1.558, 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 AhW7VfRXwaho for ; Fri, 4 Feb 2011 09:56:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 74FFF3A693C for ; Fri, 4 Feb 2011 09:56:26 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2011 17:59:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.134]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 04 Feb 2011 18:59:50 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18gz8Io7Y8g24P/B7sjI2EwJaYhxiSX5VugJrhilU ImQb35fEjfe04h Message-ID: <4D4C3E90.9010907@gmx.de> Date: Fri, 04 Feb 2011 18:59:44 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Colomiets References: <4D394B51.2060105@ericsson.com> <547161296816445@web25.yandex.ru> In-Reply-To: <547161296816445@web25.yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:56:27 -0000 On 04.02.2011 11:47, Paul Colomiets wrote: > Hi, > > I would prefer WEBSOCKET (or maybe other new method), because: > 1. It's easier to reason that it's websocket by first few bytes, it's probably important > for those serving multiple protocols on single connection, but not real HTTP Wait, you still need to be able to parse the request message properly; otherwise, how do you get the Upgrade header??? > 2. It's easier to make that pluggable in some servers. If you want to make plugin > for OPTIONS, and some other plugin will need to plug into OPTIONS (e.g. WebDAV), > the plugin system logic would be much more complicated On the other hand, by that reasoning, any new protocol we want to upgrade to would require a new method. Not convinced. > ... Best regards, Julian From mcmanus@ducksong.com Fri Feb 4 13:44:43 2011 Return-Path: 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 D7D543A69D4 for ; Fri, 4 Feb 2011 13:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] 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 bt1Hx3WWIZR3 for ; Fri, 4 Feb 2011 13:44:42 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id ABE223A67F2 for ; Fri, 4 Feb 2011 13:44:42 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 1829710305; Fri, 4 Feb 2011 16:48:08 -0500 (EST) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 350BF101F6 for ; Fri, 4 Feb 2011 16:48:03 -0500 (EST) From: "Pat McManus @Mozilla" To: "hybi@ietf.org" In-Reply-To: <4D4C3C95.2000701@caucho.com> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <4D4BD2FB.7060900@gmx.de> <4D4C3C95.2000701@caucho.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 16:48:01 -0500 Message-ID: <1296856081.2403.23.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [hybi] websocket methods - both http and procedural X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:44:43 -0000 Hello All, We are drifting dangerously close to bike shedding with this method discussion. Does anyone feel really strongly that this is important for websockets? I have heard a lot of divergent opinions, but I haven't heard anyone argue that this is really fundamental. I think we're better served by moving the process along - I certainly have preferences but stalemating over this detail is completely not worth effectively stalling interop for WS longer. What do WG members think if we try and refocus and have a draft with the remaining significant undecided issues settled before IETF-80 (probably mid-March to meet submission deadlines)? That revision would probably still not be ready for last call - but maybe it could have just one more editorial iteration to get it there afterwards. The punchlist of outstanding issues of substance is pretty short - I encourage the chairs to share their version but I think the point where the technology was significantly benefiting from lots of discussion and diverse view points (which it definitely has) has passed us by. Not much new is entering the arena. Perhaps we can, once we see the list, have consensus that for expediency resolving the individual items on the list shouldn't all require consensus themselves due to lack of overall impact. -Patrick -- http://www.getfirefox.com/ From Gabriel.Montenegro@microsoft.com Fri Feb 4 13:52:50 2011 Return-Path: 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 906A03A69D3 for ; Fri, 4 Feb 2011 13:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aI61SGzQNUGC for ; Fri, 4 Feb 2011 13:52:49 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 301153A69EE for ; Fri, 4 Feb 2011 13:52:49 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Feb 2011 13:56:10 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 4 Feb 2011 13:56:10 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.102]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 4 Feb 2011 13:56:09 -0800 From: Gabriel Montenegro To: "Pat McManus @Mozilla" , "hybi@ietf.org" Thread-Topic: [hybi] websocket methods - both http and procedural Thread-Index: AQHLxLVKPocZ0r+kIEinW+Ago4v2PJPx4Ysg Date: Fri, 4 Feb 2011 21:56:09 +0000 Message-ID: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <4D4BD2FB.7060900@gmx.de> <4D4C3C95.2000701@caucho.com> <1296856081.2403.23.camel@ds9.ducksong.com> In-Reply-To: <1296856081.2403.23.camel@ds9.ducksong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] websocket methods - both http and procedural X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:52:50 -0000 +1 ! There are other issues (listed in the issue tracker), but none are earth sh= attering, and I agree that neither is this one about the choice of method. = I'd be happy with the status quo of method and moving on. I was expecting rev 05 much sooner. My impression/hope is that it was going= to be available within the next week or so ("early Feb"). Thanks for raising this, Patrick. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of P= at > McManus @Mozilla > Sent: Friday, February 04, 2011 13:48 > To: hybi@ietf.org > Subject: [hybi] websocket methods - both http and procedural >=20 > Hello All, >=20 > We are drifting dangerously close to bike shedding with this method discu= ssion. > Does anyone feel really strongly that this is important for websockets? I= have > heard a lot of divergent opinions, but I haven't heard anyone argue that = this is > really fundamental. I think we're better served by moving the process alo= ng - I > certainly have preferences but stalemating over this detail is completely= not > worth effectively stalling interop for WS longer. >=20 > What do WG members think if we try and refocus and have a draft with the > remaining significant undecided issues settled before IETF-80 (probably m= id- > March to meet submission deadlines)? That revision would probably still n= ot be > ready for last call - but maybe it could have just one more editorial ite= ration to > get it there afterwards. >=20 > The punchlist of outstanding issues of substance is pretty short - I enco= urage the > chairs to share their version but I think the point where the technology = was > significantly benefiting from lots of discussion and diverse view points = (which it > definitely has) has passed us by. Not much new is entering the arena. Per= haps > we can, once we see the list, have consensus that for expediency resolvin= g the > individual items on the list shouldn't all require consensus themselves d= ue to lack > of overall impact. >=20 > -Patrick >=20 > -- > http://www.getfirefox.com/ >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From buskanaka@gmail.com Fri Feb 4 16:15:14 2011 Return-Path: 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 16AEB3A6A37 for ; Fri, 4 Feb 2011 16:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 n2TcLiQHkS5T for ; Fri, 4 Feb 2011 16:15:13 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 1F2BC3A69F7 for ; Fri, 4 Feb 2011 16:15:12 -0800 (PST) Received: by eyd10 with SMTP id 10so1698554eyd.31 for ; Fri, 04 Feb 2011 16:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=pwMTNM9VSFxpWBs/RyaDofcv6eL4hXDyjJqk2vFtZ8o=; b=URpJi6TCtPaijDY538Clrnuz2rRIPMBzCKTx5KCBDgsDwvC2tielk9cK8nc8FJ4VW1 aLgZ2pHcX4Wnh+zuP67V+4xyfza7+8oDyePnSZUsxVJU5UHMhkeauf3IKhQcGhhRsnjq zRuKWZvQkICUxMw/BYmAO+wuZgwqM25YvfLQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=jYjZrTbBFV1QoTZCcX2ANRitsbfEmx9sGo4AqcXIv75v0eSR3jkXcEuODIbdMLWxAt sJWG+C1UC4YAO7wALLvn38G+gburW956213kFvL5bzA9PkUrt7lG9NAGNoLXmEftBP1O cCWxETtabv1ayiiBllrsRenhv300ZwI+Rc71I= Received: by 10.14.11.232 with SMTP id 80mr2341641eex.12.1296865118646; Fri, 04 Feb 2011 16:18:38 -0800 (PST) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.119.136 with HTTP; Fri, 4 Feb 2011 16:18:18 -0800 (PST) In-Reply-To: <4D394B51.2060105@ericsson.com> References: <4D394B51.2060105@ericsson.com> From: Joel Martin Date: Fri, 4 Feb 2011 18:18:18 -0600 X-Google-Sender-Auth: OBpHpCD5oV5rUFQM8PFmPp6Rd5g Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=0016364d20b3b7f333049b7df055 Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 00:15:14 -0000 --0016364d20b3b7f333049b7df055 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 21, 2011 at 3:01 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > > #1 - GET > #2 - OPTIONS > #3 - a complete new method (e.g. WEBSOCKET) > > This poll will run until January 31st > Sal, do we have a count on this since it's officially over? I have feeling that there wasn't general consensus on this straw poll, although I haven't been following the counts closely. I do have the general impression that most people who have expressed an opinion are willing to move forward even if the choice is not their "favorite" and that this isn't a show-stopper for anyone. Joel Martin --0016364d20b3b7f333049b7df055 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 21, 2011 at 3:01 AM, Salva= tore Loreto <salvatore.loreto@ericsson.com> wrote:

#1 - GET
#2 - OPTIONS
#3 - a complete new method (e.g. WEBSOCKET)

This poll will run until January 31st

S= al, do we have a count on this since it's officially over? I have feeli= ng that there wasn't general consensus on this straw poll, although I h= aven't been following the counts closely. I do have the general impress= ion that most people who have expressed an opinion are willing to move forw= ard even if the choice is not their "favorite" and that this isn&= #39;t a show-stopper for anyone.

Joel Martin
--0016364d20b3b7f333049b7df055-- From tailhook@yandex.ru Fri Feb 4 16:27:27 2011 Return-Path: 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 474983A69DC for ; Fri, 4 Feb 2011 16:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.459 X-Spam-Level: X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 yAEu2-QaGGHI for ; Fri, 4 Feb 2011 16:27:24 -0800 (PST) Received: from forward16.mail.yandex.net (forward16.mail.yandex.net [95.108.253.141]) by core3.amsl.com (Postfix) with ESMTP id 5B7F33A67D1 for ; Fri, 4 Feb 2011 16:27:24 -0800 (PST) Received: from web16.yandex.ru (web16.yandex.ru [95.108.252.116]) by forward16.mail.yandex.net (Yandex) with ESMTP id 50A0D23A8283 for ; Sat, 5 Feb 2011 03:30:49 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1296865849; bh=XaABcT8KE0KndVYwnUJbIdVoVKZV6YHi/NU39AqqEAo=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=pG2BjEM5QT9J9fPPx1Ns8iHNV3/eNY3nd/KsqWUThq8byKti0C+WvB2M5CQJWZpU8 tjyg0TA6GCpweoDdwhLsRWmFwlbzfQtfFwGFLd3YszvMwpBgKeb6FbVlxI2+LlC5+V C+ZJQz595OfXGdOHR6OgczI1mYU6fxw8n+E7fOBk= Received: from localhost (localhost.localdomain [127.0.0.1]) by web16.yandex.ru (Yandex) with ESMTP id 09F9E11A8006 for ; Sat, 5 Feb 2011 03:30:48 +0300 (MSK) Received: from pptp-dm2008070092.domashka.kiev.ua (pptp-dm2008070092.domashka.kiev.ua [91.203.48.31]) by mail.yandex.ru with HTTP; Sat, 05 Feb 2011 03:30:48 +0300 From: Paul Colomiets Envelope-From: tailhook@yandex.ru To: hybi@ietf.org In-Reply-To: <4D4C3E90.9010907@gmx.de> References: <4D394B51.2060105@ericsson.com> <547161296816445@web25.yandex.ru> <4D4C3E90.9010907@gmx.de> MIME-Version: 1.0 Message-Id: <772991296865848@web16.yandex.ru> Date: Sat, 05 Feb 2011 02:30:48 +0200 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 00:27:27 -0000 04.02.2011, 19:59, "Julian Reschke" : > On 04.02.2011 11:47, Paul Colomiets wrote: > >> šHi, >> >> šI would prefer WEBSOCKET (or maybe other new method), because: >> ššš1. It's easier to reason that it's websocket by first few bytes, it's probably important >> ššššššfor those serving multiple protocols on single connection, but not real HTTP > > Wait, you still need to be able to parse the request message properly; > otherwise, how do you get the Upgrade header??? Yes, but I can switch to the HTTP protocol parser as fast as I see the first few bytes, and I already know that it's not STOMP or XMLSocket, or XMPP or whatever I should support. Otherwise I should use HTTP parser as a fallback, which is much less clear approach. > >> ššš2. It's easier to make that pluggable in some servers. If you want to make plugin >> ššššššfor OPTIONS, and some other plugin will need to plug into OPTIONS (e.g. WebDAV), >> ššššššthe plugin system logic would be much more complicated > > On the other hand, by that reasoning, any new protocol we want to > upgrade to would require a new method. Not convinced. Not exactly. If we would upgrade to HTTP/2.0 or Waka or whatever for which method name matters we should not. Also if we could get some meaningful answer when server is unable to connect, we should reuse existing method. And all these are not true for websockets. -- Paul From bruce@callenish.com Fri Feb 4 18:33:17 2011 Return-Path: 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 A9BD43A6AC2 for ; Fri, 4 Feb 2011 18:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 B8g7Sm6-uJlx for ; Fri, 4 Feb 2011 18:33:16 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id C257B3A6AC1 for ; Fri, 4 Feb 2011 18:33:16 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PlY0v-0003L7-TJ for hybi@ietf.org; Fri, 04 Feb 2011 18:36:42 -0800 Message-ID: <4D4CB7BD.80309@callenish.com> Date: Fri, 04 Feb 2011 18:36:45 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 02:33:17 -0000 Should the method be something more like MESSAGE or MESSAGING or something similar? Considering that what we are doing is requesting a messaging channel. Purely a bikeshed suggestion, but you have to paint the shed some colour. On 03/02/2011 2:13 PM, Joe Mason wrote: >> -----Original Message----- >> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of >> Willy Tarreau >> >> Also, if we create a new method because we did not find one which >> matches >> our needs, maybe we should be less selfish and not call it WEBSOCKET. >> After >> all, if we're forced to create another new method, it's precisely >> because >> we did not find the perfect one among existing ones. It would be stupid >> that another WG in 5 years has the exact same requirement and has to >> use >> WEBSOCKET for another purpose because of its semantics. What we need is >> just something that upgrades the connection to a tunnel. We could very >> well call it TUNNEL or UPGRADE. At least, the last one clearly implies >> what the method is intended for and other projects will be able to use >> it too. > +1 > > Still not convinced on the need or desirability of a new method, but if we do use one it should be descriptive of what the method does, not what protocol it's used in. > > Joe > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From julian.reschke@gmx.de Sat Feb 5 02:34:41 2011 Return-Path: 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 769BA3A68A8 for ; Sat, 5 Feb 2011 02:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.804 X-Spam-Level: X-Spam-Status: No, score=-103.804 tagged_above=-999 required=5 tests=[AWL=-1.205, 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 1ZXX+BnFZ6Bw for ; Sat, 5 Feb 2011 02:34:40 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 0E2653A68AD for ; Sat, 5 Feb 2011 02:34:39 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2011 10:38:03 -0000 Received: from p508FC73A.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.199.58] by mail.gmx.net (mp058) with SMTP; 05 Feb 2011 11:38:03 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX182bGMrJuY2RDwUAeiD3CKDX76hvIHlLKaCyH9Eto NWeP5FlVqxREtj Message-ID: <4D4D2880.5000607@gmx.de> Date: Sat, 05 Feb 2011 11:37:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Colomiets References: <4D394B51.2060105@ericsson.com> <547161296816445@web25.yandex.ru> <4D4C3E90.9010907@gmx.de> <772991296865848@web16.yandex.ru> In-Reply-To: <772991296865848@web16.yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 10:34:41 -0000 On 05.02.2011 01:30, Paul Colomiets wrote: > > > 04.02.2011, 19:59, "Julian Reschke": >> On 04.02.2011 11:47, Paul Colomiets wrote: >> >>> Hi, >>> >>> I would prefer WEBSOCKET (or maybe other new method), because: >>> 1. It's easier to reason that it's websocket by first few bytes, it's probably important >>> for those serving multiple protocols on single connection, but not real HTTP >> >> Wait, you still need to be able to parse the request message properly; >> otherwise, how do you get the Upgrade header??? > > Yes, but I can switch to the HTTP protocol parser as fast as I see the first few bytes, > and I already know that it's not STOMP or XMLSocket, or XMPP or whatever I should > support. Otherwise I should use HTTP parser as a fallback, which is much less clear > approach. So you'd not use the HTTP parser when the method is unknown. Let's say it's PATCH. What do you do with it instead? >>> 2. It's easier to make that pluggable in some servers. If you want to make plugin >>> for OPTIONS, and some other plugin will need to plug into OPTIONS (e.g. WebDAV), >>> the plugin system logic would be much more complicated >> >> On the other hand, by that reasoning, any new protocol we want to >> upgrade to would require a new method. Not convinced. > Not exactly. If we would upgrade to HTTP/2.0 or Waka or whatever for which method > name matters we should not. Also if we could get some meaningful answer when server > is unable to connect, we should reuse existing method. And all these are not true for > websockets. I'm not sure I understand the distinction. Best regards, Julian From jamie@shareable.org Sat Feb 5 02:47:14 2011 Return-Path: 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 620BE3A69AE for ; Sat, 5 Feb 2011 02:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] 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 9Qlg5PGvhL6Z for ; Sat, 5 Feb 2011 02:47:13 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 870313A68A8 for ; Sat, 5 Feb 2011 02:47:13 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Plfix-0000XG-OV; Sat, 05 Feb 2011 10:50:39 +0000 Date: Sat, 5 Feb 2011 10:50:39 +0000 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110205105039.GA5238@shareable.org> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 10:47:14 -0000 Greg Wilkins wrote: > On 3 February 2011 11:48, Bjoern Hoehrmann wrote: > > * Ian Fette wrote: > > > It's just a straw poll, and the Working Group does not seem to lean in > > any particular direction; that leaves us somewhere between "this does > > not seem to matter much" and "more discussion is needed". > > Which matches perfectly one of the options: Make the handshake work > with any method with a note saying the client should expect a non WS > return if the path and/or server does not support WS. > > Of course the browsers will still have to make a choice of a method, > but they could experiment with a few methods and then choose the best > one without needing to have the servers and intermediaries re > implemented. +1 - I agree. -- Jamie From tailhook@yandex.ru Sat Feb 5 03:37:33 2011 Return-Path: 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 C3D063A68E0 for ; Sat, 5 Feb 2011 03:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 c1aM9aoFvd-O for ; Sat, 5 Feb 2011 03:37:32 -0800 (PST) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by core3.amsl.com (Postfix) with ESMTP id 5A1E63A68A8 for ; Sat, 5 Feb 2011 03:37:31 -0800 (PST) Received: from web47.yandex.ru (web47.yandex.ru [77.88.47.186]) by forward2.mail.yandex.net (Yandex) with ESMTP id 17D3AA80066 for ; Sat, 5 Feb 2011 14:40:58 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1296906058; bh=fH4QQPqoT1WDcc3cU9U+QV832kpfoj9vcMKJiA2vD7E=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=jnS6iPF/NkgdFaBRivxpnb7bMOHrA9msDnOkQXPpJzfXP9tpWQw5AcegnBhPErm9B tZqfLNchnnI2DJHOD9uWFJT+T8wqjMRu+agMsXNekiELagG9Ucn1v4N5AIbo2bYG1A wx/0yjLTSBmEw4BlW8jj7TBXpcqWZ2DXCY6ePDto= Received: from localhost (localhost.localdomain [127.0.0.1]) by web47.yandex.ru (Yandex) with ESMTP id 0C367820059 for ; Sat, 5 Feb 2011 14:40:58 +0300 (MSK) Received: from pptp-dm2008070092.domashka.kiev.ua (pptp-dm2008070092.domashka.kiev.ua [91.203.48.31]) by mail.yandex.ru with HTTP; Sat, 05 Feb 2011 14:40:57 +0300 From: Paul Colomiets Envelope-From: tailhook@yandex.ru To: hybi@ietf.org In-Reply-To: <4D4D2880.5000607@gmx.de> References: <4D394B51.2060105@ericsson.com> <547161296816445@web25.yandex.ru> <4D4C3E90.9010907@gmx.de> <772991296865848@web16.yandex.ru> <4D4D2880.5000607@gmx.de> MIME-Version: 1.0 Message-Id: <296191296906057@web47.yandex.ru> Date: Sat, 05 Feb 2011 13:40:57 +0200 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 11:37:33 -0000 05.02.2011, 12:37, "Julian Reschke" : > On 05.02.2011 01:30, Paul Colomiets wrote: > >> š04.02.2011, 19:59, "Julian Reschke";: >>> šOn 04.02.2011 11:47, Paul Colomiets wrote: >>>> šššHi, >>>> >>>> šššI would prefer WEBSOCKET (or maybe other new method), because: >>>> ššššš1. It's easier to reason that it's websocket by first few bytes, it's probably important >>>> ššššššššfor those serving multiple protocols on single connection, but not real HTTP >>> šWait, you still need to be able to parse the request message properly; >>> šotherwise, how do you get the Upgrade header??? >> šYes, but I can switch to the HTTP protocol parser as fast as I see the first few bytes, >> šand I already know that it's not STOMP or XMLSocket, or XMPP or whatever I should >> šsupport. Otherwise I should use HTTP parser as a fallback, which is much less clear >> šapproach. > > So you'd not use the HTTP parser when the method is unknown. Let's say > it's PATCH. What do you do with it instead? Close connection, since this imaginary server does not work with HTTP. > >>>> ššššš2. It's easier to make that pluggable in some servers. If you want to make plugin >>>> ššššššššfor OPTIONS, and some other plugin will need to plug into OPTIONS (e.g. WebDAV), >>>> ššššššššthe plugin system logic would be much more complicated >>> šOn the other hand, by that reasoning, any new protocol we want to >>> šupgrade to would require a new method. Not convinced. >> šNot exactly. If we would upgrade to HTTP/2.0 or Waka or whatever for which method >> šname matters we should not. Also if we could get some meaningful answer when server >> šis unable to connect, we should reuse existing method. And all these are not true for >> šwebsockets. > > I'm not sure I understand the distinction. Consider somebody invented binary http protocol. And your browser understands it. It issues GET/POST or whatever request in plain-text, requesting upgrade. Then if remote server does not speak http-binary it will send response to this GET or POST. From programmer's point of view, probably backend gives frontend server a resource, and it doesn't matter which protocol frontend will send it to the client, so that backend works on the same protocol whether client support or imaginary http-binary or not. So yes, the new methods should be invented for the new pattern of interaction with server. So probably suggested MESSAGING will be better (UPGRADE or TUNNEL not exacly match this intention) -- Paul From gregw@intalio.com Sun Feb 6 17:38:17 2011 Return-Path: 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 9968B3A6B14 for ; Sun, 6 Feb 2011 17:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 r8OOwuFn0E9J for ; Sun, 6 Feb 2011 17:38:16 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9348F3A6A61 for ; Sun, 6 Feb 2011 17:38:16 -0800 (PST) Received: by vws7 with SMTP id 7so2780167vws.31 for ; Sun, 06 Feb 2011 17:38:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.194.1 with SMTP id dw1mr4069240vcb.179.1297042698937; Sun, 06 Feb 2011 17:38:18 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.98.9 with HTTP; Sun, 6 Feb 2011 17:38:18 -0800 (PST) In-Reply-To: <1296856081.2403.23.camel@ds9.ducksong.com> References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <4D4BD2FB.7060900@gmx.de> <4D4C3C95.2000701@caucho.com> <1296856081.2403.23.camel@ds9.ducksong.com> Date: Mon, 7 Feb 2011 12:38:18 +1100 X-Google-Sender-Auth: oooYoA71uVwSe_UniQ2ecr-kxmE Message-ID: From: Greg Wilkins To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] websocket methods - both http and procedural X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 01:38:17 -0000 +1 For me the main issues outstanding are: 1. masked framing 2. masking as an extension From ifette@google.com Sun Feb 6 22:40:47 2011 Return-Path: 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 2F19B3A6CA1 for ; Sun, 6 Feb 2011 22:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.187 X-Spam-Level: X-Spam-Status: No, score=-104.187 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 GTO5JRXian0J for ; Sun, 6 Feb 2011 22:40:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8429F3A6A11 for ; Sun, 6 Feb 2011 22:40:13 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p176eFJr024486 for ; Sun, 6 Feb 2011 22:40:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1297060816; bh=gFnvpVqjFxAyCX9x1Emr+cw0wO8=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=wwXAH6FKgL66cW2VYtS/r1IN4zdhBUWdShCvqu+zejDuG/g6znprxXtP6mjZ3cwN+ FxJgtDgsoqtPL3dAE3P6Q== Received: from iwc10 (iwc10.prod.google.com [10.241.65.138]) by hpaq1.eem.corp.google.com with ESMTP id p176djrE016085 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Feb 2011 22:40:14 -0800 Received: by iwc10 with SMTP id 10so4464841iwc.17 for ; Sun, 06 Feb 2011 22:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Zu59jqbfCZnD920guG+KZ31I9fsEh2H09crajHyHWBc=; b=j0VG6qZmyzp2+aK5GzFW1yJEwj8Yvt8TdiZdrWF2X++f/Lcaj7alPSIFTLzTp3vaVC Cxv03hV0m+VN7XdymPCg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=a2Kp4tIimEXln0UND1g/x38FJQ1vdPXjd1DX83divtd9ycMMHKpB3VPcS4EFFxFNr8 ORYI04z9pbTVvkJjrbwQ== MIME-Version: 1.0 Received: by 10.231.182.5 with SMTP id ca5mr4358866ibb.144.1297060813661; Sun, 06 Feb 2011 22:40:13 -0800 (PST) Received: by 10.231.13.66 with HTTP; Sun, 6 Feb 2011 22:40:13 -0800 (PST) In-Reply-To: References: <4D394B51.2060105@ericsson.com> <4D43D80B.7010903@gmx.de> <4D498DB8.703@gmx.de> <4D49BA55.3050808@gmx.de> <20110203055827.GB18511@1wt.eu> <4D4B086B.7000901@caucho.com> <4D4BD2FB.7060900@gmx.de> <4D4C3C95.2000701@caucho.com> <1296856081.2403.23.camel@ds9.ducksong.com> Date: Sun, 6 Feb 2011 22:40:13 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=0016367b679a0ce582049bab817c X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] websocket methods - both http and procedural X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 06:40:47 -0000 --0016367b679a0ce582049bab817c Content-Type: text/plain; charset=UTF-8 I was holding off on -05 until getting the consensus call from the chairs on the METHOD. On Fri, Feb 4, 2011 at 1:56 PM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > +1 ! > > There are other issues (listed in the issue tracker), but none are earth > shattering, and I agree that neither is this one about the choice of method. > I'd be happy with the status quo of method and moving on. > > I was expecting rev 05 much sooner. My impression/hope is that it was going > to be available within the next week or so ("early Feb"). > > Thanks for raising this, Patrick. > > > -----Original Message----- > > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Pat > > McManus @Mozilla > > Sent: Friday, February 04, 2011 13:48 > > To: hybi@ietf.org > > Subject: [hybi] websocket methods - both http and procedural > > > > Hello All, > > > > We are drifting dangerously close to bike shedding with this method > discussion. > > Does anyone feel really strongly that this is important for websockets? I > have > > heard a lot of divergent opinions, but I haven't heard anyone argue that > this is > > really fundamental. I think we're better served by moving the process > along - I > > certainly have preferences but stalemating over this detail is completely > not > > worth effectively stalling interop for WS longer. > > > > What do WG members think if we try and refocus and have a draft with the > > remaining significant undecided issues settled before IETF-80 (probably > mid- > > March to meet submission deadlines)? That revision would probably still > not be > > ready for last call - but maybe it could have just one more editorial > iteration to > > get it there afterwards. > > > > The punchlist of outstanding issues of substance is pretty short - I > encourage the > > chairs to share their version but I think the point where the technology > was > > significantly benefiting from lots of discussion and diverse view points > (which it > > definitely has) has passed us by. Not much new is entering the arena. > Perhaps > > we can, once we see the list, have consensus that for expediency > resolving the > > individual items on the list shouldn't all require consensus themselves > due to lack > > of overall impact. > > > > -Patrick > > > > -- > > http://www.getfirefox.com/ > > > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016367b679a0ce582049bab817c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was holding off on -05 until getting the consensus call from the chairs o= n the METHOD.=C2=A0

On Fri, Feb 4, 2011 a= t 1:56 PM, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> wrote:
+1 !

There are other issues (listed in the issue tracker), but none are earth sh= attering, and I agree that neither is this one about the choice of method. = I'd be happy with the status quo of method and moving on.

I was expecting rev 05 much sooner. My impression/hope is that it was going= to be available within the next week or so ("early Feb").

Thanks for raising this, Patrick.

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Pat
> McManus @Mozilla
> Sent: Friday, February 04, 2011 13:48
> To: hybi@ietf.org
> Subject: [hybi] websocket methods - both http and procedural
>
> Hello All,
>
> We are drifting dangerously close to bike shedding with this method di= scussion.
> Does anyone feel really strongly that this is important for websockets= ? I have
> heard a lot of divergent opinions, but I haven't heard anyone argu= e that this is
> really fundamental. I think we're better served by moving the proc= ess along - I
> certainly have preferences but stalemating over this detail is complet= ely not
> worth effectively stalling interop for WS longer.
>
> What do WG members think if we try and refocus and have a draft with t= he
> remaining significant undecided issues settled before IETF-80 (probabl= y mid-
> March to meet submission deadlines)? That revision would probably stil= l not be
> ready for last call - but maybe it could have just one more editorial = iteration to
> get it there afterwards.
>
> The punchlist of outstanding issues of substance is pretty short - I e= ncourage the
> chairs to share their version but I think the point where the technolo= gy was
> significantly benefiting from lots of discussion and diverse view poin= ts (which it
> definitely has) has passed us by. Not much new is entering the arena. = Perhaps
> we can, once we see the list, have consensus that for expediency resol= ving the
> individual items on the list shouldn't all require consensus thems= elves due to lack
> of overall impact.
>
> -Patrick
>
> --
> http://www.ge= tfirefox.com/
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016367b679a0ce582049bab817c-- From salvatore.loreto@ericsson.com Mon Feb 7 02:00:04 2011 Return-Path: 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 7C3023A6D8B for ; Mon, 7 Feb 2011 02:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5Rrhnk0tSDsO for ; Mon, 7 Feb 2011 02:00:03 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3EDF13A6D87 for ; Mon, 7 Feb 2011 02:00:03 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-e8-4d4fc2a68f94 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 36.66.13987.6A2CF4D4; Mon, 7 Feb 2011 11:00:06 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Mon, 7 Feb 2011 11:00:05 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 91F5B2A6F; Mon, 7 Feb 2011 12:00:05 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5C51B5072D; Mon, 7 Feb 2011 12:00:05 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AFB8350679; Mon, 7 Feb 2011 12:00:04 +0200 (EET) Message-ID: <4D4FC2A4.6090204@ericsson.com> Date: Mon, 7 Feb 2011 11:00:04 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Joe Hildebrand , SM Subject: [hybi] considerations on strawpoll GET vs OPTIONS vs new Method X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 10:00:04 -0000 Hi there, Joe and I, as chairs, haven't seen emerging any significant consensus from this straw-poll; so we suggest to move forward with no change of method for the upcoming 05 version, keeping GET as method for the handshake, as its behavior in the WebSocket handshake has been largely tested in the field and it is now well know for better and worse. However we want make clear that the choice of method can change, in a next version, once we have a more clear evidence of the fact that a different method (e.g. OPTIONS or a brand new one) has a better success rate and less side effect that GET Folks interested to promote a different method are invited to work (in parallel) on experimenting and collecting data to share within the HyBi community. At moment we don't have any real data to evaluate the success rate of OPTIONS as well as its actual behavior as method for the handshake while interacting with the deployed intermediaries; moreover the discussion triggered by the strawpoll has let emerge some side effects that folks had not thought before. With respect to defining a completely new method (e.g. WEBSOCKET), including all of the implied semantics, we would need to coordinate with (or delegate to) HTTPbis for the necessary expertise, particularly considering the potential for unexpected behavior from the intermediaries that are having problems with the existing methods. Those interested in working in parallel on defining a new method are invited to produce new I-Ds to describe their ideas; those I-Ds should provide analysis of how the method is likely to deploy in the wild. cheers Sal -- Salvatore Loreto www.sloreto.com From trac@tools.ietf.org Tue Feb 8 08:56:03 2011 Return-Path: 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 24D1D3A67D7 for ; Tue, 8 Feb 2011 08:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 i403bsHSwl1G for ; Tue, 8 Feb 2011 08:56:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 692193A679F for ; Tue, 8 Feb 2011 08:56:02 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmqrE-0003Nf-JJ; Tue, 08 Feb 2011 08:56:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "hybi issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: g_e_montenegro@yahoo.com, ifette@google.com X-Trac-Project: hybi Date: Tue, 08 Feb 2011 16:56:04 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/hybi/trac/ticket/34#comment:2 Message-ID: <072.cae4b5fa90b8568ea20d51061e9a87ee@tools.ietf.org> References: <063.9dad946fb744931897763f85a2d66a89@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <063.9dad946fb744931897763f85a2d66a89@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.com, ifette@google.com, hybi@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: hybi@ietf.org Subject: Re: [hybi] thewebsocketprotocol #34 (closed): Clarify Close processing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:56:03 -0000 #34: Clarify Close processing Changes (by ifette@…): * status: new => closed * resolution: => fixed Comment: I have addressed this in r55 of the protocol in svn, which will be included in -05. -- --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Ticket URL: hybi The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. From trac@tools.ietf.org Tue Feb 8 09:24:24 2011 Return-Path: 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 4E52C3A681A for ; Tue, 8 Feb 2011 09:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 pBRmzS9LS1L8 for ; Tue, 8 Feb 2011 09:24:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 747B03A6818 for ; Tue, 8 Feb 2011 09:24:23 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmrIi-0002KK-8g; Tue, 08 Feb 2011 09:24:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "hybi issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: g_e_montenegro@yahoo.com, ifette@google.com X-Trac-Project: hybi Date: Tue, 08 Feb 2011 17:24:28 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/hybi/trac/ticket/32#comment:2 Message-ID: <072.80e443af066d25046cba634c7f0f596c@tools.ietf.org> References: <063.20025886c0bcb5ccbc9f7e7f1c6e494a@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <063.20025886c0bcb5ccbc9f7e7f1c6e494a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.com, ifette@google.com, hybi@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: hybi@ietf.org Subject: Re: [hybi] thewebsocketprotocol #32 (closed): Clarify use of Origin header X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:24:24 -0000 #32: Clarify use of Origin header Changes (by ifette@…): * status: new => closed * resolution: => fixed Comment: Addressed in r56 in svn, will be included in -5. -- --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------+------------------------------------- Ticket URL: hybi The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. From trac@tools.ietf.org Tue Feb 8 11:29:14 2011 Return-Path: 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 C5A203A680A for ; Tue, 8 Feb 2011 11:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 afSFvlM1dDSR for ; Tue, 8 Feb 2011 11:29:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0BD3D3A67D6 for ; Tue, 8 Feb 2011 11:29:14 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmtFZ-0006bf-AC; Tue, 08 Feb 2011 11:29:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "hybi issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: ifette@google.com X-Trac-Project: hybi Date: Tue, 08 Feb 2011 19:29:21 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/39#comment:1 Message-ID: <077.d634d5b0cd4d9b5b8c98ab033ec56a2b@tools.ietf.org> References: <068.36490524d935945394c51f239c8e5ca3@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <068.36490524d935945394c51f239c8e5ca3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ifette@google.com, hybi@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: hybi@ietf.org Subject: Re: [hybi] thewebsocketprotocol #39 (closed): multiple extensions selection in the server side handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:29:14 -0000 #39: multiple extensions selection in the server side handshake Changes (by ifette@…): * status: new => closed * resolution: => fixed Old description: > the fact that the server can select more then one extension, among the > ones that client has offered, is not clear in the current version (04). > > in order to clarify that, > the following minor change to the text has been proposed by Alexander: > > 1 /extensions/ > 2 A (possibly empty) list representing the protocol-level > 3 extensions the server is ready to use. If the server supports > 4 multiple extensions, then the value of each extension should be > 5 derived from the client's handshake and match exactly one of the > 6 values in the "Sec-WebSocket-Extensions" field. The absence > 7 of such a field is equivalent to the null value. The empty > 8 string is not the same as the null value for these purposes. > > The changes are in lines 4 and 5. > > see: http://www.ietf.org/mail-archive/web/hybi/current/msg05851.html New description: the fact that the server can select more then one extension, among the ones that client has offered, is not clear in the current version (04). in order to clarify that, the following minor change to the text has been proposed by Alexander: 1 /extensions/ 2 A (possibly empty) list representing the protocol-level 3 extensions the server is ready to use. If the server supports 4 multiple extensions, then the value of each extension should be 5 derived from the client's handshake and match exactly one of the 6 values in the "Sec-WebSocket-Extensions" field. The absence 7 of such a field is equivalent to the null value. The empty 8 string is not the same as the null value for these purposes. The changes are in lines 4 and 5. see: http://www.ietf.org/mail-archive/web/hybi/current/msg05851.html -- Comment: Resolved in r58 in svn. will be included in -05 -- -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------------+-------------------------------- Ticket URL: hybi The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. From trac@tools.ietf.org Tue Feb 8 11:31:30 2011 Return-Path: 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 EE52E3A683F for ; Tue, 8 Feb 2011 11:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 65EbLEhufEvb for ; Tue, 8 Feb 2011 11:31:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4FFFF3A680A for ; Tue, 8 Feb 2011 11:31:29 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmtHh-0000T7-AD; Tue, 08 Feb 2011 11:31:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "hybi issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: g_e_montenegro@yahoo.com, ifette@google.com X-Trac-Project: hybi Date: Tue, 08 Feb 2011 19:31:33 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/35#comment:2 Message-ID: <072.5deef7fb505f6b1d50f0d0e8e391388b@tools.ietf.org> References: <063.1eec032ca0db73dba1b467c65224b70a@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <063.1eec032ca0db73dba1b467c65224b70a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.com, ifette@google.com, hybi@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: hybi@ietf.org Subject: Re: [hybi] thewebsocketprotocol #35 (new): Clarify Ping/Pong processing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:31:30 -0000 #35: Clarify Ping/Pong processing Comment(by ifette@…): Resolved in r59 in svn, will be included in -05 -- --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Keywords: --------------------------------------+------------------------------------- Ticket URL: hybi The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. From Internet-Drafts@ietf.org Tue Feb 8 15:15:03 2011 Return-Path: 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 114383A68BD; Tue, 8 Feb 2011 15:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 QpcfbbBNPfZz; Tue, 8 Feb 2011 15:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F95D3A6857; Tue, 8 Feb 2011 15:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208231502.31262.8249.idtracker@localhost> Date: Tue, 08 Feb 2011 15:15:02 -0800 Cc: hybi@ietf.org Subject: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-05.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 23:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. Title : The WebSocket protocol Author(s) : I. Fette Filename : draft-ietf-hybi-thewebsocketprotocol-05.txt Pages : 51 Date : 2011-02-08 The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or