From salvatore.loreto@ericsson.com Fri Jul 2 04:12:09 2010 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 559C13A65A6 for ; Fri, 2 Jul 2010 04:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6zIA-zdJjVfG for ; Fri, 2 Jul 2010 04:12:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D8C653A67E5 for ; Fri, 2 Jul 2010 04:12:00 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-df-4c2dc98bbfa8 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.C3.19600.B89CD2C4; Fri, 2 Jul 2010 13:12:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 13:11:42 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 13:11:42 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AD57026D4; Fri, 2 Jul 2010 14:11:42 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 69EB24F63E; Fri, 2 Jul 2010 14:11:42 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B72D64E647; Fri, 2 Jul 2010 14:11:41 +0300 (EEST) Message-ID: <4C2DC96D.9050908@ericsson.com> Date: Fri, 02 Jul 2010 13:11:41 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------040005020800020209010503" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 02 Jul 2010 11:11:42.0774 (UTC) FILETIME=[59EFC560:01CB19D7] X-Brightmail-Tracker: AAAAAA== Subject: [hybi] HyBi schedule & dinner in Maastricht 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, 02 Jul 2010 11:12:09 -0000 This is a multi-part message in MIME format. --------------040005020800020209010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the HyBi session is scheduled on Friday, July 30, 2010 in the afternoon 1300-1400 Afternoon Session I 0.9 Athens APP hybi BiDirectional or Server-Initiated HTTP WG 1415-1515 Afternoon Session II 0.9 Athens APP hybi BiDirectional or Server-Initiated HTTP WG However, we are trying to organize a dinner earlier in the week to discuss progress, issues, exchange ideas etc. that we can followup on Friday. I have started a doodle to find a suitable day/time : http://www.doodle.com/z2pb5f78fny5zzcc please make your choice!!! best regards Sal -- Salvatore Loreto www.sloreto.com --------------040005020800020209010503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

the HyBi session is scheduled on Friday, July 30, 2010
in the afternoon
1300-1400  Afternoon Session I
0.9 Athens      	APP 	hybi	BiDirectional or Server-Initiated HTTP WG

1415-1515  Afternoon Session II
0.9 Athens      	APP 	hybi	BiDirectional or Server-Initiated HTTP WG


However, we are trying to organize a dinner earlier in the week to discuss progress, issues, exchange ideas etc.
that we can followup on Friday.

I have started a doodle to find a suitable day/time :
http://www.doodle.com/z2pb5f78fny5zzcc

please make your choice!!!



best regards
Sal

--
Salvatore Loreto
www.sloreto.com
--------------040005020800020209010503-- From w@1wt.eu Tue Jul 6 14:00:50 2010 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 BA4FC3A6892 for ; Tue, 6 Jul 2010 14:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 SgpFKEHQIs4s for ; Tue, 6 Jul 2010 14:00:49 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 0586C3A68E7 for ; Tue, 6 Jul 2010 14:00:48 -0700 (PDT) Date: Tue, 6 Jul 2010 23:00:39 +0200 From: Willy Tarreau To: hybi@ietf.org Message-ID: <20100706210039.GA12167@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 06 Jul 2010 21:00:50 -0000 Hi, I was having a private discussion with Ian last week about a recent issue introduced in draft 76, but I realized it would be more useful and constructive to bring the issue to the list than to privately discuss possible fixes. Last week, it was reported to me that a site that was running fine on draft 75 could not get the draft 76 handshake to complete via a HAProxy load balancer, which runs as an HTTP reverse proxy. The connection would remain open between the client and haproxy, and between haproxy and the server, with the server never responding. The same client (Chromium 6.0.414.0) directly connected to the server worked fine. The guy was kind enough to send me some network captures which show an obvious problem : the 8-bytes nonce from the client is not advertised as a content-length, so it is not forwarded by the reverse proxy as it is either part of a next request or pending data for when the handshake completes. Unfortunately, the server wants those bytes to complete the handshake, so we have a dirty deadlock not even detectable by the end user. Ian proposed to upgrade the reverse proxy to detect the WebSocket handshake in the request (before it completes) and that it accepts to forward those 8 bytes. I can't agree with that because until the handshake completes, the proxy does not know whether the server will handle the request as a WS handshake or anything else, and it must absolutely not accept to blindly trust any random client who sets an Upgrade header that any server is free to ignore. Doing so would make the reverse-proxy vulnerable to HTTP request smuggling attacks [1] or even to any type of filtering bypass depending on the length of the data it lets go. Even with 8 bytes it is possible to send a "GET /xx\n" which is a valid HTTP/0.9 request and is accepted by some servers in a keep-alive connection (including Apache). Example : GET /index.html HTTP/1.1 Host: example.com Connection: Upgrade Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 Sec-WebSocket-Protocol: sample Upgrade: WebSocket Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 Origin: http://example.com GET /.. If the server does not handle WebSocket for this ressource, it will happily return the index and/or a 404 and proceed with next request contained in the 8 bytes it received. Conversely, having no Content-Length header in the request means that we don't know what a reverse proxy will do if it receives a valid one. For instance, we could very well imagine that some reverse proxies which will assume that Content-Length == 8 for any request containing "Upgrade: WebSocket" will have trouble when receiving a different Content-Length header. This could be used to pass larger amounts of data than what is allowed by the protocol to a second reverse-proxy, which, if it is able to parallelize pipelined requests, will forward the first one to the server and the second one (embedded in the apparent data) to another server. The first obvious solution that comes to mind is to comply with the HTTP protocol which will be implemented along the whole chain and to simply add a "Content-Length: 8" header in the request. This fixes the dirty hang, this fixes the fact that reverse proxies have to blindly trust the client, this fixes the case with the different content length, and it even makes it possible for WebSocket aware reverse proxies to refuse requests which don't have exactly "Content-Length: 8". But this raises a second point : shouldn't we switch to POST instead of GET then ? After all, GET + content-length is not well defined, httpbis p1 says : The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's header fields. When a request message contains both a message-body of non-zero length and a method that does not define any semantics for that request message-body, then an origin server SHOULD either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented the same request, SHOULD either forward the request inbound with the message- body or ignore the message-body when determining a response. So that means that we're not certain again that the data will pass through all reverse proxies. That said, we could consider that WebSocket aware reverse proxies will let the data flow, but the problem of the hung connection remains if the reverse proxy eats the data before forwarding to the server. The POST solves all that. POST + content-length is normal and well supported everywhere. The POST also has the nice advantage that we're sure we won't get a reply from a cache (and the POST method is even one of the 3 defined methods which must invalidate caches). The POST also has a nice advantage for various client implementations that it is easier to implement than GET with some data. After some thinking, I'm wondering why we want to pass the nonce as data in the request instead of passing it as headers. After all, we're interested in data in the response to ensure we're able to let data flow and that the whole chain understands the Upgrade request. In fact, if any one intermediate ignores the 101 and takes it as a 100 (as is explicitly permitted by httpbis-p2), the response will be aborted because the pending data does not look like an HTTP response, and this is perfect, it's what we're looking for. But in the request ? I fail to see the added value of having it in the data. Probably that it would be easier to put it in a header and keep the GET. Anyway, we have to do something now because we've reached the point Ian tried to ensure we would avoid a long time ago : the deadlock which is undetectable by the client. And it already happens through a common reverse proxy since draft 76, and will do through load balancers, IDS and HTTP-aware firewalls for the same reasons, without any simple way to fix it without breaking HTTP security on those components. And it's not like if we could imagine those components will not be in use where WebSocket is deployed ! Best regards, Willy [1] http://www.owasp.org/index.php/HTTP_Request_Smuggling From gregw@webtide.com Tue Jul 6 16:14:33 2010 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 045513A68FB for ; Tue, 6 Jul 2010 16:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 gg9hiB3hRQQK for ; Tue, 6 Jul 2010 16:14:28 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1A5EC3A67B2 for ; Tue, 6 Jul 2010 16:14:27 -0700 (PDT) Received: by fxm1 with SMTP id 1so5552261fxm.31 for ; Tue, 06 Jul 2010 16:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.120.205 with SMTP id e13mr5064990far.5.1278458067442; Tue, 06 Jul 2010 16:14:27 -0700 (PDT) Received: by 10.223.119.140 with HTTP; Tue, 6 Jul 2010 16:14:27 -0700 (PDT) In-Reply-To: <20100706210039.GA12167@1wt.eu> References: <20100706210039.GA12167@1wt.eu> Date: Wed, 7 Jul 2010 09:14:27 +1000 Message-ID: From: Greg Wilkins To: Willy Tarreau Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 06 Jul 2010 23:14:33 -0000 Willy thanks for giving a real world example to the problems of non HTTP compatibility that were predicted to occur if -76 was adopted. My understanding is that the nonce is sent as a non-HTTP non-Websocket data packet precisely to detect if there is an intermediary that cannot handle websocket - and thus fail fast. Your example show that this mechanism is neither a good test for websocket capability, nor does it actually fail fast. I believe HAproxy is a load balancer that will handle the first HTTP Request/Response on a connection as HTTP, before turning into a byte forwarding pipe. Such a proxy will work fine with websocket if the handshake is compliant HTTP, but fails on -76 because it is not compliant. The proposal that I have made several times on this list is that the handshake should include the nonce as a header. The 16 byte check code can be sent as non-HTTP data after the 101, as there is no longer a requirement to be HTTP then - however I think that if we wish to test websocket capability, it would be far better to send that in a websocket frame: Send: GET /index.html HTTP/1.1 Host: example.com Connection: Upgrade Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 Sec-WebSocket-Nonce: 4ABC2FEE237CD165 Sec-WebSocket-Protocol: sample Upgrade: WebSocket Origin: http://example.com Receive: HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Location: ws://example.com/demo Sec-WebSocket-Protocol: sample 0x81 0x10 <16 bytes> Only after the 16 byte binary websocket frame is received and validated should the client trigger the onOpen handling. This handshake is compliant HTTP and includes a check of websocket capability server to client without an extra round trip. The only think it lacks is a check of client to server websocket capability, but: a) we can see the current -76 check doesn't work anyway b) all the intermediaries say the upgrade request and 101 response, so they had the opportunity to refuse the upgrade c) it would be easy to add a client to server websocket keep-alive send after the handshake that would check that path. If server could timeout the connection if a no message is received within a reasonable timeout. To check connectivity there is no way to avoid having such a timeout since you can't test for something not being received any other way... at least this way, the message could actually be a real application message and thus a useful message and not another round trip. But all this has been said before and ignored by the editor, who wont even remove the inappropriate redirection in the intro of http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-00.txt so don't hold your breath waiting for good sense or good process to prevail. Sorry for the sour grapes... but I don't know what else to say. regards On 7 July 2010 07:00, Willy Tarreau wrote: > Hi, > > I was having a private discussion with Ian last week about a recent > issue introduced in draft 76, but I realized it would be more useful > and constructive to bring the issue to the list than to privately > discuss possible fixes. > > Last week, it was reported to me that a site that was running fine > on draft 75 could not get the draft 76 handshake to complete via a > HAProxy load balancer, which runs as an HTTP reverse proxy. The > connection would remain open between the client and haproxy, and > between haproxy and the server, with the server never responding. > The same client (Chromium 6.0.414.0) directly connected to the > server worked fine. > > The guy was kind enough to send me some network captures which show > an obvious problem : the 8-bytes nonce from the client is not advertised > as a content-length, so it is not forwarded by the reverse proxy as > it is either part of a next request or pending data for when the > handshake completes. Unfortunately, the server wants those bytes to > complete the handshake, so we have a dirty deadlock not even detectable > by the end user. > > Ian proposed to upgrade the reverse proxy to detect the WebSocket > handshake in the request (before it completes) and that it accepts > to forward those 8 bytes. > > I can't agree with that because until the handshake completes, the > proxy does not know whether the server will handle the request as > a WS handshake or anything else, and it must absolutely not accept > to blindly trust any random client who sets an Upgrade header that > any server is free to ignore. Doing so would make the reverse-proxy > vulnerable to HTTP request smuggling attacks [1] or even to any type > of filtering bypass depending on the length of the data it lets go. > Even with 8 bytes it is possible to send a "GET /xx\n" which is a > valid HTTP/0.9 request and is accepted by some servers in a keep-alive > connection (including Apache). > > Example : > > =C2=A0 =C2=A0 =C2=A0 =C2=A0GET /index.html HTTP/1.1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Host: example.com > =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection: Upgrade > =C2=A0 =C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Key2: 12998 5 Y3 1 =C2=A0.P00 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Protocol: sample > =C2=A0 =C2=A0 =C2=A0 =C2=A0Upgrade: WebSocket > =C2=A0 =C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Key1: 4 @1 =C2=A046546xW%0l 1 5 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Origin: http://example.com > > =C2=A0 =C2=A0 =C2=A0 =C2=A0GET /.. > > If the server does not handle WebSocket for this ressource, it will > happily return the index and/or a 404 and proceed with next request > contained in the 8 bytes it received. > > Conversely, having no Content-Length header in the request means that > we don't know what a reverse proxy will do if it receives a valid one. > For instance, we could very well imagine that some reverse proxies > which will assume that Content-Length =3D=3D 8 for any request containing > "Upgrade: WebSocket" will have trouble when receiving a different > Content-Length header. This could be used to pass larger amounts of > data than what is allowed by the protocol to a second reverse-proxy, > which, if it is able to parallelize pipelined requests, will forward > the first one to the server and the second one (embedded in the apparent > data) to another server. > > The first obvious solution that comes to mind is to comply with the > HTTP protocol which will be implemented along the whole chain and to > simply add a "Content-Length: 8" header in the request. This fixes > the dirty hang, this fixes the fact that reverse proxies have to blindly > trust the client, this fixes the case with the different content length, > and it even makes it possible for WebSocket aware reverse proxies to > refuse requests which don't have exactly "Content-Length: 8". > > But this raises a second point : shouldn't we switch to POST instead of > GET then ? After all, GET + content-length is not well defined, httpbis > p1 says : > > =C2=A0 The presence of a message-body in a request is signaled by the > =C2=A0 inclusion of a Content-Length or Transfer-Encoding header field in > =C2=A0 the request's header fields. =C2=A0When a request message contains= both a > =C2=A0 message-body of non-zero length and a method that does not define = any > =C2=A0 semantics for that request message-body, then an origin server SHO= ULD > =C2=A0 either ignore the message-body or respond with an appropriate erro= r > =C2=A0 message (e.g., 413). =C2=A0A proxy or gateway, when presented the = same > =C2=A0 request, SHOULD either forward the request inbound with the messag= e- > =C2=A0 body or ignore the message-body when determining a response. > > So that means that we're not certain again that the data will pass > through all reverse proxies. That said, we could consider that WebSocket > aware reverse proxies will let the data flow, but the problem of the hung > connection remains if the reverse proxy eats the data before forwarding > to the server. > > The POST solves all that. POST + content-length is normal and well > supported everywhere. The POST also has the nice advantage that we're > sure we won't get a reply from a cache (and the POST method is even > one of the 3 defined methods which must invalidate caches). > > The POST also has a nice advantage for various client implementations > that it is easier to implement than GET with some data. > > After some thinking, I'm wondering why we want to pass the nonce as > data in the request instead of passing it as headers. After all, we're > interested in data in the response to ensure we're able to let data > flow and that the whole chain understands the Upgrade request. In fact, > if any one intermediate ignores the 101 and takes it as a 100 (as is > explicitly permitted by httpbis-p2), the response will be aborted > because the pending data does not look like an HTTP response, and this > is perfect, it's what we're looking for. But in the request ? I fail > to see the added value of having it in the data. Probably that it would > be easier to put it in a header and keep the GET. > > Anyway, we have to do something now because we've reached the point Ian > tried to ensure we would avoid a long time ago : the deadlock which is > undetectable by the client. And it already happens through a common > reverse proxy since draft 76, and will do through load balancers, IDS > and HTTP-aware firewalls for the same reasons, without any simple way > to fix it without breaking HTTP security on those components. And it's > not like if we could imagine those components will not be in use where > WebSocket is deployed ! > > Best regards, > Willy > > [1] =C2=A0 http://www.owasp.org/index.php/HTTP_Request_Smuggling > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From micheil@brandedcode.com Tue Jul 6 19:44:44 2010 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 5B62E3A6974 for ; Tue, 6 Jul 2010 19:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 KMLtFcwGo+BD for ; Tue, 6 Jul 2010 19:44:41 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 4B2653A6967 for ; Tue, 6 Jul 2010 19:44:40 -0700 (PDT) Received: by pwj1 with SMTP id 1so1728138pwj.31 for ; Tue, 06 Jul 2010 19:44:40 -0700 (PDT) Received: by 10.142.142.1 with SMTP id p1mr6645696wfd.10.1278470680732; Tue, 06 Jul 2010 19:44:40 -0700 (PDT) Received: from [192.168.46.181] (124-170-233-189.dyn.iinet.net.au [124.170.233.189]) by mx.google.com with ESMTPS id l40sm6599198rvb.6.2010.07.06.19.44.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 19:44:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Micheil Smith In-Reply-To: <20100706210039.GA12167@1wt.eu> Date: Wed, 7 Jul 2010 12:44:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100706210039.GA12167@1wt.eu> To: hybi@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 02:44:44 -0000 Willy, Thanks for raising this point. I'm an author of a node.js powered = websocket=20 server, and this was actually a really awkward part of the websocket = spec to=20 comply to when writing my server. Without having a content-length header, the http parser in node doesn't = know=20 how to handle the extra data it receives in that initial handshake. What = we=20 ended up doing as a fix, was just to provide an upgradeHead as a slice = of the buffer from where the headers ended to the end of the packet. In short, I'd be all for having a content-length header sent to declare = the body=20 as a body, or to declare it as just extra data that should be handled = post upgrade. =46rom what I can tell from what Ian is telling me over irc, he'd be = more inclined to=20 add in content-length: 0 as a header, then content-length: 8. Hopefully this reply does make somewhat sense.=20 Yours, Micheil Smith -- BrandedCode.com ps: I'm hoping this does actually reply to the mailing list, rather then = the individual. On 07/07/2010, at 7:00 AM, Willy Tarreau wrote: > Hi, >=20 > I was having a private discussion with Ian last week about a recent > issue introduced in draft 76, but I realized it would be more useful > and constructive to bring the issue to the list than to privately > discuss possible fixes. >=20 > Last week, it was reported to me that a site that was running fine > on draft 75 could not get the draft 76 handshake to complete via a > HAProxy load balancer, which runs as an HTTP reverse proxy. The > connection would remain open between the client and haproxy, and > between haproxy and the server, with the server never responding. > The same client (Chromium 6.0.414.0) directly connected to the > server worked fine. >=20 > The guy was kind enough to send me some network captures which show > an obvious problem : the 8-bytes nonce from the client is not = advertised > as a content-length, so it is not forwarded by the reverse proxy as > it is either part of a next request or pending data for when the > handshake completes. Unfortunately, the server wants those bytes to > complete the handshake, so we have a dirty deadlock not even = detectable > by the end user. >=20 > Ian proposed to upgrade the reverse proxy to detect the WebSocket > handshake in the request (before it completes) and that it accepts > to forward those 8 bytes. >=20 > I can't agree with that because until the handshake completes, the > proxy does not know whether the server will handle the request as > a WS handshake or anything else, and it must absolutely not accept > to blindly trust any random client who sets an Upgrade header that > any server is free to ignore. Doing so would make the reverse-proxy > vulnerable to HTTP request smuggling attacks [1] or even to any type > of filtering bypass depending on the length of the data it lets go. > Even with 8 bytes it is possible to send a "GET /xx\n" which is a > valid HTTP/0.9 request and is accepted by some servers in a keep-alive > connection (including Apache). >=20 > Example : >=20 > GET /index.html HTTP/1.1 > Host: example.com > Connection: Upgrade > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 > Sec-WebSocket-Protocol: sample > Upgrade: WebSocket > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 > Origin: http://example.com >=20 > GET /.. >=20 > If the server does not handle WebSocket for this ressource, it will > happily return the index and/or a 404 and proceed with next request > contained in the 8 bytes it received. >=20 > Conversely, having no Content-Length header in the request means that > we don't know what a reverse proxy will do if it receives a valid one. > For instance, we could very well imagine that some reverse proxies > which will assume that Content-Length =3D=3D 8 for any request = containing > "Upgrade: WebSocket" will have trouble when receiving a different > Content-Length header. This could be used to pass larger amounts of > data than what is allowed by the protocol to a second reverse-proxy, > which, if it is able to parallelize pipelined requests, will forward > the first one to the server and the second one (embedded in the = apparent > data) to another server. >=20 > The first obvious solution that comes to mind is to comply with the > HTTP protocol which will be implemented along the whole chain and to > simply add a "Content-Length: 8" header in the request. This fixes > the dirty hang, this fixes the fact that reverse proxies have to = blindly > trust the client, this fixes the case with the different content = length, > and it even makes it possible for WebSocket aware reverse proxies to > refuse requests which don't have exactly "Content-Length: 8". >=20 > But this raises a second point : shouldn't we switch to POST instead = of > GET then ? After all, GET + content-length is not well defined, = httpbis > p1 says : >=20 > The presence of a message-body in a request is signaled by the > inclusion of a Content-Length or Transfer-Encoding header field in > the request's header fields. When a request message contains both a > message-body of non-zero length and a method that does not define any > semantics for that request message-body, then an origin server SHOULD > either ignore the message-body or respond with an appropriate error > message (e.g., 413). A proxy or gateway, when presented the same > request, SHOULD either forward the request inbound with the message- > body or ignore the message-body when determining a response. >=20 > So that means that we're not certain again that the data will pass > through all reverse proxies. That said, we could consider that = WebSocket > aware reverse proxies will let the data flow, but the problem of the = hung > connection remains if the reverse proxy eats the data before = forwarding > to the server. >=20 > The POST solves all that. POST + content-length is normal and well > supported everywhere. The POST also has the nice advantage that we're > sure we won't get a reply from a cache (and the POST method is even > one of the 3 defined methods which must invalidate caches). >=20 > The POST also has a nice advantage for various client implementations > that it is easier to implement than GET with some data. >=20 > After some thinking, I'm wondering why we want to pass the nonce as > data in the request instead of passing it as headers. After all, we're > interested in data in the response to ensure we're able to let data > flow and that the whole chain understands the Upgrade request. In = fact, > if any one intermediate ignores the 101 and takes it as a 100 (as is > explicitly permitted by httpbis-p2), the response will be aborted > because the pending data does not look like an HTTP response, and this > is perfect, it's what we're looking for. But in the request ? I fail > to see the added value of having it in the data. Probably that it = would > be easier to put it in a header and keep the GET. >=20 > Anyway, we have to do something now because we've reached the point = Ian > tried to ensure we would avoid a long time ago : the deadlock which is > undetectable by the client. And it already happens through a common > reverse proxy since draft 76, and will do through load balancers, IDS > and HTTP-aware firewalls for the same reasons, without any simple way > to fix it without breaking HTTP security on those components. And it's > not like if we could imagine those components will not be in use where > WebSocket is deployed ! >=20 > Best regards, > Willy >=20 > [1] http://www.owasp.org/index.php/HTTP_Request_Smuggling >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi Micheil Smith -- BrandedCode.com On 07/07/2010, at 7:00 AM, Willy Tarreau wrote: > Hi, >=20 > I was having a private discussion with Ian last week about a recent > issue introduced in draft 76, but I realized it would be more useful > and constructive to bring the issue to the list than to privately > discuss possible fixes. >=20 > Last week, it was reported to me that a site that was running fine > on draft 75 could not get the draft 76 handshake to complete via a > HAProxy load balancer, which runs as an HTTP reverse proxy. The > connection would remain open between the client and haproxy, and > between haproxy and the server, with the server never responding. > The same client (Chromium 6.0.414.0) directly connected to the > server worked fine. >=20 > The guy was kind enough to send me some network captures which show > an obvious problem : the 8-bytes nonce from the client is not = advertised > as a content-length, so it is not forwarded by the reverse proxy as > it is either part of a next request or pending data for when the > handshake completes. Unfortunately, the server wants those bytes to > complete the handshake, so we have a dirty deadlock not even = detectable > by the end user. >=20 > Ian proposed to upgrade the reverse proxy to detect the WebSocket > handshake in the request (before it completes) and that it accepts > to forward those 8 bytes. >=20 > I can't agree with that because until the handshake completes, the > proxy does not know whether the server will handle the request as > a WS handshake or anything else, and it must absolutely not accept > to blindly trust any random client who sets an Upgrade header that > any server is free to ignore. Doing so would make the reverse-proxy > vulnerable to HTTP request smuggling attacks [1] or even to any type > of filtering bypass depending on the length of the data it lets go. > Even with 8 bytes it is possible to send a "GET /xx\n" which is a > valid HTTP/0.9 request and is accepted by some servers in a keep-alive > connection (including Apache). >=20 > Example : >=20 > GET /index.html HTTP/1.1 > Host: example.com > Connection: Upgrade > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 > Sec-WebSocket-Protocol: sample > Upgrade: WebSocket > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 > Origin: http://example.com >=20 > GET /.. >=20 > If the server does not handle WebSocket for this ressource, it will > happily return the index and/or a 404 and proceed with next request > contained in the 8 bytes it received. >=20 > Conversely, having no Content-Length header in the request means that > we don't know what a reverse proxy will do if it receives a valid one. > For instance, we could very well imagine that some reverse proxies > which will assume that Content-Length =3D=3D 8 for any request = containing > "Upgrade: WebSocket" will have trouble when receiving a different > Content-Length header. This could be used to pass larger amounts of > data than what is allowed by the protocol to a second reverse-proxy, > which, if it is able to parallelize pipelined requests, will forward > the first one to the server and the second one (embedded in the = apparent > data) to another server. >=20 > The first obvious solution that comes to mind is to comply with the > HTTP protocol which will be implemented along the whole chain and to > simply add a "Content-Length: 8" header in the request. This fixes > the dirty hang, this fixes the fact that reverse proxies have to = blindly > trust the client, this fixes the case with the different content = length, > and it even makes it possible for WebSocket aware reverse proxies to > refuse requests which don't have exactly "Content-Length: 8". >=20 > But this raises a second point : shouldn't we switch to POST instead = of > GET then ? After all, GET + content-length is not well defined, = httpbis > p1 says : >=20 > The presence of a message-body in a request is signaled by the > inclusion of a Content-Length or Transfer-Encoding header field in > the request's header fields. When a request message contains both a > message-body of non-zero length and a method that does not define = any > semantics for that request message-body, then an origin server = SHOULD > either ignore the message-body or respond with an appropriate error > message (e.g., 413). A proxy or gateway, when presented the same > request, SHOULD either forward the request inbound with the message- > body or ignore the message-body when determining a response. >=20 > So that means that we're not certain again that the data will pass > through all reverse proxies. That said, we could consider that = WebSocket > aware reverse proxies will let the data flow, but the problem of the = hung > connection remains if the reverse proxy eats the data before = forwarding > to the server. >=20 > The POST solves all that. POST + content-length is normal and well > supported everywhere. The POST also has the nice advantage that we're > sure we won't get a reply from a cache (and the POST method is even > one of the 3 defined methods which must invalidate caches). >=20 > The POST also has a nice advantage for various client implementations > that it is easier to implement than GET with some data. >=20 > After some thinking, I'm wondering why we want to pass the nonce as > data in the request instead of passing it as headers. After all, we're > interested in data in the response to ensure we're able to let data > flow and that the whole chain understands the Upgrade request. In = fact, > if any one intermediate ignores the 101 and takes it as a 100 (as is > explicitly permitted by httpbis-p2), the response will be aborted > because the pending data does not look like an HTTP response, and this > is perfect, it's what we're looking for. But in the request ? I fail > to see the added value of having it in the data. Probably that it = would > be easier to put it in a header and keep the GET. >=20 > Anyway, we have to do something now because we've reached the point = Ian > tried to ensure we would avoid a long time ago : the deadlock which is > undetectable by the client. And it already happens through a common > reverse proxy since draft 76, and will do through load balancers, IDS > and HTTP-aware firewalls for the same reasons, without any simple way > to fix it without breaking HTTP security on those components. And it's > not like if we could imagine those components will not be in use where > WebSocket is deployed ! >=20 > Best regards, > Willy >=20 > [1] http://www.owasp.org/index.php/HTTP_Request_Smuggling >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From w@1wt.eu Tue Jul 6 21:41:35 2010 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 E30E33A6957 for ; Tue, 6 Jul 2010 21:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-1.583, BAYES_05=-1.11, 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 4Es-AxHEDN0l for ; Tue, 6 Jul 2010 21:41:34 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 96F263A67CC for ; Tue, 6 Jul 2010 21:41:32 -0700 (PDT) Date: Wed, 7 Jul 2010 06:41:29 +0200 From: Willy Tarreau To: Micheil Smith Message-ID: <20100707044129.GH12126@1wt.eu> References: <20100706210039.GA12167@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 04:41:36 -0000 On Wed, Jul 07, 2010 at 12:44:32PM +1000, Micheil Smith wrote: > Willy, > > Thanks for raising this point. I'm an author of a node.js powered websocket > server, and this was actually a really awkward part of the websocket spec to > comply to when writing my server. > > Without having a content-length header, the http parser in node doesn't know > how to handle the extra data it receives in that initial handshake. What we > ended up doing as a fix, was just to provide an upgradeHead as a slice of the > buffer from where the headers ended to the end of the packet. > > In short, I'd be all for having a content-length header sent to declare the body > as a body, or to declare it as just extra data that should be handled post upgrade. > >From what I can tell from what Ian is telling me over irc, he'd be more inclined to > add in content-length: 0 as a header, then content-length: 8. > > Hopefully this reply does make somewhat sense. Content-length: 0 also makes sense but it means that the nonce will be sent *after* the handshake, which means we'd have a second round-trip. For some sites who deal with hundreds of thousands of concurrent connections (and I know some), having two more packets in a connectionn is an unneeded increase of network traffic. For this reason, I think that the idea of the nonce in the request header is good. However, I think that having content-length: 0 in the *response* will definitely help eliminating incompatible intermediates : those who properly support 101 will forward the data regardless of the content length because the tunnel is established. Those who don't completely support 101 will stop at the content-length and not forward the response. Alternatively, it might be nice to use a transfer-encoding: chunked in the response with only an end of chunk ("0\r\n") before the nonce. That would permit the client to check if it receives only the "0\r\n" or if it receives the nonce too. An increased check could also consist in setting "Connection: close" in the response in addition with the transfer-encoding or content-length. That way, incompatible intermediates won't remain open waiting for anything and will quickly close the connection before the part they don't support. Regards, Willy From w@1wt.eu Tue Jul 6 21:55:26 2010 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 C6CD93A6407 for ; Tue, 6 Jul 2010 21:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_50=0.001, 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 xguzRjEYxv8S for ; Tue, 6 Jul 2010 21:55:25 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 7D83A3A6869 for ; Tue, 6 Jul 2010 21:55:24 -0700 (PDT) Date: Wed, 7 Jul 2010 06:55:26 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100707045526.GI12126@1wt.eu> References: <20100706210039.GA12167@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 04:55:26 -0000 On Wed, Jul 07, 2010 at 09:14:27AM +1000, Greg Wilkins wrote: > Willy > > thanks for giving a real world example to the problems of non HTTP > compatibility that were predicted to occur if -76 was adopted. In fact, I'd say that it's often hard to predict the risk of breakage before observing it, the only thing we know is that if we respect what others understand, the risk is low and that if we patently ignore standards, the risk is high. > My understanding is that the nonce is sent as a non-HTTP non-Websocket > data packet precisely to detect if there is an intermediary that > cannot handle websocket - and thus fail fast. That's what I understood too and it is inefficient. > Your example show that > this mechanism is neither a good test for websocket capability, nor > does it actually fail fast. I believe HAproxy is a load balancer that > will handle the first HTTP Request/Response on a connection as HTTP, > before turning into a byte forwarding pipe. yes, it now properly handles the 101, which means that it becomes a pipe once it sees the 101 in the response (once the handshake completes). So there is no way it will send unadvertised data before the server is OK with receiving them. > Such a proxy will work > fine with websocket if the handshake is compliant HTTP, but fails on > -76 because it is not compliant. exactly. > The proposal that I have made several times on this list is that the > handshake should include the nonce as a header. The 16 byte check > code can be sent as non-HTTP data after the 101, as there is no longer > a requirement to be HTTP then - however I think that if we wish to > test websocket capability, it would be far better to send that in a > websocket frame: Yes, that's what I think would be the cleaner (and the last proposal in my mail too). > Send: > > GET /index.html HTTP/1.1 > Host: example.com > Connection: Upgrade > Sec-WebSocket-Key1: 4 @1 46546xW%0l 1 5 > Sec-WebSocket-Key2: 12998 5 Y3 1 .P00 > Sec-WebSocket-Nonce: 4ABC2FEE237CD165 > Sec-WebSocket-Protocol: sample > Upgrade: WebSocket > Origin: http://example.com > > Receive: > > HTTP/1.1 101 WebSocket Protocol Handshake > Upgrade: WebSocket > Connection: Upgrade > Sec-WebSocket-Origin: http://example.com > Sec-WebSocket-Location: ws://example.com/demo > Sec-WebSocket-Protocol: sample > > 0x81 0x10 <16 bytes> > > > Only after the 16 byte binary websocket frame is received and > validated should the client trigger the onOpen handling. This > handshake is compliant HTTP and includes a check of websocket > capability server to client without an extra round trip. And it's also how TLS is supposed to work over HTTP/1.1 since May 2000 ! > The only > think it lacks is a check of client to server websocket capability, > but: > a) we can see the current -76 check doesn't work anyway > b) all the intermediaries say the upgrade request and 101 response, > so they had the opportunity to refuse the upgrade > c) it would be easy to add a client to server websocket keep-alive > send after the handshake that would check that path. If server could > timeout the connection if a no message is received within a reasonable > timeout. To check connectivity there is no way to avoid having such a > timeout since you can't test for something not being received any > other way... at least this way, the message could actually be a real > application message and thus a useful message and not another round > trip. In my opinion, it is not a problem because if an intermediate does not understand the 101, the response data will not be sent to the client (and we may have to ensure a bit more that those data can't be sent, eg with content-length 0 in the response, and connection: close). If those data flow to the client, then it must mean that the pipe is established. I'm now thinking we could even further strengthen the handshake via non compliant intermediates by adding connection: close in both directions. This will make incompatible reverse proxies fail the earliest possible, without breaking compatibility with the protocols implemented on the components which transport the handshake. Regards, Willy From fenix@google.com Tue Jul 6 22:13:30 2010 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 3D7983A6858 for ; Tue, 6 Jul 2010 22:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 db3AC+3XrVES for ; Tue, 6 Jul 2010 22:13:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 47A8F3A683C for ; Tue, 6 Jul 2010 22:13:15 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o675DGLO024201 for ; Tue, 6 Jul 2010 22:13:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1278479597; bh=NkzlzLNmCPM7OR9asbIHZHlxWis=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hr7YpDNUgv8miGEKDErhWEiIF3C2L3Wz1tnEHvJEAvAmx1cLx77K2G3qwl8cqbnVN EZbQ7RtAHvAbZv8HN8ndg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=k/viFTHgsSPYTkfSl6YXoqEbaN/6yqflbkTIsR8rue27KDCRTCriPfyhEifxMRx09 XwZqQDQu20vn/cU9H1U/w== Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by wpaz24.hot.corp.google.com with ESMTP id o675DF3M015137 for ; Tue, 6 Jul 2010 22:13:15 -0700 Received: by gxk28 with SMTP id 28so1783294gxk.40 for ; Tue, 06 Jul 2010 22:13:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.82.9 with SMTP id f9mr3316215agb.124.1278479595430; Tue, 06 Jul 2010 22:13:15 -0700 (PDT) Received: by 10.150.66.12 with HTTP; Tue, 6 Jul 2010 22:13:15 -0700 (PDT) In-Reply-To: <20100707044129.GH12126@1wt.eu> References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> Date: Tue, 6 Jul 2010 22:13:15 -0700 Message-ID: From: Roberto Peon To: Willy Tarreau Content-Type: multipart/alternative; boundary=001636163fb7236edf048ac53a3a X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 05:13:31 -0000 --001636163fb7236edf048ac53a3a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 6, 2010 at 9:41 PM, Willy Tarreau wrote: > On Wed, Jul 07, 2010 at 12:44:32PM +1000, Micheil Smith wrote: > > Willy, > > > > Thanks for raising this point. I'm an author of a node.js powered > websocket > > server, and this was actually a really awkward part of the websocket spec > to > > comply to when writing my server. > > > > Without having a content-length header, the http parser in node doesn't > know > > how to handle the extra data it receives in that initial handshake. What > we > > ended up doing as a fix, was just to provide an upgradeHead as a slice of > the > > buffer from where the headers ended to the end of the packet. > > > > In short, I'd be all for having a content-length header sent to declare > the body > > as a body, or to declare it as just extra data that should be handled > post upgrade. > > >From what I can tell from what Ian is telling me over irc, he'd be more > inclined to > > add in content-length: 0 as a header, then content-length: 8. > > > > Hopefully this reply does make somewhat sense. > > Content-length: 0 also makes sense but it means that the nonce will > be sent *after* the handshake, which means we'd have a second > round-trip. For some sites who deal with hundreds of thousands of > concurrent connections (and I know some), having two more packets > in a connectionn is an unneeded increase of network traffic. For > this reason, I think that the idea of the nonce in the request header > is good. > > If we're worried about hundreds of thousands of connections, then we need multiplexing of sessions over one TCP connection between the browser and the server. I, for one, am extremely worried about it, and am perhaps more worried that many seem to be just shrugging it off-- even ignoring the server scalability problems, NAT boxes do really funny and nasty things when their connection tables overflow. I do love that we're thinking about ways to make fail-fast happen within the context of HTTP. This makes so much more sense to me. -=R > However, I think that having content-length: 0 in the *response* will > definitely help eliminating incompatible intermediates : those who > properly support 101 will forward the data regardless of the content > length because the tunnel is established. Those who don't completely > support 101 will stop at the content-length and not forward the > response. Alternatively, it might be nice to use a transfer-encoding: > chunked in the response with only an end of chunk ("0\r\n") before the > nonce. That would permit the client to check if it receives only the > "0\r\n" or if it receives the nonce too. An increased check could also > consist in setting "Connection: close" in the response in addition with > the transfer-encoding or content-length. That way, incompatible > intermediates won't remain open waiting for anything and will quickly > close the connection before the part they don't support. > > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --001636163fb7236edf048ac53a3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 6, 2010 at 9:41 PM, Willy Ta= rreau <w@1wt.eu> wrote:
On Wed, Jul 07, 2010 at 12:44:32PM +1000, Micheil Smith w= rote:
> Willy,
>
> Thanks for raising this point. I'm an author of a node.js powered = websocket
> server, and this was actually a really awkward part of the websocket s= pec to
> comply to when writing my server.
>
> Without having a content-length header, the http parser in node doesn&= #39;t know
> how to handle the extra data it receives in that initial handshake. Wh= at we
> ended up doing as a fix, was just to provide an upgradeHead as a slice= of the
> buffer from where the headers ended to the end of the packet.
>
> In short, I'd be all for having a content-length header sent to de= clare the body
> as a body, or to declare it as just extra data that should be handled = post upgrade.
> >From what I can tell from what Ian is telling me over irc, he'= d be more inclined to
> add in content-length: 0 as a header, then content-length: 8.
>
> Hopefully this reply does make somewhat sense.

Content-length: 0 also makes sense but it means that the nonce will be sent *after* the handshake, which means we'd have a second
round-trip. For some sites who deal with hundreds of thousands of
concurrent connections (and I know some), having two more packets
in a connectionn is an unneeded increase of network traffic. For
this reason, I think that the idea of the nonce in the request header
is good.


If we're worried about hundreds of= thousands of connections, then we need multiplexing of sessions over one T= CP connection between the browser and the server.
I, for one, am extrem= ely worried about it, and am perhaps more worried that many seem to be just= shrugging it off-- even ignoring the server scalability problems, NAT boxe= s do really funny and nasty things when their connection tables overflow.


I do love that we're thinking about = ways to make fail-fast happen within the context of HTTP. This makes so muc= h more sense to me.
-=3DR
=A0
However, I think that having content-length: 0 in the *response* will
definitely help eliminating incompatible intermediates : those who
properly support 101 will forward the data regardless of the content
length because the tunnel is established. Those who don't completely support 101 will stop at the content-length and not forward the
response. Alternatively, it might be nice to use a transfer-encoding:
chunked in the response with only an end of chunk ("0\r\n") befor= e the
nonce. That would permit the client to check if it receives only the
"0\r\n" or if it receives the nonce too. An increased check could= also
consist in setting "Connection: close" in the response in additio= n with
the transfer-encoding or content-length. That way, incompatible
intermediates won't remain open waiting for anything and will quickly close the connection before the part they don't support.

Regards,
Willy

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

--001636163fb7236edf048ac53a3a-- From Martin.Thomson@andrew.com Tue Jul 6 22:21:35 2010 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 86B243A687B for ; Tue, 6 Jul 2010 22:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=-0.537, 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 OPI+5-qC8EBW for ; Tue, 6 Jul 2010 22:21:22 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 970463A6873 for ; Tue, 6 Jul 2010 22:21:18 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:5153 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S258618Ab0GGFVU (ORCPT ); Wed, 7 Jul 2010 00:21:20 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 7 Jul 2010 00:21:20 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 7 Jul 2010 13:21:18 +0800 From: "Thomson, Martin" To: Roberto Peon , Willy Tarreau Date: Wed, 7 Jul 2010 13:23:22 +0800 Thread-Topic: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies Thread-Index: AcsdkypIpYS8+b7VQc6XfLW3uodlNgAAOtWw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 05:21:36 -0000 DQo+IENvbnRlbnQtbGVuZ3RoOiAwIGFsc28gbWFrZXMgc2Vuc2UgYnV0IGl0IG1lYW5zIHRoYXQg dGhlIG5vbmNlIHdpbGwNCj4gYmUgc2VudCAqYWZ0ZXIqIHRoZSBoYW5kc2hha2UsIHdoaWNoIG1l YW5zIHdlJ2QgaGF2ZSBhIHNlY29uZA0KPiByb3VuZC10cmlwLiANCg0KVGhlIHJvdW5kLXRyaXAg dGhpbmcgaXMgYSBmYWxsYWN5LiAgSnVzdCBhcyB5b3UgY2FuIHBpcGVsaW5lIHJlcXVlc3RzLCBz byBjYW4geW91IHNlbmQgZXh0cmEgaGFuZHNoYWtleSBwYXJ0cyBhZnRlciB0aGUgaGVhZGVycy4N Cg0KU29sdXRpb246ICBUaGUgaGFuZHNoYWtlIGluY2x1ZGVzIGEgY29tcGxldGUgSFRUUCBtZXNz YWdlLCBQTFVTIGV4dHJhIHN0dWZmLiAgQWxsIG9mIHRoaXMgaXMgc2VudCBhdCBvbmNlLCBidXQg dGhlIEhUVFAgc3R1ZmYgc3RvcHMgaGFsZiB3YXkuDQoNClRoaXMgaXMgb25seSB0cnVlIGlmIHRo ZSBleHRyYSBzdHVmZiBpcyBkZXBlbmRlbnQgb24gaW5mb3JtYXRpb24gZnJvbSB0aGUgcGVlciwg d2hpY2ggaXMgbm90IHRoZSBjYXNlIGluIHRoaXMgc2NlbmFyaW8uDQo= From w@1wt.eu Tue Jul 6 22:31:40 2010 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 61B143A6893 for ; Tue, 6 Jul 2010 22:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.092, 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 xPzmzaVJ0vTK for ; Tue, 6 Jul 2010 22:31:31 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DCE0D3A687B for ; Tue, 6 Jul 2010 22:31:24 -0700 (PDT) Date: Wed, 7 Jul 2010 07:31:17 +0200 From: Willy Tarreau To: "Thomson, Martin" Message-ID: <20100707053117.GJ12126@1wt.eu> References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 05:31:41 -0000 On Wed, Jul 07, 2010 at 01:23:22PM +0800, Thomson, Martin wrote: > > > Content-length: 0 also makes sense but it means that the nonce will > > be sent *after* the handshake, which means we'd have a second > > round-trip. > > The round-trip thing is a fallacy. Just as you can pipeline requests, so can you send extra handshakey parts after the headers. > > Solution: The handshake includes a complete HTTP message, PLUS extra stuff. All of this is sent at once, but the HTTP stuff stops half way. > > This is only true if the extra stuff is dependent on information from the peer, which is not the case in this scenario. You're perfectly right Martin, this was a stupid comment of mine in fact. The extra round-trip will only be between the reverse proxy and the server, which is not a problem since both are supposed to be very close one to the other. So, let's have content-length: 0 in both directions and have the nonce transported *after* the handshake and tested by the client. Willy From gregw@webtide.com Wed Jul 7 08:01:32 2010 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 D907F3A67AB for ; Wed, 7 Jul 2010 08:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 s6TgYfT-Tz7T for ; Wed, 7 Jul 2010 08:01:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 914D53A67B4 for ; Wed, 7 Jul 2010 08:01:31 -0700 (PDT) Received: by fxm1 with SMTP id 1so5960387fxm.31 for ; Wed, 07 Jul 2010 08:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.70 with SMTP id s6mr5826033fao.67.1278514891293; Wed, 07 Jul 2010 08:01:31 -0700 (PDT) Received: by 10.223.119.140 with HTTP; Wed, 7 Jul 2010 08:01:31 -0700 (PDT) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> Date: Thu, 8 Jul 2010 01:01:31 +1000 Message-ID: From: Greg Wilkins To: "Thomson, Martin" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 15:01:33 -0000 Martin, You are correct that it is not an extra round trip. But I do not think it is a good solution to send a complete HTTP message PLUS extra stuff in the request. If the handshake is legal HTTP, the server should be able to rejects the websocket upgrade without closing the connection. This would allow the connection to remain in the browsers pool of connections and avoid an extra round trip to establish another connection if the application falls back to non-websocket transports. Sending extra stuff after the response is OK. cheers On 7 July 2010 15:23, Thomson, Martin wrote: > >> Content-length: 0 also makes sense but it means that the nonce will >> be sent *after* the handshake, which means we'd have a second >> round-trip. > > The round-trip thing is a fallacy. =C2=A0Just as you can pipeline request= s, so can you send extra handshakey parts after the headers. > > Solution: =C2=A0The handshake includes a complete HTTP message, PLUS extr= a stuff. =C2=A0All of this is sent at once, but the HTTP stuff stops half w= ay. > > This is only true if the extra stuff is dependent on information from the= peer, which is not the case in this scenario. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From Martin.Thomson@andrew.com Wed Jul 7 15:38:19 2010 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 473183A697A for ; Wed, 7 Jul 2010 15:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 UopeEu7gIc2t for ; Wed, 7 Jul 2010 15:38:17 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 9A5D33A68E7 for ; Wed, 7 Jul 2010 15:38:17 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:3650 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S335839Ab0GGWiU (ORCPT ); Wed, 7 Jul 2010 17:38:20 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 7 Jul 2010 17:38:20 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 8 Jul 2010 06:38:18 +0800 From: "Thomson, Martin" To: Greg Wilkins Date: Thu, 8 Jul 2010 06:40:20 +0800 Thread-Topic: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies Thread-Index: Acsd5UshXq8Mp9iIR7+KmX95gZW/pgAP97RA Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCCAD4@SISPE7MB1.commscope.com> References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 07 Jul 2010 22:38:19 -0000 VGhhdCdzIHJlYXNvbmFibGUuDQoNClRoZSBhbHRlcm5hdGl2ZSBpcyB0byBoYXZlIENvbnRlbnQt TGVuZ3RoIHNldCB0byB0aGUgbGVuZ3RoIG9mIHRoZSBleHRyYSBzdHVmZiAtIG1ha2UgdGhlIGV4 dHJhIGhhbmRzaGFrZSBzdHVmZiBwYXJ0IG9mIHRoZSBtZXNzYWdlIGJvZHkuICBUaGF0IHB1bGxz IGl0IHVwIGludG8gdGhlIEhUVFAuICBUaGF0IG9ubHkgYXBwbGllcyBvbiB0aGUgcmVxdWVzdCAt IHRoZSByZXNwb25zZSB0byBhIHN1Y2Nlc3NmdWwgaGFuZHNoYWtlIGNhbiBkbyBhbnl0aGluZyBp dCBsaWtlcyBvbmNlIHRoZSBIVFRQIHBhcnQgaXMgb3V0IG9mIHRoZSB3YXkuDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogR3JlZyBXaWxraW5zIFttYWlsdG86Z3JlZ3dA d2VidGlkZS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCA4IEp1bHkgMjAxMCAxOjAyIEFNDQo+IFRv OiBUaG9tc29uLCBNYXJ0aW4NCj4gQ2M6IFJvYmVydG8gUGVvbjsgV2lsbHkgVGFycmVhdTsgaHli aUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2h5YmldIFdlYlNvY2tldCAtNzYgaXMgaW5jb21w YXRpYmxlIHdpdGggSFRUUCByZXZlcnNlDQo+IHByb3hpZXMNCj4gDQo+IE1hcnRpbiwNCj4gDQo+ IFlvdSBhcmUgY29ycmVjdCB0aGF0IGl0IGlzIG5vdCBhbiBleHRyYSByb3VuZCB0cmlwLiAgQnV0 IEkgZG8gbm90DQo+IHRoaW5rIGl0IGlzIGEgZ29vZCBzb2x1dGlvbiB0byBzZW5kIGEgY29tcGxl dGUgSFRUUCBtZXNzYWdlIFBMVVMgZXh0cmENCj4gc3R1ZmYgaW4gdGhlIHJlcXVlc3QuDQo+IA0K PiBJZiB0aGUgaGFuZHNoYWtlIGlzIGxlZ2FsIEhUVFAsIHRoZSBzZXJ2ZXIgc2hvdWxkIGJlIGFi bGUgdG8gcmVqZWN0cw0KPiB0aGUgd2Vic29ja2V0IHVwZ3JhZGUgd2l0aG91dCBjbG9zaW5nIHRo ZSBjb25uZWN0aW9uLiAgVGhpcyB3b3VsZA0KPiBhbGxvdyB0aGUgY29ubmVjdGlvbiB0byByZW1h aW4gaW4gdGhlIGJyb3dzZXJzIHBvb2wgb2YgY29ubmVjdGlvbnMgYW5kDQo+IGF2b2lkIGFuIGV4 dHJhIHJvdW5kIHRyaXAgdG8gZXN0YWJsaXNoIGFub3RoZXIgY29ubmVjdGlvbiBpZiB0aGUNCj4g YXBwbGljYXRpb24gZmFsbHMgYmFjayB0byBub24td2Vic29ja2V0IHRyYW5zcG9ydHMuDQo+IA0K PiBTZW5kaW5nIGV4dHJhIHN0dWZmIGFmdGVyIHRoZSByZXNwb25zZSBpcyBPSy4NCj4gDQo+IGNo ZWVycw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24gNyBKdWx5IDIwMTAgMTU6MjMs IFRob21zb24sIE1hcnRpbiA8TWFydGluLlRob21zb25AYW5kcmV3LmNvbT4NCj4gd3JvdGU6DQo+ ID4NCj4gPj4gQ29udGVudC1sZW5ndGg6IDAgYWxzbyBtYWtlcyBzZW5zZSBidXQgaXQgbWVhbnMg dGhhdCB0aGUgbm9uY2Ugd2lsbA0KPiA+PiBiZSBzZW50ICphZnRlciogdGhlIGhhbmRzaGFrZSwg d2hpY2ggbWVhbnMgd2UnZCBoYXZlIGEgc2Vjb25kDQo+ID4+IHJvdW5kLXRyaXAuDQo+ID4NCj4g PiBUaGUgcm91bmQtdHJpcCB0aGluZyBpcyBhIGZhbGxhY3kuIMKgSnVzdCBhcyB5b3UgY2FuIHBp cGVsaW5lDQo+IHJlcXVlc3RzLCBzbyBjYW4geW91IHNlbmQgZXh0cmEgaGFuZHNoYWtleSBwYXJ0 cyBhZnRlciB0aGUgaGVhZGVycy4NCj4gPg0KPiA+IFNvbHV0aW9uOiDCoFRoZSBoYW5kc2hha2Ug aW5jbHVkZXMgYSBjb21wbGV0ZSBIVFRQIG1lc3NhZ2UsIFBMVVMgZXh0cmENCj4gc3R1ZmYuIMKg QWxsIG9mIHRoaXMgaXMgc2VudCBhdCBvbmNlLCBidXQgdGhlIEhUVFAgc3R1ZmYgc3RvcHMgaGFs ZiB3YXkuDQo+ID4NCj4gPiBUaGlzIGlzIG9ubHkgdHJ1ZSBpZiB0aGUgZXh0cmEgc3R1ZmYgaXMg ZGVwZW5kZW50IG9uIGluZm9ybWF0aW9uIGZyb20NCj4gdGhlIHBlZXIsIHdoaWNoIGlzIG5vdCB0 aGUgY2FzZSBpbiB0aGlzIHNjZW5hcmlvLg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gaHliaSBtYWlsaW5nIGxpc3QNCj4gPiBoeWJpQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oeWJpDQo+ ID4NCg== From alexey.melnikov@isode.com Thu Jul 8 05:53:25 2010 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 DD0EF3A6A84 for ; Thu, 8 Jul 2010 05:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 ajDLVoBMUTuO for ; Thu, 8 Jul 2010 05:53:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C80633A67E3 for ; Thu, 8 Jul 2010 05:53:24 -0700 (PDT) Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Jul 2010 13:53:28 +0100 Message-ID: <4C35CA30.80308@isode.com> Date: Thu, 08 Jul 2010 13:53:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: hybi@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Reminder to document editors: Internet Draft final submission cut-off is July 12 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, 08 Jul 2010 12:53:26 -0000 Hi, This is a friendly reminder from the Area Director responsible for this WG that Internet Draft submission cut-off is July 12: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 It looks like there are some changes that need to be implemented to WG documents, so it would be good to see documents updated before the IETF meeting in Maastricht. Best Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From trac@tools.ietf.org Thu Jul 8 10:06:10 2010 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 71B8A3A6B1B for ; Thu, 8 Jul 2010 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, 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 fxifv-0NmTrd for ; Thu, 8 Jul 2010 10:06:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 756EC3A6B57 for ; Thu, 8 Jul 2010 10:06:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OWuY5-00050x-UZ; Thu, 08 Jul 2010 10:06:09 -0700 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: salvatore.loreto@ericsson.com X-Trac-Project: hybi Date: Thu, 08 Jul 2010 17:06:09 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/4 Message-ID: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: salvatore.loreto@ericsson.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: [hybi] #4: handshake does not work properly with HTTP reverse proxy. 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: Thu, 08 Jul 2010 17:06:10 -0000 #4: handshake does not work properly with HTTP reverse proxy. -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: thewebsocketprotocol | Version: Severity: Active WG Document | Keywords: -------------------------------------------+-------------------------------- the handshake in draft-ietf-hybi-thewebsocketprotocol-00 (as in draft 76) does not work properly in presence of HTTP reverse proxy. The 8-bytes nonce from the client is not advertised as a content-length, so it is not forwarded by the reverse proxy as it is either part of a next request or pending data for when the handshake completes. Unfortunately, the server wants those bytes to complete the handshake, so we have a dirty deadlock not even detectable by the end user. for more information: http://www.ietf.org/mail-archive/web/hybi/current/msg02149.html -- 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 g_e_montenegro@yahoo.com Thu Jul 8 11:20:16 2010 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 CAC443A67C0 for ; Thu, 8 Jul 2010 11:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 w3ZozvfIXAh8 for ; Thu, 8 Jul 2010 11:20:15 -0700 (PDT) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id E539D3A6804 for ; Thu, 8 Jul 2010 11:20:14 -0700 (PDT) Received: (qmail 65331 invoked by uid 60001); 8 Jul 2010 18:20:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278613215; bh=m6oF7X4PWakdFx4TxSso2Edlsw6E7tKelJ/rtmsBzCA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Juac6luRvbsHbSyDyCMsQDPbMODus3VeU7iPItv0tMy4BkqQ5RK0rexImE0rMdrCsPNGshPiGvFsvGlNLJ4DYNUrQPQfoSkc38CIakFNRVSUQYNTykMzztUePGELXfDZ80Sup1LalP1XY7fjgjOC6ltabQNCIkoWrN5WMh/CCQg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5zXsPG0scCh1TMqc3yPfP0qjkd+3VlK8h2uliHmmhRvzaJVBrF5L5bYr+3mK3fvhPEf/qYvVBb9Up/nt6bPTZH+Gh5jP/CaGVVT/CM4/XmsOkUdjGVyJyDnQ/6Gk21KYeucnkB7aFV0DQeWqFoN1NNWUbgMBqyAEbTs6HolZbKI=; Message-ID: <615374.65181.qm@web82607.mail.mud.yahoo.com> X-YMail-OSG: UuJuiywVM1n.Q.WkH.1fGjwD1gmgciyGnKytJhG8ilUbJ7m 83sfxGfqgmJlDmPYalLOMxcxwFKt49pjVZWxR8MynW612wX23Dqr.ZoQmPE9 Qj7pS1xKo3sp7UPcDayCd_VYSElr0pC0x1wvV..1EwDBMiOyGAtXNEFAJcqU N1mkowJZn.bnlp_eqVh7MNTThOvIc21LrRmvwKzOd_ee0.saTz_aP3PmVM7S 3LdwYO6abtYTpv9_bIKR786CsT9FvzbYqNn_AuV1fPCl0MjC_KBgBdngoRIr RGhZbz8eibcPZD4t_u0puLhi4CJyx2WRS16U2WeUf5WJUgl7yD5HQow-- Received: from [71.197.227.220] by web82607.mail.mud.yahoo.com via HTTP; Thu, 08 Jul 2010 11:20:15 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 Date: Thu, 8 Jul 2010 11:20:15 -0700 (PDT) From: gabriel montenegro To: hybi@ietf.org, draft-ietf-hybi-websocket-requirements@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 08 Jul 2010 18:20:16 -0000 Hi folks,=0AI've had some conversations with collegues at Microsoft and we'= d like =0Ato provide some feedback on the requirements document. =0APlease = find it interspersed with the text of the draft below =0A(between "---" mar= kings). Hopefully, it is not too late for the =0Arevision before next Monda= y's deadline.=0Athanks,=0AGabriel Montenegro=0AWindows Networking, Microsof= t=0A=0A[initial text elided]=0A1.=C2=A0 Introduction=0A=C2=A0=C2=A0 HTTP [R= FC2616] is a client/server protocol, where the HTTP servers=0A=C2=A0=C2=A0 = store the data and provide it when it is requested by clients.=C2=A0 When= =0A=C2=A0=C2=A0 used to used to retrieve data from an HTTP server, the clie= nt sends=0A---=0A/used to//=0A---=0A=C2=A0=C2=A0 HTTP requests to the serve= r, and the server returns the requested=0A=C2=A0=C2=A0 data in HTTP respons= es.=C2=A0 So the client has to poll continuously the=0A=C2=A0=C2=A0 server = in order to receive new data.=0A=C2=A0=C2=A0 Recently techniques that enabl= e bidirectional communication over HTTP=0A=C2=A0=C2=A0 have become more per= vasive.=C2=A0 Those techniques reduce the need to poll=0A=C2=A0=C2=A0 conti= nuously the server thanks to the usage of HTTP hanging requests=0A=C2=A0=C2= =A0 and multiple connections between the client and the server=0A=C2=A0=C2= =A0 [I-D.loreto-http-bidirectional].=0A---=0AReplace with I-D. ietf-hybi-de= sign-space=0A---=0A=C2=A0=C2=A0 The goal of HyBi is to provide an efficient= and clean two-way=0A=C2=A0=C2=A0 communication channel between client and = server.=0A=C2=A0=C2=A0 The communication channel will:=0A=C2=A0=C2=A0 o=C2= =A0 allow each side to, independently from the other, send data when=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 is willing and ready to do it;=0A=C2=A0=C2=A0 o= =C2=A0 rely on a single TCP connection for traffic in both the=0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 directions.=0A=C2=A0=C2=A0 o=C2=A0 reduce the high ov= erhead produced by HTTP headers in each request/=0A=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 response.=0A---=0AGiven the verbage above about =E2=80=98recent tech= niques=E2=80=99 it is better to be =0Aexplicit about the fact that the WG i= s not going to standardize any =0Aof the existing hacks that reuse HTTP (or= extended HTTP), but rather to =0AUPGRADE the connection to a separate prot= ocol with the right semantics =0Asatisfying the requirements set forth in t= his document.=0ASuggest adding this bullet to the list above:=0A=C2=A0=C2= =A0 O=C2=A0 Use HTTP UPGRADE to set up the communication channel between = =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client and server using the WebSocket Pro= tocol. =0A---=0A=C2=A0=C2=A0 The goal of this work is to provide the set of= requirements the=0A=C2=A0=C2=A0 WebSocket Protocol MUST meet.=0A=C2=A0=C2= =A0 In the following sections we list and analyse the requirements from=0A= =C2=A0=C2=A0 the perspective of clients and servers.=0A=0A2.=C2=A0 Terminol= ogy=0A=C2=A0=C2=A0 In this document, the key words "MUST", "MUST NOT", "REQ= UIRED",=0A=C2=A0=C2=A0 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOM= MENDED", "NOT=0A=C2=A0=C2=A0 RECOMMENDED", "MAY", and "OPTIONAL" are to be = interpreted as=0A=C2=A0=C2=A0 described in BCP 14, RFC 2119 [RFC2119] and i= ndicate requirement=0A=C2=A0=C2=A0 levels for compliant implementations.=0A= 2.1.=C2=A0 HyBi Terminology=0A=C2=A0=C2=A0 This document uses the following= HyBi-related terms:=0A=C2=A0=0A=0AWilkins & Stachowiak=C2=A0=C2=A0=C2=A0 E= xpires November 11, 2010=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 3]=0A=C2=A0=0AInternet-Draft=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HyBi WebSocket Requirements=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= May 2010=0A=0A=C2=A0=C2=A0 connection:=C2=A0 A transport layer virtual cir= cuit established between a=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client and a se= rver for the purpose of communication.=0A=C2=A0=C2=A0 frame:=C2=A0 The basi= c unit of WebSocket communication, consisting of a=0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 structured sequence of octets matching the syntax defined in the= =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 actual protocol and transmitted on the es= tablished communication=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel.=0A=C2=A0= =C2=A0 message:=C2=A0 user message: a block of related data with identified= =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boundaries.=0A=C2=A0=C2=A0 origin server:= =C2=A0 The server on which a given resource resides or is to=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 be created.=0A---=0ASuggest adding definitions for the 3= aspects of the protocol along =0Athese lines:=0AWebSocket handshake: The p= rocess involving the HTTP UPGRADE and =0Aassociated capability negotiation = that sets up the WebSocket =0Acommunication channel=0AWebSocket communicati= on channel : After the WebSocket handshake is =0Acomplete, the resultant bi= -directional communication path between =0Aclient and server over the trans= port (e.g., TCP, or SSL over TCP) =0Athat was used by HTTP up to and includ= ing the UPGRADE.=0AWebSocket sub-protocol: The negotiated sub-protocol for = use on a =0AWebSocket communication channel that dictates framing, encoding= , =0Acompression, etc.=0AThe chronological relationship among these is:=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HTTP(s) session=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 V=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 WebSocket Handshake [including Sub-Protocol negotiation]=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 V=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 WebSocket communication channel =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 V=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket Sub-protoco= l =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 (uses framing, encoding, compression, etc as dictated=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the sub-= protocol)=0A---=0A3.=C2=A0 WebSocket Requirements=0A=C2=A0=C2=A0 The follow= ing requirements fro WebSocket Protocol have been=0A---=0A/fro/for the/=0A-= --=0A=C2=A0=C2=A0 identified both in the HyBi wg input document=0A=C2=A0=C2= =A0 [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list=0A=C2=A0= =C2=A0 dicussion.=0A=C2=A0=C2=A0 REQ. 1:=C2=A0 The WebSocket Protocol MUST = run directly on top of a=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transport protoco= l (e.g.=C2=A0 TCP, UDP or SCTP, DCCP).=0A---=0ANo need to say anything, as = the point is that whatever HTTP was =0Arunning over should continue to be u= sed after the upgrade. Typically =0Athis is TCP, yes. So how about rewordin= g thus:=0A=C2=A0=C2=A0 REQ. 1:=C2=A0 The WebSocket Protocol MUST run direct= ly on top of =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the transport over which the= initial HTTP handshake was running =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (typi= cally TCP).=0A---=0A=C2=A0=C2=A0 REQ. 2:=C2=A0 The WebSocket Protocol MUST = be able to handle (send and=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receive) messa= ges on top of a TCP data stream connection.=0A---=0ASuggest rewording:=0A= =C2=A0=C2=A0 REQ. 2:=C2=A0 The WebSocket Protocol MUST be able to handle (s= end and=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receive) messages up to a maximum = size (TBD) on top of the transport =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 over w= hich the initial HTTP handshake was running (typically TCP).=0A---=0A=0A=C2= =A0=C2=A0 Reason: transfer data as message prevents the receiver to parse/= =0A=C2=A0=C2=A0 handle partial content.=0A---=0ANot sure I could parse the = above. Is this closer to the intent?:=0AReason: transfer data as message ob= viates the need for the receiver to parse/=0A=C2=A0=C2=A0 handle partial co= ntent.=0A---=0A=C2=A0=C2=A0 REQ. 3:=C2=A0 It MUST be possible to sent a mes= sage when the total size is=0A---=0A/sent/send/=0A---=0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 either unknown or exceeds a fixed buffer size.=0A---=0A/size/s= ize (TBD)./=0A---=0A=C2=A0=C2=A0 Reason: This will allow dynamic messages t= o be constructed and sent=0A=C2=A0=C2=A0 without the need to buffer the ent= ire message.=0A=C2=A0=C2=A0 REQ. 4:=C2=A0 Textual data MUST be encoded as U= TF-8.=0A---=0AGood that this only applies to textual data. But it is not cl= ear what =0A"text data" refers to: either metadata used in capability negot= iation =0Aduring the handshake or textual data in the data stream in the = =0Aestablished communication channel.=0A---=0A=C2=A0=C2=A0 REQ. 5:=C2=A0 Th= e protocol MUST be designed to support different frame=0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 types (e.g. binary).=0A---=0ASuggest changing to different "da= ta types" to be consistent with REQ 4,=0Awhich uses the expression "textual= *data*". So how about something like=0Athis:=0A=C2=A0=C2=A0 REQ. 5:=C2=A0 = The protocol MUST be designed to support negotiation among =0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 multiple possible framing mechanisms (e.g. binary,= textual).=C2=A0=0A---=0A=C2=A0=C2=A0 REQ. 6:=C2=A0 The WebSocket protocol = MUST allow HTTP and WebSocket=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connections = to be served from the same port.=C2=A0 Consideration MUST=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 be given:=0A=C2=A0=0A=C2=A0=0AWilkins & Stachowiak=C2=A0=C2= =A0=C2=A0 Expires November 11, 2010=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 4]=0A=C2=A0=0AInternet-= Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HyBi WebSocket Requir= ements=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 May 2010=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 * to provide WebSocket services via modules that plug in to=0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 existing web infrastructure.=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * to making it possible and p= ractical to implement standalone=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 implementations of the protocol without requiring a fully=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 conforming HTTP implementatio= n.=0A=0A=C2=A0=C2=A0 Reason: Some server developers would like to integrate= WebSocket=0A=C2=A0=C2=A0 support into existing HTTP servers.=C2=A0 In addi= tion, the default HTTP=0A=C2=A0=C2=A0 and HTTPS ports are ofter favoured fo= r traffic that has to go through=0A=C2=A0=C2=A0 a firewall, so service prov= iders will likely want to be able to use=0A=C2=A0=C2=A0 WebSocket over port= s 80 and 443, even when running a We server on the=0A=C2=A0=C2=A0 same host= .=C2=A0 However there could be scenarios where it is not=0A=C2=A0=C2=A0 opp= ortune or possible to setup a proxy on the same HTTP server.=0A=C2=A0=C2=A0= REQ. 7:=C2=A0 When sharing host and "well known" port with HTTP, the=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket protocol MUST be HTTP compatible unti= l both ends have=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 established the WebSocket= protocol.=0A---=0AWhat is the difference between fully conforming HTTP and= HTTP compatible?=0AAlso, to clarify what aspects of the protocol are being= referred to,=0AI suggest rewording as follows:=0A=C2=A0=C2=A0 REQ. 7:=C2= =A0 When sharing host and "well known" port with HTTP, the=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 WebSocket protocol handshake MUST be HTTP compatible unt= il both ends have=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 established the WebSocke= t protocol communication channel.=0A---=0A=C2=A0=C2=A0 Reason: when operati= ng on the standard HTTP ports, existing web=0A=C2=A0=C2=A0 infrastructure m= ay handle according to existing standards prior to=0A=C2=A0=C2=A0 the estab= lishment of the new protocol.=0A=C2=A0=C2=A0 REQ. 8:=C2=A0 The protocol SHO= ULD make it possible and practical to reuse=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 existing HTTP components where appropriate.=0A=C2=A0=C2=A0 Reason: the = re-usage of existing well-debugged software decreases the=0A=C2=A0=C2=A0 nu= mber of implementation errors as well as the possibility to=0A=C2=A0=C2=A0 = introduce security holes especially and at the same time speed up the=0A=C2= =A0=C2=A0 development especially when the Web Socket server is implemented = as=0A=C2=A0=C2=A0 modules that plug in to existing popular Web servers.=0A-= --=0AHere's one more requirement:=0AReq # TBD: WebSocket sub-protocols MUST= be able to support different =0Aframing and encoding and be able to reuse = existing security mechanisms =0A(e.g., upgrading to a TLS-enabled session f= or XMPP).=0A---=0A3.1.=C2=A0 WebSocket Client Requirements=0A=C2=A0=C2=A0 R= EQ. 9:=C2=A0 The WebSocket Client MUST be able to set up a communication=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel sending to a WebSocket Server a well= defined handshake.=0A---=0ASlight rewording suggested:=0A=C2=A0=C2=A0 REQ.= 9:=C2=A0 The WebSocket Client MUST be able to set up a communication=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 channel with a WebSocket Server using a well de= fined handshake.=0A---=0A=C2=A0=C2=A0 REQ. 10:=C2=A0 WebSocket Protocol MUS= T provide for graceful close of an=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 active = WebSocket connection on request from the user Application.=0A=C2=A0=C2=A0 R= eason: a clean shutdown signals that the other endpoint has=0A=C2=A0=C2=A0 = definitely received all the messages sent prior the the close, so=0A---=0A/= the the/to the/=0A---=0A=C2=A0=C2=A0 there is no protocol uncertainty about= what has been processed / what=0A=C2=A0=C2=A0 can be retried on another co= nnection.=0A=C2=A0=0A=C2=A0=0AWilkins & Stachowiak=C2=A0=C2=A0=C2=A0 Expire= s November 11, 2010=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Page 5]=0A=C2=A0=0AInternet-Draft=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HyBi WebSocket Requirements=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ma= y 2010=0A=0A=C2=A0=C2=A0 OPEN ISSUE:=C2=A0 WebSocket Protocol MUST also all= ow ungraceful close,=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 either on request fro= m the user application or as a result of a=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= detected error condition.=0A---=0ACan=E2=80=99t be avoided (e.g., if one e= nd stops responding or crashes), =0Aso MUST is correct.=0A---=0A=C2=A0=C2= =A0 REQ. 11:=C2=A0 The WebSocket Client MUST be able to request the server,= =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 during the handshake, to use a specific W= ebSocket sub-protocol.=0A---=0ASuggest rewording as follows:=0A=C2=A0=C2=A0= REQ. 11:=C2=A0 During the handshake ,the WebSocket Client MUST be able =0A= to send one or more WebSocket sub-protocol proposals to the server =0Aso th= at the server can select one.,This results in the use of a specific =0AWebS= ocket sub-protocol.=0A---=0A=0A=C2=A0=C2=A0 REQ. 12:=C2=A0 The WebSocket Cl= ient MUST have the ability to send=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitra= ry text content to the server on the established=0A=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 communication channel, in the form of ordered discrete blocks.=0A=C2= =A0=C2=A0 REQ. 13:=C2=A0 The WebSocket Client MUST have the ability to send= =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary binary content to the server on= the established=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, in= the form of ordered discrete blocks.=0A---=0A#12 and #13 can be combined i= nto one. Suggest rewording #12 as follows and=0Adeleting #13:=0A=C2=A0=C2= =A0 REQ. 12:=C2=A0 The WebSocket Client MUST have the ability to send=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary content to the server on the establis= hed=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, as dictated by = the WebSocket =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub-protocol in effec= t.=0A---=0A3.2.=C2=A0 WebSocket Server Requirements=0A=C2=A0=C2=A0 REQ. 14:= =C2=A0 The WebSocket Server that accept to set up, with a=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 WebSocket Client, a communication channel MUST send back to= the=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket Client a well defined hands= hake.=0A---=0ASuggest rewording as follows:=0A=C2=A0=C2=A0 REQ. 14:=C2=A0 T= he WebSocket Server that accepts to set up =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 a communication channel with a=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSock= et Client MUST use a well defined handshake.=0A---=0A=C2=A0=C2=A0 REQ. 15:= =C2=A0 The WebSocket Server MUST have the ability to send=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 arbitrary text content to the client on the established=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, in the form of ordere= d discrete blocks.=0A=C2=A0=C2=A0 REQ. 16:=C2=A0 The WebSocket Server MUST = have the ability to send=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary binary = content to the client on the established=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c= ommunication channel, in the form of ordered discrete blocks.=0A---=0A#15 a= nd #16 can be combined into one. Suggest rewording #15 as follows and=0Adel= eting #16:=0A=C2=A0=C2=A0 REQ. 15:=C2=A0 The WebSocket Server MUST have the= ability to send=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary content to the = client on the established=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication ch= annel, as dictated by the WebSocket sub-protocol =0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 in effect.=0A---=0A3.3.=C2=A0 WebSocket Proxies Requirements=0A= =C2=A0=C2=A0 Todo=0A----=0ASuggest adding the requirement as follows, as ny= thing short of this is not practical:=0A=C2=A0=C2=A0 REQ. TBD: WebSocket MU= ST work over existing proxies to the same extent =0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 as HTTP or HTTPS already does.=0A----=0A3.4.=C2=A0 WebSocket Secu= rity Requirements=0A=C2=A0=C2=A0 REQ. 17:=C2=A0 The WebSocket Protocol MUST= use the Origin-based security=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 model commo= nly used by Web browsers to restrict which Web pages=0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 can contact a WebSocket sever when the WebSocket protocol is u= sed=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from a Web page.=0A=C2=A0=C2=A0 REQ. 1= 8:=C2=A0 When used directly (not from a Web page), the WebSocket=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Protocol MUST use an equivalent security model.=0A= =0A---=0A"origin-based" security is not directly translatable to non-browse= r=0A=C2=A0usage, so requiring an "equivalent" model is problematic.=C2=A0 T= here may =0Abe different models available outside the browser world so this= =0Ais a very narrow view. Outside of the browser, there is precedent =0Ain= direct HTTP(S) usage (e.g., via utilities such as curl) so that =0Ausage s= hould be allowed.=0ASuggest rewording as follows:=0A=C2=A0=C2=A0 REQ. 18:= =C2=A0 When used directly (not from a Web page), the WebSocket=0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Protocol MUST use a security model equivalent to that= of direct =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HTTP or HTTPS usage.=0A---=0A= =C2=A0=0A=0AWilkins & Stachowiak=C2=A0=C2=A0=C2=A0 Expires November 11, 201= 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 [Page 6]=0A=C2=A0=0AInternet-Draft=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 HyBi WebSocket Requirements=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 May 2010=0A=C2=A0=0A= =C2=A0=C2=A0 REQ. 19:=C2=A0 WebSocket should be designed to be robust again= st cross-=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protocol attacks.=C2=A0 The prot= ocol design should consider and=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mitigate t= he risk presented by WebSocket clients to existing=0A=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 servers (including HTTP servers).=C2=A0 It should also consider a= nd=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mitigate the risk to WebSocket servers = presented by clients for=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other protocols (= including HTTP).=0A---=0AThese terms should reuse thjose discussed in the H= TTP security =0Aanalysis work in HASMAT or defined here.=0A---=0A=C2=A0=C2= =A0 Reason: As the Web Socket protocol is expected to be mainly used in=0A-= --=0A/mainly/often/=0A"mainly" implies other usages are not as important or= are 2nd class citizens,=0Acontrary to what the charter says: "Wide browser= support is a goal for =0Athe bidirectional communication mechanism, howeve= r the solution should =0Aalso be suitable for clients other than Web Browse= rs." =0A---=0A=C2=A0=C2=A0 browsers, a careful design is necessary to mitig= ate the chances for=0A=C2=A0=C2=A0 hostile JavaScript to use WebSocket for = a cross-protocol attack=0A=C2=A0=C2=A0 against vanilla HTTP resources or no= n-HTTP servers.=C2=A0 More the design=0A=C2=A0=C2=A0 should prevent the pos= sibility for cross-site XMLHttpRequest (using=0A=C2=A0=C2=A0 CORS or XDomai= nRequest) to be used for a cross-protocol attack=0A=C2=A0=C2=A0 against Web= Socket resources, potentially violating integrity (though=0A=C2=A0=C2=A0 no= t confidentiality).=0A=0A[rest of the text elided...] From gregw@webtide.com Thu Jul 8 17:28:34 2010 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 C86093A6987 for ; Thu, 8 Jul 2010 17:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 9PPWqgfJsgxT for ; Thu, 8 Jul 2010 17:28:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2E9E93A659A for ; Thu, 8 Jul 2010 17:28:32 -0700 (PDT) Received: by fxm1 with SMTP id 1so811560fxm.31 for ; Thu, 08 Jul 2010 17:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.120.200 with SMTP id e8mr7743277far.0.1278635309510; Thu, 08 Jul 2010 17:28:29 -0700 (PDT) Received: by 10.223.119.140 with HTTP; Thu, 8 Jul 2010 17:28:29 -0700 (PDT) In-Reply-To: <615374.65181.qm@web82607.mail.mud.yahoo.com> References: <615374.65181.qm@web82607.mail.mud.yahoo.com> Date: Fri, 9 Jul 2010 10:28:29 +1000 Message-ID: From: Greg Wilkins To: gabriel montenegro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-hybi-websocket-requirements@tools.ietf.org, hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 09 Jul 2010 00:28:34 -0000 Gabriel, I'm no longer editor of the requirements, but I've commented below as an individual. On 9 July 2010 04:20, gabriel montenegro wrote: > =C2=A0=C2=A0 REQ. 1:=C2=A0 The WebSocket Protocol MUST run directly on to= p of a > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transport protocol (e.g.=C2=A0 TCP, UDP or= SCTP, DCCP). > --- > No need to say anything, as the point is that whatever HTTP was > running over should continue to be used after the upgrade. Typically > this is TCP, yes. So how about rewording thus: > =C2=A0=C2=A0 REQ. 1:=C2=A0 The WebSocket Protocol MUST run directly on to= p of > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the transport over which the initial HTTP = handshake was running > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (typically TCP). +1 > --- > =C2=A0=C2=A0 REQ. 2:=C2=A0 The WebSocket Protocol MUST be able to handle = (send and > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receive) messages on top of a TCP data str= eam connection. > --- > Suggest rewording: > =C2=A0=C2=A0 REQ. 2:=C2=A0 The WebSocket Protocol MUST be able to handle = (send and > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 receive) messages up to a maximum size (TB= D) on top of the transport > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 over which the initial HTTP handshake was = running (typically TCP). I don't think we should mix in size requirements here. > =C2=A0=C2=A0 REQ. 4:=C2=A0 Textual data MUST be encoded as UTF-8. > --- > Good that this only applies to textual data. But it is not clear what > "text data" refers to: either metadata used in capability negotiation > during the handshake or textual data in the data stream in the > established communication channel. Agreed the reference to textual data is poorly defined.. see below: > =C2=A0=C2=A0 REQ. 5:=C2=A0 The protocol MUST be designed to support diffe= rent frame > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 types (e.g. binary). > --- > Suggest changing to different "data types" to be consistent with REQ 4, > which uses the expression "textual *data*". So how about something like > this: > =C2=A0=C2=A0 REQ. 5:=C2=A0 The protocol MUST be designed to support negot= iation among > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multiple possible framing mechanisms= (e.g. binary, textual). I think "negotiation" is a loaded word for this protocol, and I think some = are very much opposed to any negotiation and prefer a declarative (or assumed) approach. I actually think that there is no requirement to support different framing. The requirement is that we must be able to transport both binary and text messages - if one framing mechanism can do both, then great! So how about: REQ. 5: The protocol MUST be designed to support both binary and textual data. > =C2=A0=C2=A0 REQ. 7:=C2=A0 When sharing host and "well known" port with H= TTP, the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket protocol MUST be HTTP compatible= until both ends have > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 established the WebSocket protocol. > --- > What is the difference between fully conforming HTTP and HTTP compatible? I have long argued that we should require "compliance" rather than compatibility. Compliance implies a more than compatibility in that telnet could be said t= o be HTTP compatible because you can telnet to port 80 and interact with a HTTP server. But telnet is not HTTP compliant, because it can also be used to s= end illegal HTTP. Compliance means that the HTTP conversation needs to be legal HTTP up until the websocket communication channel is established (for which I agree with your extra wording). > Also, to clarify what aspects of the protocol are being referred to, > I suggest rewording as follows: > =C2=A0=C2=A0 REQ. 7:=C2=A0 When sharing host and "well known" port with H= TTP, the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket protocol handshake MUST be HTTP = compatible until both ends have > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 established the WebSocket protocol communi= cation channel. +1 (specially if we s/compatible/compliant/) > Here's one more requirement: > Req # TBD: WebSocket sub-protocols MUST be able to support different > framing and encoding and be able to reuse existing security mechanisms > (e.g., upgrading to a TLS-enabled session for XMPP). I don't agree with this one. Websocket should be a specific protocol, with specific framing. If you want to carry XMPP, then you need to define a binding for XMPP to websocket framing. I think this subprotocol should represent this binding and not a different framing mechanism. > --- > 3.1.=C2=A0 WebSocket Client Requirements > =C2=A0=C2=A0 REQ. 9:=C2=A0 The WebSocket Client MUST be able to set up a = communication > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel sending to a WebSocket Server a we= ll defined handshake. > --- > Slight rewording suggested: > =C2=A0=C2=A0 REQ. 9:=C2=A0 The WebSocket Client MUST be able to set up a = communication > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel with a WebSocket Server using a we= ll defined handshake. +1 > =C2=A0=C2=A0 REQ. 11:=C2=A0 The WebSocket Client MUST be able to request = the server, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 during the handshake, to use a specific We= bSocket sub-protocol. > --- > Suggest rewording as follows: > =C2=A0=C2=A0 REQ. 11:=C2=A0 During the handshake ,the WebSocket Client MU= ST be able > to send one or more WebSocket sub-protocol proposals to the server > so that the server can select one.,This results in the use of a specific > WebSocket sub-protocol. Firstly I don't think the requirements document should actually talk about the handshake. Handshaking is an implementation detail. So the requirement should be just about establishing sub protocols. But again we come down to the two different approaches - should the sub-protocol be negotiated (in which case your list of sub-protocol proposa= ls makes a lot of sense), or should it be declarative (and the server can only accept or reject). I like negotiation... but then if we negotiate one thing, we should probabl= y negotiate more. So maybe the requirement is to support sub protocols - if a particular solution support negotiation, then great, but it is not actually required? > =C2=A0=C2=A0 REQ. 12:=C2=A0 The WebSocket Client MUST have the ability to= send > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary text content to the server on th= e established > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, in the form of orde= red discrete blocks. > =C2=A0=C2=A0 REQ. 13:=C2=A0 The WebSocket Client MUST have the ability to= send > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary binary content to the server on = the established > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, in the form of orde= red discrete blocks. > --- > #12 and #13 can be combined into one. Suggest rewording #12 as follows an= d > deleting #13: > =C2=A0=C2=A0 REQ. 12:=C2=A0 The WebSocket Client MUST have the ability to= send > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary content to the server on the est= ablished > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, as dictated by the = WebSocket > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sub-protocol in effect. +1 (although it duplicates REQ5 a bit) > --- > 3.2.=C2=A0 WebSocket Server Requirements > =C2=A0=C2=A0 REQ. 14:=C2=A0 The WebSocket Server that accept to set up, w= ith a > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket Client, a communication channel = MUST send back to the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket Client a well defined handshake. > --- > Suggest rewording as follows: > =C2=A0=C2=A0 REQ. 14:=C2=A0 The WebSocket Server that accepts to set up > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a communication channel with a > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebSocket Client MUST use a well defined h= andshake. Why is it a requirement to use a handshake? I think that is implementation detail and this REQ can be dropped. > =C2=A0=C2=A0 REQ. 15:=C2=A0 The WebSocket Server MUST have the ability to= send > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary text content to the client on th= e established > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, in the form of orde= red discrete blocks. > =C2=A0=C2=A0 REQ. 16:=C2=A0 The WebSocket Server MUST have the ability to= send > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary binary content to the client on = the established > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, in the form of orde= red discrete blocks. > --- > #15 and #16 can be combined into one. Suggest rewording #15 as follows an= d > deleting #16: > =C2=A0=C2=A0 REQ. 15:=C2=A0 The WebSocket Server MUST have the ability to= send > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 arbitrary content to the client on the est= ablished > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 communication channel, as dictated by the = WebSocket sub-protocol > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in effect. +1 (although it duplicates REQ5 a bit) > 3.3.=C2=A0 WebSocket Proxies Requirements > =C2=A0=C2=A0 Todo > ---- > Suggest adding the requirement as follows, as nything short of this is no= t practical: > =C2=A0=C2=A0 REQ. TBD: WebSocket MUST work over existing proxies to the s= ame extent > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as HTTP or HTTPS already does. I think that is a bit strong, because I don't think it is possible to work with all existing proxies. How about REQ. TBD: WebSocket SHOULD work over existing proxies that do not imped= e the flow of a websocket communication channel. Ie - if a proxy like haproxy can be made to work with websocket without upgrading the proxy, then we should work with it. cheers From w@1wt.eu Thu Jul 8 22:15:17 2010 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 BFF653A6B67 for ; Thu, 8 Jul 2010 22:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-1.170, 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 cYgYB-SbhTmi for ; Thu, 8 Jul 2010 22:15:15 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A096F3A6855 for ; Thu, 8 Jul 2010 22:15:13 -0700 (PDT) Date: Fri, 9 Jul 2010 07:15:14 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100709051514.GC31430@1wt.eu> References: <615374.65181.qm@web82607.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: draft-ietf-hybi-websocket-requirements@tools.ietf.org, hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 09 Jul 2010 05:15:17 -0000 Greg, I'm adding a precision below. On Fri, Jul 09, 2010 at 10:28:29AM +1000, Greg Wilkins wrote: > > 3.3. WebSocket Proxies Requirements> Todo> ----> Suggest adding the requirement as follows, as nything short of this is not practical:> REQ. TBD: WebSocket MUST work over existing proxies to the same extent> as HTTP or HTTPS already does. > I think that is a bit strong, because I don't think it is possible towork with all existingproxies. How about > REQ. TBD: WebSocket SHOULD work over existing proxies that do not impede the flow of a websocket communication channel. > Ie - if a proxy like haproxy can be made to work with websocketwithout upgradingthe proxy, then we should work with it. We must be careful to always distinguish two points : - proxies - reverse-proxies Proxies are explicit on the client side. The client may very well use the CONNECT method to establish the bidirectionnal tunnel over the proxy, it has worked for many years now. Squid is a good example of such a proxy, where CONNECT already works. However, from my experience, HTTP Upgrade through proxies does not often work. My squid is quite old here (2.6.STABLE13) and does not support it. Some other products I've tried this through did not support it either (some of them being anti-virus proxies). In all cases, the behaviour is very clean because the proxy simply closes the connection after the 101 response, which is easily detected by the client. But I still think the CONNECT method is safer. Reverse proxies are either on the server side, or implemented in any intermediate (eg: a load balancer in front of proxies on the client side, or an HTTP-aware firewall somewhere in the path). Haproxy is such a reverse proxy. Thus it will have to understand the proxy mode if installed in front of client-side proxies (so CONNECT is OK), or to understand the server-side protocol when installed in front of servers (HTTP UPGRADE is already OK). I'm sure most of us are aware of the differences between those two usages, but since I've sometimes confused people myself by employing the term "proxy" to designate a reverse-proxy, I find it better to clarify. Regards, Willy From annevk@opera.com Thu Jul 8 22:37:06 2010 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 E9BF83A6813 for ; Thu, 8 Jul 2010 22:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bZ4pNzsn7T8O for ; Thu, 8 Jul 2010 22:37:05 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id ACCB03A67F2 for ; Thu, 8 Jul 2010 22:37:04 -0700 (PDT) Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o695aqB2008138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jul 2010 05:37:08 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: hybi@ietf.org, "gabriel montenegro" References: <615374.65181.qm@web82607.mail.mud.yahoo.com> Date: Fri, 09 Jul 2010 07:36:57 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software ASA Message-ID: In-Reply-To: <615374.65181.qm@web82607.mail.mud.yahoo.com> User-Agent: Opera Mail/10.70 (Linux) Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 09 Jul 2010 05:37:07 -0000 On Thu, 08 Jul 2010 20:20:15 +0200, gabriel montenegro wrote: > identified both in the HyBi wg input document > [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list > dicussion. > REQ. 1: The WebSocket Protocol MUST run directly on top of a > transport protocol (e.g. TCP, UDP or SCTP, DCCP). > --- > No need to say anything, as the point is that whatever HTTP was > running over should continue to be used after the upgrade. Typically > this is TCP, yes. So how about rewording thus: > REQ. 1: The WebSocket Protocol MUST run directly on top of > the transport over which the initial HTTP handshake was running > (typically TCP). I think the requirement should be removed then. The requirements shouldn't constrain us to a HTTP handshake. > --- > REQ. 2: The WebSocket Protocol MUST be able to handle (send and > receive) messages on top of a TCP data stream connection. > --- > Suggest rewording: > REQ. 2: The WebSocket Protocol MUST be able to handle (send and > receive) messages up to a maximum size (TBD) on top of the > transport > over which the initial HTTP handshake was running (typically TCP). Why should we constrain size in the requirements? > REQ. 11: The WebSocket Client MUST be able to request the server, > during the handshake, to use a specific WebSocket sub-protocol. > --- > Suggest rewording as follows: > REQ. 11: During the handshake ,the WebSocket Client MUST be able > to send one or more WebSocket sub-protocol proposals to the server > so that the server can select one.,This results in the use of a specific > WebSocket sub-protocol. I don't think this is needed. It's also something that can easily be added later if application authors find a need for it. -- Anne van Kesteren http://annevankesteren.nl/ From micheil@brandedcode.com Fri Jul 9 01:13:24 2010 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 9CAC83A6957 for ; Fri, 9 Jul 2010 01:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 J6Lk+RecGgkb for ; Fri, 9 Jul 2010 01:13:23 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 280AF3A687C for ; Fri, 9 Jul 2010 01:13:22 -0700 (PDT) Received: by pvd12 with SMTP id 12so880340pvd.31 for ; Fri, 09 Jul 2010 01:13:22 -0700 (PDT) Received: by 10.114.195.15 with SMTP id s15mr10957748waf.53.1278663202183; Fri, 09 Jul 2010 01:13:22 -0700 (PDT) Received: from [192.168.46.181] (124-170-233-189.dyn.iinet.net.au [124.170.233.189]) by mx.google.com with ESMTPS id n32sm9934719wag.11.2010.07.09.01.13.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 01:13:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Micheil Smith In-Reply-To: Date: Fri, 9 Jul 2010 18:13:18 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <615374.65181.qm@web82607.mail.mud.yahoo.com> To: hybi@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 09 Jul 2010 08:13:24 -0000 I think there's only one change, in what I've read of this thread (since = the message from Gabriel, 9th July 2010) that I could argue against as a protocol = implementor and active maintainer of a near spec-compliant server. The only thing that does stand out is the message size constriants, = which would not be a good idea. If a client sends a message that is too large, then = it is up to the server-side developer to decide if they want to disconnect the = socket for that reason. The second point I find interesting is the sub-protocol negotiation = point, this is something that I think would possibly be a good idea, but may add = unneeded complexity. Also, I am that micheil person from #whatwg on irc. Yours, Micheil Smith -- BrandedCode.com On 09/07/2010, at 3:36 PM, Anne van Kesteren wrote: > On Thu, 08 Jul 2010 20:20:15 +0200, gabriel montenegro = wrote: >> identified both in the HyBi wg input document >> [I-D.hixie-thewebsocketprotocol] and in the HyBi mailing list >> dicussion. >> REQ. 1: The WebSocket Protocol MUST run directly on top of a >> transport protocol (e.g. TCP, UDP or SCTP, DCCP). >> --- >> No need to say anything, as the point is that whatever HTTP was >> running over should continue to be used after the upgrade. Typically >> this is TCP, yes. So how about rewording thus: >> REQ. 1: The WebSocket Protocol MUST run directly on top of >> the transport over which the initial HTTP handshake was running >> (typically TCP). >=20 > I think the requirement should be removed then. The requirements = shouldn't constrain us to a HTTP handshake. >=20 >=20 >> --- >> REQ. 2: The WebSocket Protocol MUST be able to handle (send and >> receive) messages on top of a TCP data stream connection. >> --- >> Suggest rewording: >> REQ. 2: The WebSocket Protocol MUST be able to handle (send and >> receive) messages up to a maximum size (TBD) on top of the = transport >> over which the initial HTTP handshake was running (typically = TCP). >=20 > Why should we constrain size in the requirements? >=20 >=20 >> REQ. 11: The WebSocket Client MUST be able to request the server, >> during the handshake, to use a specific WebSocket sub-protocol. >> --- >> Suggest rewording as follows: >> REQ. 11: During the handshake ,the WebSocket Client MUST be able >> to send one or more WebSocket sub-protocol proposals to the server >> so that the server can select one.,This results in the use of a = specific >> WebSocket sub-protocol. >=20 > I don't think this is needed. It's also something that can easily be = added later if application authors find a need for it. >=20 >=20 > --=20 > Anne van Kesteren > http://annevankesteren.nl/ > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From g_e_montenegro@yahoo.com Fri Jul 9 18:20:16 2010 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 CC0013A695B for ; Fri, 9 Jul 2010 18:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 jn72txKa0iHu for ; Fri, 9 Jul 2010 18:20:12 -0700 (PDT) Received: from web82601.mail.mud.yahoo.com (web82601.mail.mud.yahoo.com [68.142.201.118]) by core3.amsl.com (Postfix) with SMTP id 47FD53A6946 for ; Fri, 9 Jul 2010 18:20:05 -0700 (PDT) Received: (qmail 22989 invoked by uid 60001); 10 Jul 2010 01:20:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278724806; bh=ZcFxS7CUkC+y5JmQH2G9CdJOsOTl3O1x3rvo7dkR3+I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1XSIoN8GQthozXlN+cNTBwh5wjkvKA9Rcr1WLo+zxfh44/fwhl9B5YibIZJdFExEXvggSUD0W3NwknWXpzfhjY7ReaQBHKKu/SnmqOK6xmq9Xzo/Ydel2wSfjSwh3PWTXzcriv5UtZx16l9FU2aNizbHjlK1IopoW6CLb0zwThU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SdWyOi6kqZJ/xobS0uwJIWPxXgsA69ULxqClaHVdwJoP1+AVTV3JNsH6Rr9MYSEMttHpqRqh06YuGG1FtWRrY5qkLVbyHZ6AkLsVHKKK7astiCH4CVhfurF46w5kUTsITCmyKE2V0YPhCZirDRmcOdi5GjrWRJS6r6rPUq8GBB8=; Message-ID: <988448.22680.qm@web82601.mail.mud.yahoo.com> X-YMail-OSG: C7JWlz8VM1luc.ixG.CAV3DzrKdqbBZRqjzvdwGqDAFdEcv PXSdQFM0Td6YGQyO5oXsj3eTl7xSS2qfjZGKacbIrcNZ4h0mPbCwmFQM2ruL Ea_R5iW5JNUFdMRqLRPk2r4bVJPnNt7129zAPa99LgYQOS4IH81zM7eiUhAb M6PuYMPCSBmfg91Y3bR4eHPHLl13xQxjUVIBLw1YtTcoZmKEGGetKbgHfevj ACJvlRWvHJeaCkipWZrhwvMpGsx_reOeBvcYUXInBip1dpmqHDjmuDSvvm7K 7xoV45B4GNAexO184PHJk7StViuCONfBqscltd6OVTkyalYS9WY5KYbehYG4 Hmc8bmwei7Jo- Received: from [131.107.0.78] by web82601.mail.mud.yahoo.com via HTTP; Fri, 09 Jul 2010 18:20:05 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <615374.65181.qm@web82607.mail.mud.yahoo.com> Date: Fri, 9 Jul 2010 18:20:05 -0700 (PDT) From: gabriel montenegro To: Greg Wilkins In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-hybi-websocket-requirements@tools.ietf.org, hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 10 Jul 2010 01:20:16 -0000 Hi Greg and requirements authors,=0A=0A=0APlease find my responses inline..= .=0A=0A=0A----- Original Message ----=0A> From: Greg Wilkins =0A> To: ; gabriel montenegro =0A> Cc: ; hyb= i@ietf.org; draft-ietf-hybi-websocket-requirements@tools.ietf.org=0A> Sent:= Thu, July 8, 2010 5:28:29 PM=0A> Subject: Re: [hybi] comments on draft-iet= f-hybi-websocket-requirements-00=0A> =0A> Gabriel,=0A=0AI'm no longer edito= r of the requirements, but I've commented =0A> below as=0Aan individual.=0A= =0A[gm] sorry to see you go.=0A=0AOn 9 July 2010 04:20, gabriel =0A> monten= egro <> href=3D"mailto:g_e_montenegro@yahoo.com">g_e_montenegro@yahoo.com> = =0A> wrote:=0A=0A> =A0=A0 REQ. 1:=A0 The WebSocket Protocol MUST run direct= ly on top =0A> of a=0A> =A0=A0=A0=A0=A0 transport protocol (e.g.=A0 TCP, UD= P or SCTP, DCCP).=0A> =0A> ---=0A> No need to say anything, as the point is= that whatever HTTP =0A> was=0A> running over should continue to be used af= ter the upgrade. =0A> Typically=0A> this is TCP, yes. So how about rewordin= g thus:=0A> =A0=A0 REQ. =0A> 1:=A0 The WebSocket Protocol MUST run directly= on top of=0A> =A0=A0=A0=A0=A0 the =0A> transport over which the initial HT= TP handshake was running=0A> =A0=A0=A0=A0=A0 =0A> (typically TCP).=0A=0A+1= =0A=0A[gm] Cool.=0A=0A> ---=0A> =A0=A0 REQ. 2:=A0 The =0A> WebSocket Protoc= ol MUST be able to handle (send and=0A> =A0=A0=A0=A0=A0 receive) =0A> messa= ges on top of a TCP data stream connection.=0A> ---=0A> Suggest =0A> reword= ing:=0A> =A0=A0 REQ. 2:=A0 The WebSocket Protocol MUST be able to handle = =0A> (send and=0A> =A0=A0=A0=A0=A0 receive) messages up to a maximum size (= TBD) on top of =0A> the transport=0A> =A0=A0=A0=A0=A0 over which the initia= l HTTP handshake was running =0A> (typically TCP).=0A=0AI don't think we sh= ould mix in size requirements =0A> here.=0A=0A[gm] Perhaps I've misundersto= od what Req. #2 and #3 are for.=0AHow do they differ? Also, both client and= server requirements talk about "ordered discrete blocks"=0A(#12, #13, #15,= #16). I imagine when one talks about blocks, there is some limit on those = at least=0Afor DoS protection but also to be able to interoperate ("what is= the largest block we can exchange?").=0A=0AI also notice that the protocol= draft in section 4.2 (Data Framing) item 3.6 mentions length of the messag= es=0Aand the fact that some lengths may not be reasonable, but no mention a= s to what that value is. =0A=0A> =A0=A0 REQ. 4:=A0 Textual data MUST be enc= oded as =0A> UTF-8.=0A> ---=0A> Good that this only applies to textual data= . But it =0A> is not clear what=0A> "text data" refers to: either metadata = used in =0A> capability negotiation=0A> during the handshake or textual dat= a in the data =0A> stream in the=0A> established communication channel.=0A= =0AAgreed the =0A> reference to textual data is poorly defined.. see below:= =0A=0A=0A> =A0=A0 REQ. =0A> 5:=A0 The protocol MUST be designed to support = different frame=0A> =A0=A0=A0=A0=A0 types =0A> (e.g. binary).=0A> ---=0A> S= uggest changing to different "data types" to =0A> be consistent with REQ 4,= =0A> which uses the expression "textual *data*". So =0A> how about somethin= g like=0A> this:=0A> =A0=A0 REQ. 5:=A0 The protocol MUST be =0A> designed t= o support negotiation among=0A> =A0=A0=A0=A0=A0=A0 multiple possible framin= g =0A> mechanisms (e.g. binary, textual).=0A=0AI think "negotiation" is a l= oaded word =0A> for this protocol, and I think some are=0Avery much opposed= to any negotiation =0A> and prefer a declarative (or assumed)=0Aapproach.= =0A=0A[gm] Ok, others have also tripped on the choice of word here. The wor= d is not as important=0Aas stating what it is that should be supported (we = can worry about the mechanism later).=0A=0AI actually think that =0A> there= is no requirement to support different framing.=0AThe requirement is that = =0A> we must be able to transport both binary and text=0Amessages - if one = framing =0A> mechanism can do both, then great!=A0 So how=0Aabout:=0A=0A=A0= =A0 =0A> REQ. 5:=A0 The protocol MUST be designed to support both binary a= nd=0A=A0 =0A> textual data.=0A=0A[gm] Having the "native" WebSocket wire pr= otocol support both is definitely an improvement over the original version,= yes. But if one wanted to use, say, XMPP over websockets, for that session= there is no need for the native wire=0Aprotocol, so the above is not enoug= h, but perhaps the sub-protocol requirement captures that.=0A=0A=0A=0A=0A= =0A> =A0=A0 REQ. 7:=A0 When sharing host and =0A> "well known" port with HT= TP, the=0A> =A0=A0=A0=A0=A0 WebSocket protocol MUST be HTTP =0A> compatible= until both ends have=0A> =A0=A0=A0=A0=A0 established the WebSocket =0A> pr= otocol.=0A> ---=0A> What is the difference between fully conforming =0A> HT= TP and HTTP compatible?=0A=0AI have long argued that we should require =0A>= "compliance" rather than=0Acompatibility.=0ACompliance implies a more than= =0A> compatibility in that telnet could be said to be=0AHTTP compatible be= cause you =0A> can telnet to port 80 and interact with a HTTP=0Aserver.=A0 = But telnet is =0A> not HTTP compliant, because it can also be used to send= =0Aillegal HTTP.=A0 =0A> =A0 Compliance means that the HTTP conversation ne= eds to be=0Alegal HTTP up =0A> until the websocket communication channel is= established (for=0Awhich I agree =0A> with your extra wording).=0A=0A[gm] = I'm still not clear on the difference, cuz if one's doing black-box testing= then I wouldn't know=0Ahow you've implemented your HTTP stack (heck, it mi= ght be written in perl using a telnet client). And even=0Aa native HTTP sta= ck could be misused, I do agree=0Athat we want whichever word implies a str= onger adherence to HTTP up to the Upgrade. So perhaps we=0Acan simply state= what is desirable instead of relying on the right choice of words. See bel= ow. =0A=0A> Also, to clarify what aspects of the =0A> protocol are being re= ferred to,=0A> I suggest rewording as follows:=0A> =0A> =A0=A0 REQ. 7:=A0 W= hen sharing host and "well known" port with HTTP, the=0A> =A0=A0=A0=A0=A0 = =0A> WebSocket protocol handshake MUST be HTTP compatible until both ends = =0A> have=0A> =A0=A0=A0=A0=A0 established the WebSocket protocol communicat= ion =0A> channel.=0A=0A+1 (specially if we s/compatible/compliant/)=0A=0A[g= m] So to sidestep the compatible/compliant debate, how about this?: =0A=0AR= EQ. 7:=A0 When sharing host and "well known" port with HTTP, the=0A=A0=A0= =A0=A0=A0=A0 WebSocket protocol handshake MUST be indistinguishable from HT= TP until both ends have=0A=A0=A0=A0=A0=A0=A0 established the WebSocket prot= ocol.=0A=0A> =0A> Here's one more requirement:=0A> Req # TBD: WebSocket sub= -protocols MUST be =0A> able to support different=0A> framing and encoding = and be able to reuse =0A> existing security mechanisms=0A> (e.g., upgrading= to a TLS-enabled session =0A> for XMPP).=0A=0AI don't agree with this one.= =A0 Websocket should be a =0A> specific=0Aprotocol, with specific=0Aframing= .=A0 If you want to carry XMPP, =0A> then you need to define a=0Abinding fo= r XMPP to=0Awebsocket framing.=A0 I =0A> think this subprotocol should repr= esent this=0Abinding and not=0Aa different =0A> framing mechanism.=0A=0A[gm= ] In keeping with the goal of providing a TCP-like channel while adding as = little=0Aas possible it would be best if existing components (e.g. XMPP, et= c) could be reused=0Aas they are over TCP. Establishing the end-to-end comm= unication channel via websockets=0Ais great, but I don't see why the endpoi= nt applications or sub-protocols cannot use =0Awhatever framing they are us= ed to and understand after that. That is not to say that there=0Ashould be = one native framing to guarantee interoperability (with support for both tex= t and binary),=0Abut why does it follow that it has to be the *only* one po= ssible? For example, we could call the native =0Awire format and framing th= e "Native" Sub-Protocol with the implication that unless otherwise=0Aspecif= ied, that is the one to use, but still allow for other sub-protocols to use= different framing.=0A=0A=0A> ---=0A> 3.1.=A0 WebSocket Client =0A> Require= ments=0A> =A0=A0 REQ. 9:=A0 The WebSocket Client MUST be able to set up a = =0A> communication=0A> =A0=A0=A0=A0=A0 channel sending to a WebSocket Serve= r a well defined =0A> handshake.=0A> ---=0A> Slight rewording suggested:=0A= > =A0=A0 REQ. 9:=A0 =0A> The WebSocket Client MUST be able to set up a comm= unication=0A> =A0=A0=A0=A0=A0 =0A> channel with a WebSocket Server using a = well defined =0A> handshake.=0A=0A+1=0A=0A[gm] Cool.=0A=0A> =A0=A0 REQ. 11:= =A0 The WebSocket Client MUST be =0A> able to request the server,=0A> =A0= =A0=A0=A0=A0 during the handshake, to use a =0A> specific WebSocket sub-pro= tocol.=0A> ---=0A> Suggest rewording as =0A> follows:=0A> =A0=A0 REQ. 11:= =A0 During the handshake ,the WebSocket Client MUST be =0A> able=0A> to sen= d one or more WebSocket sub-protocol proposals to the =0A> server=0A> so th= at the server can select one.,This results in the use of a =0A> specific=0A= > WebSocket sub-protocol.=0A=0AFirstly I don't think the =0A> requirements = document should actually talk about=0Athe handshake.=A0 =0A> Handshaking is= an implementation detail.=0A=0ASo the requirement should be =0A> just abou= t establishing sub protocols.=0ABut again we come down to the two =0A> diff= erent approaches - should the=0Asub-protocol be negotiated (in which case = =0A> your list of sub-protocol proposals=0Amakes a lot of sense), or should= it be =0A> declarative (and the server can only=0Aaccept or reject).=0A=0A= I like =0A> negotiation... but then if we negotiate one thing, we should = =0A> probably=0Anegotiate more.=0A=0A[gm] I think the proposed wording abov= e is actually what you call=0A"declarative". What is proposed is for the cl= ient to state and the =0Aserver can only accept or reject ("...the server c= an select one..."). =0A=0A=0ASo maybe the requirement is to support sub =0A= > protocols - if a particular=0Asolution support negotiation, then great, b= ut it =0A> is not actually required?=0A=0A[gm] yes, that's fine, the above = wording actually does not=0Ause the word "negotiation".=0A=0A> =A0=A0 REQ. = 12:=A0 The WebSocket Client =0A> MUST have the ability to send=0A> =A0=A0= =A0=A0=A0 arbitrary text content to the server =0A> on the established=0A> = =A0=A0=A0=A0=A0 communication channel, in the form of ordered =0A> discrete= blocks.=0A> =A0=A0 REQ. 13:=A0 The WebSocket Client MUST have the ability = =0A> to send=0A> =A0=A0=A0=A0=A0 arbitrary binary content to the server on = the =0A> established=0A> =A0=A0=A0=A0=A0 communication channel, in the form= of ordered discrete =0A> blocks.=0A> ---=0A> #12 and #13 can be combined i= nto one. Suggest =0A> rewording #12 as follows and=0A> deleting #13:=0A> = =A0=A0 REQ. 12:=A0 The =0A> WebSocket Client MUST have the ability to send= =0A> =A0=A0=A0=A0=A0 arbitrary content =0A> to the server on the establishe= d=0A> =A0=A0=A0=A0=A0 communication channel, as =0A> dictated by the WebSoc= ket=0A> =A0=A0=A0=A0=A0=A0 sub-protocol in =0A> effect.=0A=0A+1=0A=0A(altho= ugh it duplicates REQ5 a bit)=0A=0A[gm] I think=0A=0A> =0A> ---=0A> 3.2.=A0= WebSocket Server Requirements=0A> =A0=A0 REQ. 14:=A0 The =0A> WebSocket Se= rver that accept to set up, with a=0A> =A0=A0=A0=A0=A0 WebSocket Client, a = =0A> communication channel MUST send back to the=0A> =A0=A0=A0=A0=A0 WebSoc= ket Client a =0A> well defined handshake.=0A> ---=0A> Suggest rewording as = =0A> follows:=0A> =A0=A0 REQ. 14:=A0 The WebSocket Server that accepts to s= et =0A> up=0A> =A0=A0=A0=A0=A0 a communication channel with a=0A> =A0=A0=A0= =A0=A0 WebSocket Client =0A> MUST use a well defined handshake.=0A=0A=0AWhy= is it a requirement to use a =0A> handshake?=0AI think that is implementat= ion detail and this REQ can be =0A> dropped.=0A=0A=0A=0A=0A> =A0=A0 REQ. 15= :=A0 The WebSocket Server MUST have the =0A> ability to send=0A> =A0=A0=A0= =A0=A0 arbitrary text content to the client on the =0A> established=0A> =A0= =A0=A0=A0=A0 communication channel, in the form of ordered discrete =0A> bl= ocks.=0A> =A0=A0 REQ. 16:=A0 The WebSocket Server MUST have the ability to = =0A> send=0A> =A0=A0=A0=A0=A0 arbitrary binary content to the client on the= =0A> established=0A> =A0=A0=A0=A0=A0 communication channel, in the form of= ordered discrete =0A> blocks.=0A> ---=0A> #15 and #16 can be combined into= one. Suggest =0A> rewording #15 as follows and=0A> deleting #16:=0A> =A0= =A0 REQ. 15:=A0 The =0A> WebSocket Server MUST have the ability to send=0A>= =A0=A0=A0=A0=A0 arbitrary content =0A> to the client on the established=0A= > =A0=A0=A0=A0=A0 communication channel, as =0A> dictated by the WebSocket = sub-protocol=0A> =A0=A0=A0=A0=A0 in =0A> effect.=0A=0A=0A+1=0A=0A(although = it duplicates REQ5 a bit)=0A=0A[gm] Your proposed rewording for REQ5 does n= ot capture the sub-protocol aspect,=0Aunless we say that the native text/bi= nary support is the implied "Native" sub-protocol.=0AThen Req15 would be al= l that's needed without need for Req5.=0A=0A> =0A> 3.3.=A0 WebSocket Proxie= s Requirements=0A> =A0=A0 Todo=0A> ----=0A> =0A> Suggest adding the require= ment as follows, as nything short of this is not =0A> practical:=0A> =A0=A0= REQ. TBD: WebSocket MUST work over existing proxies to the =0A> same exten= t=0A> =A0=A0=A0=A0=A0 as HTTP or HTTPS already does.=0A=0AI think that is = =0A> a bit strong, because I don't think it is possible to=0Awork with all = =0A> existing=0Aproxies.=A0 =A0 How about=0A=0A=A0 =A0 REQ. TBD: =0A> WebSo= cket SHOULD work over existing proxies that do not impede=0A=A0 =A0 =0A> th= e flow of a websocket communication channel.=0A=0AIe - if a proxy like =0A>= haproxy can be made to work with websocket=0Awithout upgrading=0Athe proxy= , =0A> then we should work with it.=0A=0A[gm] This is more precise, yes. Pe= rhaps saying saying "to the same extent of HTTP" was=0Aoverly optimistic. T= he fact is that after the upgrade, it won't be HTTP any more, so we=0Acan't= realistically expect every proxy to continue working as before, I'm sure s= omething =0Asomewhere will break. Your wording is more realistic.=0A=0Athan= ks,=0A=0AGabriel From g_e_montenegro@yahoo.com Fri Jul 9 18:30:21 2010 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 07AAF3A6949 for ; Fri, 9 Jul 2010 18:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xqm2b9N6Gzbp for ; Fri, 9 Jul 2010 18:30:12 -0700 (PDT) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id 9A0423A6925 for ; Fri, 9 Jul 2010 18:30:09 -0700 (PDT) Received: (qmail 66218 invoked by uid 60001); 10 Jul 2010 01:30:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278725411; bh=Olm1z935MtkSALFcqSAj2AuRjEZvU11wEih1sADLVeE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2cJSOG8FI8bP3MSn/AHsBqhYlCCuK725wnAzhjapBWvdb4xaoZ2FHW/L3l5FnzPHj3j6bUqI57TsRf7UQdytB+b6o6lNm7oboVO6UErgRfmixmrhnSbWrI4FW8xaGuq4AsF5mcIso0J24LJ5L/qLnv9PCrrfT/mTaHcAqz5kXHk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qcIP9XQq4EtkToc28yR3o/CQcTz6pUXLOfFT+ocqN+S7dTxo7NPUednQ9UsFEoY9rjXWxIsDB/sPL/Ks17d9yrD3ltPI+VmlMrbGEe2TDdM4sr3pLw//FQgkQN/GHWFW0ZuSHwE3REo59qIHQfBWMkOJTdyr+/Su7wmfj1cswvc=; Message-ID: <564970.65690.qm@web82607.mail.mud.yahoo.com> X-YMail-OSG: Iz3h.gIVM1lbeM6LSReSYuLQWPabSWRJ6RhGNgAUAQAA4da N8JLbs2eZyr2fIKavxbVAq4HXCDdT2NMWFI.NDleT3TjCoc.Cm9s0oxv20Ff XWByb65ch7nlfasq.i0jrBlJ4uaWrUdZ.Yuu5pSbFCfGUBA1LVUCWdGijemH bPZax5ip_LXSLjVR3ZsdE0O4EOlpqofffhJ5O84qXr6Ok8T7EGgXP_ffh2Dz 4xt09V3zNe5owvsq406l8PiaQRDGmOEDrx4QUUTLoKwvkE4JNxJZGpxMXeMA nJwKo3L3Oa5IvuOFcR0Fal4ogIVcfP5_kynFttchAW.IXEk2z4G9njDuxfmd DdvxO6iVgKTPwRTzIfzVa4_ZDlA-- Received: from [131.107.0.78] by web82607.mail.mud.yahoo.com via HTTP; Fri, 09 Jul 2010 18:30:10 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <615374.65181.qm@web82607.mail.mud.yahoo.com> Date: Fri, 9 Jul 2010 18:30:10 -0700 (PDT) From: gabriel montenegro To: Anne van Kesteren , hybi@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 10 Jul 2010 01:30:21 -0000 Hi Anne,=0A=0Aplease see my comments inline...=0A=0A=0A=0A> On Thu, 08 Jul = 2010 20:20:15 +0200, gabriel montenegro <> ymailto=3D"mailto:g_e_montenegro= @yahoo.com" =0A> href=3D"mailto:g_e_montenegro@yahoo.com">g_e_montenegro@ya= hoo.com> =0A> wrote:=0A>=A0 =A0 identified both in the HyBi wg input =0A> d= ocument=0A>=A0 =A0 [I-D.hixie-thewebsocketprotocol] and in the HyBi =0A> ma= iling list=0A>=A0 =A0 dicussion.=0A>=A0 =A0 REQ. 1:=A0 =0A> The WebSocket P= rotocol MUST run directly on top of a=0A>=A0 =A0 =A0 =0A> transport protoco= l (e.g.=A0 TCP, UDP or SCTP, DCCP).=0A> ---=0A> No =0A> need to say anythin= g, as the point is that whatever HTTP was=0A> running =0A> over should cont= inue to be used after the upgrade. Typically=0A> this is =0A> TCP, yes. So = how about rewording thus:=0A>=A0 =A0 REQ. 1:=A0 The =0A> WebSocket Protocol= MUST run directly on top of=0A>=A0 =A0 =A0 the =0A> transport over which t= he initial HTTP handshake was running=0A>=A0 =A0 =0A> =A0 (typically TCP).= =0A=0AI think the requirement should be removed then. =0A> The requirements= shouldn't constrain us to a HTTP handshake.=0A=0A=0A[gm] Hmmm... I was und= er the impression that the whole point was to =0Astart with HTTP and then v= ia the Upgrade directive move into the=0AWebSocket protocol. Or are you say= ing that there might be other ways=0Ato start other than HTTP?=0A=0A> =0A> = ---=0A>=A0 =A0 REQ. 2:=A0 The WebSocket Protocol MUST be able to =0A> handl= e (send and=0A>=A0 =A0 =A0 receive) messages on top of a TCP =0A> data stre= am connection.=0A> ---=0A> Suggest rewording:=0A>=A0 =0A> =A0 REQ. 2:=A0 Th= e WebSocket Protocol MUST be able to handle (send =0A> and=0A>=A0 =A0 =A0 r= eceive) messages up to a maximum size (TBD) on =0A> top of the transport=0A= >=A0 =A0 =A0 over which the initial HTTP =0A> handshake was running (typica= lly TCP).=0A=0AWhy should we constrain size in =0A> the requirements?=0A=0A= [gm] Please see my response to Greg's message.=0A=0A>=A0 =A0 REQ. 11:=A0 Th= e WebSocket =0A> Client MUST be able to request the server,=0A>=A0 =A0 =A0 = during =0A> the handshake, to use a specific WebSocket sub-protocol.=0A> --= -=0A> =0A> Suggest rewording as follows:=0A>=A0 =A0 REQ. 11:=A0 During the = =0A> handshake ,the WebSocket Client MUST be able=0A> to send one or more = =0A> WebSocket sub-protocol proposals to the server=0A> so that the server = can =0A> select one.,This results in the use of a specific=0A> WebSocket = =0A> sub-protocol.=0A=0AI don't think this is needed. It's also something t= hat can =0A> easily be added later if application authors find a need for = =0A> it.=0A=0A[gm] Are you disagreeing with the proposed rewording or with = the original=0Awording?:=0A=0A"=A0=A0 REQ. 11:=A0 The WebSocket Client MUST= be able to request the server,=0A=A0=A0=A0=A0=A0 during the handshake, to = use a specific WebSocket sub-protocol.=0A"=0A=0AThe rewording did not chang= e the basic requirement for sub-protocol support, it=0Awas just adding more= text as to how that might happen.=0A=0Athanks,=0A=0AGabriel=0A From g_e_montenegro@yahoo.com Fri Jul 9 18:35:50 2010 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 B599D3A6835 for ; Fri, 9 Jul 2010 18:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2WoMhPrC+LXw for ; Fri, 9 Jul 2010 18:35:49 -0700 (PDT) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id C0F443A67A4 for ; Fri, 9 Jul 2010 18:35:49 -0700 (PDT) Received: (qmail 96430 invoked by uid 60001); 10 Jul 2010 01:35:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278725752; bh=uLLduMe2xVXBd3SId+jJunva8LWbENHrZb2ypGC90YI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hmG1y3H+qR5afHjgANDKY0MwqHLdLGRo+k6GSqMSoMsF4na8X9V496W9FepzXGcXU4ZHq62DGlAKsuC48VWAc84N6Yqrp4gHZiKe6+fWKt5TTtQCT+8mOXTiCrIHpe6jNAPA1mJsJepY002GTcxaSBLjauUJX74DE8gAPrf3+8I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=d6LIWnJ8/C3aVKYvCtaxdHOk8+Ff0Ik8PzIPUIJ5NeOpvrQyYwXpmR+eekVGkxe4EJ19nXtyfzLwnae434PUGqfzQKKOdg9Ja3kwqe8fcChe70pi9sX+t689g0al1IiOGZ+MUUPxBh6KrrCRDOA+AXn1RFe64U1RObRHSv+hI20=; Message-ID: <593626.96270.qm@web82602.mail.mud.yahoo.com> X-YMail-OSG: M_WFnWMVM1k0krCXKUBQfXId1ktTJaPvU4v0ImK16BsYKX. _i89MRp5OUiiRhWWHdBzlaFxx6YMiITcTlKyZYVH.vKJ7t7r59KV6MJDuEh6 dZAALqunMWMHPhjvIWCZXb0im3GR5kSqL1UdnIl3kNk5OTmVuwDgu0CgVY5e 3q6_xAWSueKeqoDduUEaeoI.lfDrqTBpApKaZnkWdu9sDv3dKSkZk2fqlay5 5ztFP64wgSHsm2g1jEsLW2xy08XSD3ebSYep5UW4419IJ.gG02xBwouZsOgi HdgvhQUi1S0VDBDKHDKp4mE_bfGusE2jMCVdghbpgyv8f9yGUydagEw-- Received: from [131.107.0.78] by web82602.mail.mud.yahoo.com via HTTP; Fri, 09 Jul 2010 18:35:52 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <615374.65181.qm@web82607.mail.mud.yahoo.com> Date: Fri, 9 Jul 2010 18:35:52 -0700 (PDT) From: gabriel montenegro To: Micheil Smith , hybi@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 10 Jul 2010 01:35:50 -0000 Hi Micheil,=0A=0APlease see inline...=0A=0A=0A=0A----- Original Message ---= -=0A> I think there's only one change, in what I've read of this thread (si= nce the =0A> message=0Afrom Gabriel, 9th July 2010) that I could argue agai= nst as a protocol =0A> implementor=0Aand active maintainer of a near spec-c= ompliant server.=0A=0AThe =0A> only thing that does stand out is the messag= e size constriants, which =0A> would=0Anot be a good idea. If a client send= s a message that is too large, then =0A> it is up to=0Athe server-side deve= loper to decide if they want to disconnect =0A> the socket for that=0Areaso= n.=0A=0A[gm] Please see my response to Greg's message on this topic. =0AOne= thing that comes to mind is what if it's a legitimate client trying to fig= ure out=0Awhat the largest message to the server is. finding this out by fa= cing a series of=0Asocket disconnects can be tedious.=0A=0AThe second point= I find interesting is the =0A> sub-protocol negotiation point, this is=0As= omething that I think would possibly =0A> be a good idea, but may add unnee= ded=0Acomplexity.=0A=0A[gm] Is this because of the unfortunate use of the w= ord "negotiation"?=0A=0AThe original wording in the draft alrady called for= sub-protocol support thus:=0A=0A=A0=A0 REQ. 11:=A0 The WebSocket Client MU= ST be able to request the server,=0A=A0=A0=A0=A0=A0 during the handshake, t= o use a specific WebSocket sub-protocol.=0A=0Athe proposed rewording just c= alled out the fact that the client proposal =0Amight involve more than one = sub-protocol, but the server would only choose=0Aone. This is exactly how U= pgrade works in HTTP1.1 already.=0A=0Athanks,=0A=0AGabriel From annevk@opera.com Fri Jul 9 22:57:38 2010 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 42B103A6907 for ; Fri, 9 Jul 2010 22:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fNysHyDnYCDg for ; Fri, 9 Jul 2010 22:57:37 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id D31603A68B6 for ; Fri, 9 Jul 2010 22:57:36 -0700 (PDT) Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o6A5vOA7024302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jul 2010 05:57:40 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: hybi@ietf.org, "gabriel montenegro" References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> Date: Sat, 10 Jul 2010 07:57:25 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software ASA Message-ID: In-Reply-To: <564970.65690.qm@web82607.mail.mud.yahoo.com> User-Agent: Opera Mail/10.70 (Linux) Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 10 Jul 2010 05:57:38 -0000 On Sat, 10 Jul 2010 03:30:10 +0200, gabriel montenegro wrote: > [gm] Hmmm... I was under the impression that the whole point was to > start with HTTP and then via the Upgrade directive move into the > WebSocket protocol. Or are you saying that there might be other ways > to start other than HTTP? Yes, but mostly I'm saying that the requirements document should not constrain the design to this level of detail. >> Why should we constrain size in >> the requirements? > > [gm] Please see my response to Greg's message. Please see above. :-) >> Suggest rewording as follows: >> REQ. 11: During the >> handshake ,the WebSocket Client MUST be able >> to send one or more >> WebSocket sub-protocol proposals to the server >> so that the server can >> select one.,This results in the use of a specific >> WebSocket >> sub-protocol. > > I don't think this is needed. It's also something that can > easily be added later if application authors find a need for > it. > > [gm] Are you disagreeing with the proposed rewording or with the original > wording?: > > " REQ. 11: The WebSocket Client MUST be able to request the server, > during the handshake, to use a specific WebSocket sub-protocol. > " > > The rewording did not change the basic requirement for sub-protocol > support, it was just adding more text as to how that might happen. The rewording suggests the client transmits one or more sub-protocols. I don't think we necessarily need to go there (too complex for v1 and probably not needed at all) and the requirements document should not constrain that. Having said that, I'm not even sure it makes sense to talk about sub-protocols in the requirements document. Requirements should be high-level. -- Anne van Kesteren http://annevankesteren.nl/ From w@1wt.eu Fri Jul 9 23:38:22 2010 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 DA08F3A67B4 for ; Fri, 9 Jul 2010 23:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=-1.385, 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 xRDqnWhbgIbl for ; Fri, 9 Jul 2010 23:38:22 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id BC74E3A6783 for ; Fri, 9 Jul 2010 23:38:21 -0700 (PDT) Date: Sat, 10 Jul 2010 08:38:25 +0200 From: Willy Tarreau To: Anne van Kesteren Message-ID: <20100710063825.GB8207@1wt.eu> References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 10 Jul 2010 06:38:23 -0000 On Sat, Jul 10, 2010 at 07:57:25AM +0200, Anne van Kesteren wrote: > On Sat, 10 Jul 2010 03:30:10 +0200, gabriel montenegro > wrote: > >[gm] Hmmm... I was under the impression that the whole point was to > >start with HTTP and then via the Upgrade directive move into the > >WebSocket protocol. Or are you saying that there might be other ways > >to start other than HTTP? > > Yes, but mostly I'm saying that the requirements document should not > constrain the design to this level of detail. But the original one is (unfortunately) even much more detailed. So maybe what should be done is to detail only the WebSocket protocol after the Upgrade, ensuring it works on top of raw TCP without the HTTP Upgrade, then add a paragraph explaining how to use it after an HTTP Upgrade when the port is shared. And after all, that becomes logical and clear. We could state that by default, the WS protocol consists in the framing we currently see after the Upgrade. Clients explicitly talking to port 80 SHOULD use the HTTP Upgrade method. Those passing through proxies must also use the CONNECT method first (then either raw proto or HTTP upgrade depending on the port). That would leave all combinations possible and an easy way for the client to know which one to pick. And after all, that's precisely what RFC2817 already suggests for TLS over HTTP. Regards, Willy From salvatore.loreto@ericsson.com Sat Jul 10 03:25:54 2010 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 4050D3A6993 for ; Sat, 10 Jul 2010 03:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 c8J17XOoGIgJ for ; Sat, 10 Jul 2010 03:25:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3AC4F3A6972 for ; Sat, 10 Jul 2010 03:25:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-3d-4c384ab2bc13 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C4.19.10125.2BA483C4; Sat, 10 Jul 2010 12:25:54 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Jul 2010 12:25:53 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Jul 2010 12:25:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9211C27C2 for ; Sat, 10 Jul 2010 13:25:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5BDF74FC00 for ; Sat, 10 Jul 2010 13:25:53 +0300 (EEST) Received: from cs78166197.pp.htv.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 044954FBFF for ; Sat, 10 Jul 2010 13:25:52 +0300 (EEST) Message-ID: <4C384AB0.6000909@ericsson.com> Date: Sat, 10 Jul 2010 13:25:52 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 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-OriginalArrivalTime: 10 Jul 2010 10:25:53.0899 (UTC) FILETIME=[46C8BBB0:01CB201A] X-Brightmail-Tracker: AAAAAA== Subject: [hybi] draft Agenda: IETF78 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, 10 Jul 2010 10:25:54 -0000 Hi Folks, here the draft agenda for Anaheim: Agenda: - Administrative / Agenda bash (Chairs, 10') - Way of working, how to measure consensus, (Chairs, 20') drafts ownership - Requirements: open discussion on the Active tickets (?, 30') http://trac.tools.ietf.org/wg/hybi/trac/report/1 - Design discussion for WebSocket SubProtocols (?, 60') Please note that the agenda is still under discussion, so expect changes. If you have any suggestion, please send it to the co-chairs. cheers /Sal From g_e_montenegro@yahoo.com Mon Jul 12 02:48:39 2010 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 16B583A683C for ; Mon, 12 Jul 2010 02:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 Te362zTjNYF9 for ; Mon, 12 Jul 2010 02:48:35 -0700 (PDT) Received: from web82601.mail.mud.yahoo.com (web82601.mail.mud.yahoo.com [68.142.201.118]) by core3.amsl.com (Postfix) with SMTP id 6C7983A6903 for ; Mon, 12 Jul 2010 02:48:34 -0700 (PDT) Received: (qmail 97222 invoked by uid 60001); 12 Jul 2010 09:48:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278928121; bh=WBYApOaLQY42D1kvo857NOqOK6AAaqmG4aG+Mg2iPIk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Shp89otLjTtUtz2D6I30xPPg1dKyU8J8ovi5/rTmDBQYyd6BtlLCvdeyJVVifz2QRQY8y2FY36DGYHZZPE+sfu8UhutfQfSJLspdMAwXJProdFUaWP0sW1eOeZF8Az0ssITX5k/u+9PubkfAC+Vtn7hJ8uS3cNBgQeu7q6VWSaA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LTW7/eNPHr6Qq0MHqStaVwmx0geyKcIS9G25QI6k/xw2ZgsjdJOfRVwW9TnqwuY9i2xF1CRh8CMQSOumer0MsllZt5Czwiv8yEXw2F/RK+DT856h57mlV8n7S4XU7Yu2IbBHcM94SbtKKVUT4nYGOd5XvjuMXI9SQQlAPI50rk4=; Message-ID: <814698.93763.qm@web82601.mail.mud.yahoo.com> X-YMail-OSG: H87mIugVM1lUZ0WKU_jULuXFqD.IN9GH535wiAMqktBhKS. ZRnXfo5pZS29XbEm0vZDIg0WML8hOS5jen2gqQDyJxZqDnN0gtj9S2ciAsy_ hk5sC2Na2W1v8lMMkx4iTvOs5g3Jror9rUMaVB1uPpiG4CZ9ltk.e0ZUVodQ Zg6ayp.eolomPN1Ws0.jemEI5DCDsq6SNhsE1GrJgtI9_om2QlNiVfYSkxf. rrR0JS2osEqO0njrZBMaVocFfKvD_4RqWu4hfPl5vAULJl_Typ.bSJNEddIX n2yqydOOrTmkRxZpKSCzslQF2ohh_eLz.ixNaIB_A2e.mi1iSxKzrf0dT7YS E Received: from [71.197.227.220] by web82601.mail.mud.yahoo.com via HTTP; Mon, 12 Jul 2010 02:48:41 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> Date: Mon, 12 Jul 2010 02:48:41 -0700 (PDT) From: gabriel montenegro To: Anne van Kesteren , hybi@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 12 Jul 2010 09:48:39 -0000 Hi Anne,=0A=0A=0A> From: Anne van Kesteren =0A> [gm] Hmmm= ... I was under the impression that the whole point was =0A> to=0A> start w= ith HTTP and then via the Upgrade directive move into =0A> the=0A> WebSocke= t protocol. Or are you saying that there might be other =0A> ways=0A> to st= art other than HTTP?=0A=0A> Yes, but mostly I'm saying that =0A> the requir= ements document should not constrain the design to this level of =0A> detai= l.=0A=0A[gm] I think it is appropriate, given that we're supposed to be wor= king on what=0Athe charter set out to do:=0A=0A"=A0 The Hypertext-Bidirecti= onal (HyBi) working group will seek=0A=A0 standardization of one approach t= o maintain bidirectional=0A=A0 communications between the HTTP client, serv= er and intermediate=0A=A0 entities, which will provide more efficiency comp= ared to the current=0A=A0 use of hanging requests.=0A"=0A=0AThat seems pret= ty clear about HTTP usage. =0A=0A>> Why should we constrain size in=0A>> th= e =0A> requirements?=0A> =0A> [gm] Please see my response to Greg's =0A> me= ssage.=0A=0APlease see above. :-)=0A=0A[gm] Not sure the above was specific= ally related to the size discussion, so perhaps=0AI'm missing something.=0A= =0A>> Suggest rewording as =0A> follows:=0A>>=A0 =A0 REQ. 11:=A0 During the= =0A>> =0A> handshake ,the WebSocket Client MUST be able=0A>> to send one or= =0A> more=0A>> WebSocket sub-protocol proposals to the server=0A>> so =0A>= that the server can=0A>> select one.,This results in the use of a =0A> spe= cific=0A>> WebSocket=0A>> sub-protocol.=0A> =0A> I =0A> don't think this is= needed. It's also something that can=0A> easily be added =0A> later if app= lication authors find a need for=0A> it.=0A> =0A> [gm] =0A> Are you disagre= eing with the proposed rewording or with the original=0A> =0A> wording?:=0A= > =0A> "=A0 REQ. 11:=A0 The WebSocket Client MUST be =0A> able to request t= he server,=0A>=A0 =A0 =A0 during the handshake, to =0A> use a specific WebS= ocket sub-protocol.=0A> "=0A> =0A> The rewording =0A> did not change the ba= sic requirement for sub-protocol support, it was just =0A> adding more text= as to how that might happen.=0A=0AThe rewording suggests the =0A> client t= ransmits one or more sub-protocols. I don't think we necessarily need to = =0A> go there (too complex for v1 and probably not needed at all) and the = =0A> requirements document should not constrain that. Having said that, I'm= not even =0A> sure it makes sense to talk about sub-protocols in the requi= rements document. =0A> Requirements should be high-level.=0A=0AThere was so= me discussion with Greg about this. There is some overlap with=0AReq.5 whic= h does not actually talk about sub-protocols. That term is not as=0Aimporta= nt as somehow capturing that different framings should be allowed=0A(with o= ne native format for interoperability).=0A=0Athanks,=0A=0AGabriel=0A From annevk@opera.com Mon Jul 12 03:10:33 2010 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 C36993A6912 for ; Mon, 12 Jul 2010 03:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7BZWXqtmbiQB for ; Mon, 12 Jul 2010 03:10:31 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 527263A6903 for ; Mon, 12 Jul 2010 03:10:31 -0700 (PDT) Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o6CAAMrb008153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jul 2010 10:10:37 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: hybi@ietf.org, "gabriel montenegro" References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <814698.93763.qm@web82601.mail.mud.yahoo.com> Date: Mon, 12 Jul 2010 12:10:22 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software ASA Message-ID: In-Reply-To: <814698.93763.qm@web82601.mail.mud.yahoo.com> User-Agent: Opera Mail/10.70 (Linux) Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 12 Jul 2010 10:10:33 -0000 On Mon, 12 Jul 2010 11:48:41 +0200, gabriel montenegro wrote: >> Yes, but mostly I'm saying that >> the requirements document should not constrain the design to this level >> of detail. > > [gm] I think it is appropriate, given that we're supposed to be working > on what the charter set out to do: > > " 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. > " > > That seems pretty clear about HTTP usage. Not to me. The main reason we are discussing what "HTTP compatible" means and how the "HTTP handshake" ought to look is because someone at IANA thought WebSocket should share a port with HTTP. It has nothing much to do with the charter. And frankly, it seems like things might be much easier if we did not share a port with HTTP. > [gm] Not sure the above was specifically related to the size discussion, > so perhaps I'm missing something. Effectively, too much detail for the requirements document. > There was some discussion with Greg about this. There is some overlap > with Req.5 which does not actually talk about sub-protocols. That term > is not as important as somehow capturing that different framings should > be allowed > (with one native format for interoperability). That is directly contrary to the draft proposal we have today. It only allows clients to use frames that are defined in the specification. -- Anne van Kesteren http://annevankesteren.nl/ From g_e_montenegro@yahoo.com Mon Jul 12 03:19:38 2010 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 5F75E3A6828 for ; Mon, 12 Jul 2010 03:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 CvYkjkSeJiP2 for ; Mon, 12 Jul 2010 03:19:37 -0700 (PDT) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id 8A05B3A6817 for ; Mon, 12 Jul 2010 03:19:37 -0700 (PDT) Received: (qmail 62578 invoked by uid 60001); 12 Jul 2010 10:19:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278929982; bh=jarCzlE9KUC8JrnTgRcuPuXLRqPE1dZ5n7GPR//rqAk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZiwCPGGeHFoCR0gyxKO6cZfKRWKjApt5nJ50kj0Z60lHIBncN2spyqH5Gl3UYOkH6hvUESi/yV7Cl/1wOMolJlAFWUwDqrjlbc2hWKgWOoJDgnYb/QZ1/cvZEFuUjZAszT1u3qEhEiPwOlZPOmeU+3nSxVJKI5iEfhv9sEfwH38= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hCqXptCrJ+4eblXLpfMUyMqZuis1iIftTKSM5iqHV8uXrF0GGpdJwtbELggjpdnSbnRjgEcbpPZluQkXpVTkCtzsgliaF4we4Go7ARWelJfDKHsXE3YZvslj4jGzVU5T2teKkda1V+y4ECKwgSlBJZ6lZ0U+ORgnJ2xK1VXbP4M=; Message-ID: <478779.60829.qm@web82604.mail.mud.yahoo.com> X-YMail-OSG: dcxaXDgVM1nUOXNnattDgZ8nMhNvHqrwlkxuAJzheyFxzBs YZHbyAXK6Nyu7Sd67eq9eR2k3siHr9FGEPQE8whg8bnYx4GD5uIfgpy3ipqU FK2C9diBTDz6PIbmvI9f3xhygTgfc8qgNtGqedfIWTPtI0a_Ns9xvghw28Qt BPJPh08tQEisxLw2QByBxJwEdgc08HKktSWmFD2Iugj05ne1K4OsBfylTnna a2ELkGpfumV_sPphqlxAbQRPD6W0ieN55SUfV0Uo96VLr9MmqBnZjfMO2o5P bfRQO8hs91gQTZ9_e2u5ndLwaY9duNf_wPkUe3dkvM4R48Zcu6SBZX4K.jut ksX5l6WZaoGtDq7SyQVQvtA-- Received: from [71.197.227.220] by web82604.mail.mud.yahoo.com via HTTP; Mon, 12 Jul 2010 03:19:42 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <20100710063825.GB8207@1wt.eu> Date: Mon, 12 Jul 2010 03:19:42 -0700 (PDT) From: gabriel montenegro To: Willy Tarreau , Anne van Kesteren In-Reply-To: <20100710063825.GB8207@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 12 Jul 2010 10:19:38 -0000 Hi Willy, Practically speaking, ports 80 and 443 are what will allow websocket connectivity to work, but I see what you mean. Yes, specifying along the lines of RFC2817 might make sense. ----- Original Message ---- > From: Willy Tarreau > To: ; Anne van Kesteren > Cc: ; hybi@ietf.org; gabriel montenegro > Sent: Fri, July 9, 2010 11:38:25 PM > Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 > > On Sat, Jul 10, 2010 at 07:57:25AM +0200, Anne van Kesteren wrote: > On > Sat, 10 Jul 2010 03:30:10 +0200, gabriel montenegro > <> ymailto="mailto:g_e_montenegro@yahoo.com" > href="mailto:g_e_montenegro@yahoo.com">g_e_montenegro@yahoo.com> > wrote: > >[gm] Hmmm... I was under the impression that the whole point > was to > >start with HTTP and then via the Upgrade directive move into > the > >WebSocket protocol. Or are you saying that there might be other > ways > >to start other than HTTP? > > Yes, but mostly I'm > saying that the requirements document should not > constrain the design to > this level of detail. But the original one is (unfortunately) even much > more detailed. So maybe what should be done is to detail only the WebSocket > protocol after the Upgrade, ensuring it works on top of raw TCP without > the HTTP Upgrade, then add a paragraph explaining how to use it after > an HTTP Upgrade when the port is shared. And after all, that becomes > logical and clear. We could state that by default, the WS protocol consists > in the framing we currently see after the Upgrade. Clients explicitly talking > to port 80 SHOULD use the HTTP Upgrade method. Those passing through proxies > must also use the CONNECT method first (then either raw proto or HTTP > upgrade depending on the port). That would leave all combinations > possible and an easy way for the client to know which one to pick. And > after all, that's precisely what RFC2817 already suggests for TLS over > HTTP. Regards, Willy From w@1wt.eu Mon Jul 12 03:27:22 2010 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 D1C1E3A6B2B for ; Mon, 12 Jul 2010 03:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=-1.247, 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 bAm4rBggSNlc for ; Mon, 12 Jul 2010 03:27:22 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 877993A67A5 for ; Mon, 12 Jul 2010 03:27:21 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6CARPap007583; Mon, 12 Jul 2010 12:27:25 +0200 Date: Mon, 12 Jul 2010 12:27:25 +0200 From: Willy Tarreau To: Anne van Kesteren Message-ID: <20100712102725.GA6953@1wt.eu> References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <814698.93763.qm@web82601.mail.mud.yahoo.com> 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: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 12 Jul 2010 10:27:22 -0000 On Mon, Jul 12, 2010 at 12:10:22PM +0200, Anne van Kesteren wrote: > On Mon, 12 Jul 2010 11:48:41 +0200, gabriel montenegro > wrote: > >>Yes, but mostly I'm saying that > >>the requirements document should not constrain the design to this level > >>of detail. > > > >[gm] I think it is appropriate, given that we're supposed to be working > >on what the charter set out to do: > > > >" 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. > >" > > > >That seems pretty clear about HTTP usage. > > Not to me. The main reason we are discussing what "HTTP compatible" means > and how the "HTTP handshake" ought to look is because someone at IANA > thought WebSocket should share a port with HTTP. It has nothing much to do > with the charter. And frankly, it seems like things might be much easier > if we did not share a port with HTTP. If it does not share the port, then it will not replace existing protocols ! Also there are good reasons for sharing ports : - you can't reasonably assign new well-known ports, since most visitors from enterprise networks won't be able to access them for a long time, thus limiting adoption. - expecting a new address to be assigned for each service is not practical for shared hosting providers who manage hundreds or thousands of customers on shared equipments, all routed on the HTTP Host header only. Clearly those ones will not start assigning a dedicated IP to every customer that asks for one just for WebSocket. - in many environments there will be a need for Host-based forwarding or even cookie-based server stickiness. This is already possible on other HTTP-based mechanisms, and will be required for newcomers if the intent is to make long-polling disappear. The fact that HTTP compliance is required might be the problem though. I'd prefer to see the protocol described as the part after the HTTP handshake, and simply state that people who want to use it over HTTP will just have to perform the HTTP handshake first. Check RFC2817, it explains the same principle for TLS over HTTP. This leaves a large degree of freedom for implementers, allows for less overhead for those who don't intend to share a port with HTTP, and allows for higher accessibility for those who can't proceed differently. In my opinion, the HTTP handshake should just be a paragraph in the spec, not 90% of the spec. Regards, Willy From julian.reschke@gmx.de Mon Jul 12 04:06:18 2010 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 AD8133A690A for ; Mon, 12 Jul 2010 04:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.443, 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 hes9fHJNXQ2I for ; Mon, 12 Jul 2010 04:06:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 04CFB3A67EF for ; Mon, 12 Jul 2010 04:06:16 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2010 11:06:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.113]) [217.91.35.233] by mail.gmx.net (mp055) with SMTP; 12 Jul 2010 13:06:23 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18u7FkcGnAuDKeXINWQ32gAuNs5f8T5bBXW6568l9 lS1X6uvYLWCTGx Message-ID: <4C3AF72E.6070001@gmx.de> Date: Mon, 12 Jul 2010 13:06:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Anne van Kesteren References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <814698.93763.qm@web82601.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 12 Jul 2010 11:06:18 -0000 On 12.07.2010 12:10, Anne van Kesteren wrote: > ... > Not to me. The main reason we are discussing what "HTTP compatible" > means and how the "HTTP handshake" ought to look is because someone at > IANA thought WebSocket should share a port with HTTP. It has nothing > much to do with the charter. And frankly, it seems like things might be > much easier if we did not share a port with HTTP. > ... Was IANA actually asked? When? Why would *they* care, being just ther registry? What should be relevant is the IETF consensus. Best regards, Julian From julian.reschke@gmx.de Tue Jul 13 02:20:02 2010 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 2E6D03A6A42 for ; Tue, 13 Jul 2010 02:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-2.400, 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 QjrmjX1r5dnm for ; Tue, 13 Jul 2010 02:20:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 515333A6956 for ; Tue, 13 Jul 2010 02:20:00 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2010 09:20:08 -0000 Received: from p508FE44B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.228.75] by mail.gmx.net (mp008) with SMTP; 13 Jul 2010 11:20:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19QZfcNR9BQFZVFZ5vNcRLxFDVn06fxAdffEFXULz VTbslJPuyzCzUW Message-ID: <4C3C2FBA.6090904@gmx.de> Date: Tue, 13 Jul 2010 11:19:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Salvatore Loreto References: <4C384AB0.6000909@ericsson.com> In-Reply-To: <4C384AB0.6000909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] draft Agenda: IETF78 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, 13 Jul 2010 09:20:02 -0000 On 10.07.2010 12:25, Salvatore Loreto wrote: > ... > - Way of working, how to measure consensus, (Chairs, 20') > drafts ownership > ... Will we have the relevant people either in the room, or online? Otherwise, it might be better to start the discussion right away on the mailing list. Best regards, Julian From s.striker@striker.nl Tue Jul 13 02:31:48 2010 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 A17233A6813 for ; Tue, 13 Jul 2010 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 l-kn16t15+FX for ; Tue, 13 Jul 2010 02:31:47 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 366173A68CC for ; Tue, 13 Jul 2010 02:31:46 -0700 (PDT) Received: by bwz7 with SMTP id 7so3480324bwz.31 for ; Tue, 13 Jul 2010 02:31:52 -0700 (PDT) Received: by 10.204.162.207 with SMTP id w15mr2627572bkx.63.1279013512073; Tue, 13 Jul 2010 02:31:52 -0700 (PDT) MIME-Version: 1.0 Sender: s.striker@striker.nl Received: by 10.204.100.65 with HTTP; Tue, 13 Jul 2010 02:31:31 -0700 (PDT) In-Reply-To: References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <814698.93763.qm@web82601.mail.mud.yahoo.com> From: Sander Striker Date: Tue, 13 Jul 2010 11:31:31 +0200 X-Google-Sender-Auth: NsyDo00kh7TxlrS5ZCPkiReUUv0 Message-ID: To: Anne van Kesteren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 13 Jul 2010 09:31:48 -0000 On Mon, Jul 12, 2010 at 12:10 PM, Anne van Kesteren wrot= e: > On Mon, 12 Jul 2010 11:48:41 +0200, gabriel montenegro > wrote: >>> >>> Yes, but mostly I'm saying that >>> the requirements document should not constrain the design to this level >>> of detail. >> >> [gm] I think it is appropriate, given that we're supposed to be working = on >> what the charter set out to do: >> >> " =A0The Hypertext-Bidirectional (HyBi) working group will seek >> =A0standardization of one approach to maintain bidirectional >> =A0communications between the HTTP client, server and intermediate >> =A0entities, which will provide more efficiency compared to the current >> =A0use of hanging requests. >> " >> >> That seems pretty clear about HTTP usage. > > Not to me. The main reason we are discussing what "HTTP compatible" means > and how the "HTTP handshake" ought to look is because someone at IANA > thought WebSocket should share a port with HTTP. It has nothing much to d= o > with the charter. And frankly, it seems like things might be much easier = if > we did not share a port with HTTP. Come again? Reading the threads here on this very list, the main reason was reach. Arbitrary ports are not likely to be reachable through firewalls. I thought that this was the reason Websocket wanted to "piggyback" on HTTP. Reasons like "someone at IANA said" seem a bit awkward. I'd really like to see IANA's official response if that is the real reason. Cheers, Sander >> [gm] Not sure the above was specifically related to the size discussion, >> so perhaps I'm missing something. > > Effectively, too much detail for the requirements document. > > >> There was some discussion with Greg about this. There is some overlap wi= th >> Req.5 which does not actually talk about sub-protocols. That term is not= as >> important as somehow capturing that different framings should be allowed >> (with one native format for interoperability). > > That is directly contrary to the draft proposal we have today. It only > allows clients to use frames that are defined in the specification. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From duerst@it.aoyama.ac.jp Tue Jul 13 03:44:51 2010 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 77B0A3A680E for ; Tue, 13 Jul 2010 03:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.26 X-Spam-Level: * X-Spam-Status: No, score=1.26 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.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 s9OHFUXFXMdD for ; Tue, 13 Jul 2010 03:44:47 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 4C2143A67C3 for ; Tue, 13 Jul 2010 03:44:47 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o6DAiqAM014740 for ; Tue, 13 Jul 2010 19:44:52 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 4af9_41d2_aad15d5a_8e6b_11df_829b_001d096c566a; Tue, 13 Jul 2010 19:44:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49981) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 13 Jul 2010 19:44:49 +0900 Message-ID: <4C3C4397.3050709@it.aoyama.ac.jp> Date: Tue, 13 Jul 2010 19:44:39 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Anne van Kesteren References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <814698.93763.qm@web82601.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 13 Jul 2010 10:44:51 -0000 On 2010/07/12 19:10, Anne van Kesteren wrote: > Not to me. The main reason we are discussing what "HTTP compatible" > means and how the "HTTP handshake" ought to look is because someone at > IANA thought WebSocket should share a port with HTTP. It has nothing > much to do with the charter. And frankly, it seems like things might be > much easier if we did not share a port with HTTP. I agree. Ports, especially those below 1024, are scare, so it's quite understandable that IANA was reluctant to allocate a new port number for an individual or a third-party organization. But we are an IETF WG. If we decide that we better use a separate port for websockets, we just say so in the spec, and some time between now and when the spec is published as an RFC, IANA will tell us what port number we get. For details, please see http://tools.ietf.org/html/rfc2780. There are some good reasons to reuse the http ports, but there are also some good reasons to not do so. Regards, Martin. -- #-# Martin J. Drst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From w@1wt.eu Tue Jul 13 04:34:48 2010 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 1FE403A685F for ; Tue, 13 Jul 2010 04:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.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 9PE0rUmCkQdr for ; Tue, 13 Jul 2010 04:34:47 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 038BB3A67EF for ; Tue, 13 Jul 2010 04:34:46 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6DBYsHc016710; Tue, 13 Jul 2010 13:34:54 +0200 Date: Tue, 13 Jul 2010 13:34:54 +0200 From: Willy Tarreau To: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= Message-ID: <20100713113454.GG14207@1wt.eu> References: <615374.65181.qm@web82607.mail.mud.yahoo.com> <564970.65690.qm@web82607.mail.mud.yahoo.com> <814698.93763.qm@web82601.mail.mud.yahoo.com> <4C3C4397.3050709@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C3C4397.3050709@it.aoyama.ac.jp> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] comments on draft-ietf-hybi-websocket-requirements-00 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, 13 Jul 2010 11:34:48 -0000 On Tue, Jul 13, 2010 at 07:44:39PM +0900, "Martin J. Drst" wrote: > On 2010/07/12 19:10, Anne van Kesteren wrote: > > >Not to me. The main reason we are discussing what "HTTP compatible" > >means and how the "HTTP handshake" ought to look is because someone at > >IANA thought WebSocket should share a port with HTTP. It has nothing > >much to do with the charter. And frankly, it seems like things might be > >much easier if we did not share a port with HTTP. > > I agree. Ports, especially those below 1024, are scare, so it's quite > understandable that IANA was reluctant to allocate a new port number for > an individual or a third-party organization. But we are an IETF WG. If > we decide that we better use a separate port for websockets, we just say > so in the spec, and some time between now and when the spec is published > as an RFC, IANA will tell us what port number we get. For details, > please see http://tools.ietf.org/html/rfc2780. > > There are some good reasons to reuse the http ports, but there are also > some good reasons to not do so. In my opinion we should distinguish the *need* for reusing HTTP ports from the need to use a separate ports. Those are two distinct things. The reuse of the HTTP port is for the port, but not only, it's also for everything belonging to HTTP (URL switching, virtual hosting, etc...). For this reason it seems urgent to define the protocol as if the port was dedicated to it, and then define how it can be upgraded from standard HTTP. Regards, Willy From stpeter@stpeter.im Tue Jul 13 14:34:03 2010 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 24E9B3A6814 for ; Tue, 13 Jul 2010 14:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 hHpw7lKU8FuV for ; Tue, 13 Jul 2010 14:34:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9B06E3A67FC for ; Tue, 13 Jul 2010 14:34:01 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 61DE640E3B for ; Tue, 13 Jul 2010 15:34:10 -0600 (MDT) Message-ID: <4C3CDBD0.1040800@stpeter.im> Date: Tue, 13 Jul 2010 15:34:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: hybi@ietf.org References: <4C2DC96D.9050908@ericsson.com> In-Reply-To: <4C2DC96D.9050908@ericsson.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [hybi] HyBi schedule & dinner in Maastricht 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, 13 Jul 2010 21:34:03 -0000 On 7/2/10 5:11 AM, Salvatore Loreto wrote: > However, we are trying to organize a dinner earlier in the week to > discuss progress, issues, exchange ideas etc. > that we can followup on Friday. > > I have started a doodle to find a suitable day/time : > http://www.doodle.com/z2pb5f78fny5zzcc It looks like Wednesday evening is the most popular choice... Peter -- Peter Saint-Andre https://stpeter.im/ From trac@tools.ietf.org Fri Jul 16 10:29:58 2010 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 1723B3A6970 for ; Fri, 16 Jul 2010 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, 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 UVww71AtwpZ9 for ; Fri, 16 Jul 2010 10:29:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E17A53A67D3 for ; Fri, 16 Jul 2010 10:29:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZojg-0004eT-72; Fri, 16 Jul 2010 10:30:08 -0700 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: salvatore.loreto@ericsson.com X-Trac-Project: hybi Date: Fri, 16 Jul 2010 17:30:08 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://64.170.98.42/wg/hybi/trac/ticket/5 Message-ID: <068.e1fb505269e30e62f69c37cca39640c9@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: salvatore.loreto@ericsson.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: [hybi] #5: IANA registration for the Upgrade token 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: Fri, 16 Jul 2010 17:29:58 -0000 #5: IANA registration for the Upgrade token -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Keywords: -------------------------------------------+-------------------------------- the IANA registration for the Upgrade token as shown at: http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade- tokens.xml currently refers to draft-hixie-… it should be replaced with draft-ietf-hybi-thewebsocketprotocol -- 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 julian.reschke@gmx.de Fri Jul 16 10:46:11 2010 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 6314D3A68DC for ; Fri, 16 Jul 2010 10:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.675 X-Spam-Level: X-Spam-Status: No, score=-3.675 tagged_above=-999 required=5 tests=[AWL=-1.076, 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 rD4hAjXztC-f for ; Fri, 16 Jul 2010 10:46:10 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id E29853A68B2 for ; Fri, 16 Jul 2010 10:46:09 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2010 17:46:18 -0000 Received: from p508FDD4C.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.221.76] by mail.gmx.net (mp010) with SMTP; 16 Jul 2010 19:46:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+3gh4bUYe3pvIktSF8tp6U7VQrTC/TQzjlaeF/AE dHGUUk8YaOL9H2 Message-ID: <4C409AD8.3050007@gmx.de> Date: Fri, 16 Jul 2010 19:46:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: hybi@ietf.org References: <068.e1fb505269e30e62f69c37cca39640c9@tools.ietf.org> In-Reply-To: <068.e1fb505269e30e62f69c37cca39640c9@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: Re: [hybi] #5: IANA registration for the Upgrade token 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, 16 Jul 2010 17:46:11 -0000 On 16.07.2010 19:30, hybi issue tracker wrote: > #5: IANA registration for the Upgrade token > -------------------------------------------+-------------------------------- > Reporter: salvatore.loreto@… | Owner: > Type: defect | Status: new > Priority: minor | Milestone: > Component: thewebsocketprotocol | Version: > Severity: - | Keywords: > -------------------------------------------+-------------------------------- > the IANA registration for the Upgrade token as shown at: > > http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade- > tokens.xml > > currently refers to draft-hixie-… > it should be replaced with draft-ietf-hybi-thewebsocketprotocol The same applies to the URI scheme registrations for "ws" and "wss" (). From gregw@webtide.com Fri Jul 16 17:01:28 2010 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 7316D3A67F9 for ; Fri, 16 Jul 2010 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 y-XvLIAzl2cE for ; Fri, 16 Jul 2010 17:01:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 743073A679F for ; Fri, 16 Jul 2010 17:01:27 -0700 (PDT) Received: by fxm1 with SMTP id 1so1516889fxm.31 for ; Fri, 16 Jul 2010 17:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.116.6 with SMTP id k6mr1240288faq.49.1279324898623; Fri, 16 Jul 2010 17:01:38 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Fri, 16 Jul 2010 17:01:38 -0700 (PDT) Date: Sat, 17 Jul 2010 10:01:38 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [hybi] New editors? 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, 17 Jul 2010 00:01:28 -0000 All, Have the editors of the requirements and protocol documents opted out of this working group? I believe the deadlines for drafts for the next meeting has already been passed, so that we will be going to the next meeting with exactly the same requirements and protocol specification that we took to the last meeting (except one has been renamed ietf-00 instead of hixie-76). So zero progress has been made. And we will continue to do so while we have partisan and/or inactive editors. At the next meeting, under the topic: "Way of working, how to measure consensus, drafts ownership" I strongly urge those that attend the meeting to consider appointing new editors who will actually engage in this process. If anybody reading wants to contribute to the process and feels that they can speak in moderately neutral voice, then please consider volunteering to be an editor of these drafts. regards From jamie@shareable.org Fri Jul 16 19:37:43 2010 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 D750B3A6881 for ; Fri, 16 Jul 2010 19:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 5NeMqsvqGMyM for ; Fri, 16 Jul 2010 19:37:41 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id AADCE3A6407 for ; Fri, 16 Jul 2010 19:37:40 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1OZxHh-0000eF-EB; Sat, 17 Jul 2010 03:37:49 +0100 Date: Sat, 17 Jul 2010 03:37:49 +0100 From: Jamie Lokier To: hybi issue tracker Message-ID: <20100717023749.GA2426@shareable.org> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Sat, 17 Jul 2010 02:37:43 -0000 hybi issue tracker wrote: > #4: handshake does not work properly with HTTP reverse proxy. > -------------------------------------------+-------------------------------- > Reporter: salvatore.loreto@… | Owner: > Type: defect | Status: new > Priority: critical | Milestone: > Component: thewebsocketprotocol | Version: > Severity: Active WG Document | Keywords: > -------------------------------------------+-------------------------------- > the handshake in draft-ietf-hybi-thewebsocketprotocol-00 (as in draft 76) > does not work properly in presence of HTTP reverse proxy. > > The 8-bytes nonce from the client is not advertised as a content-length, > so it is not forwarded by the reverse proxy as it is either part of a next > request or pending data for when the handshake completes. Unfortunately, > the server wants those bytes to complete the handshake, so we have a dirty > deadlock not even detectable by the end user. > > for more information: > http://www.ietf.org/mail-archive/web/hybi/current/msg02149.html >From discussions on the hybi list several months ago, several times, I got the impression that failure to work through any kind of HTTP proxy was *intentional* in the handshake design. I don't personally agree with that as a design goal, but if it is the design goal than this issue #4 isn't a bug. If the goal is to work through proxies, there are some other issues that also need to be addressed, in particular what are the forwarding requirements that a proxy must satisfy after handshake is complete - partial frames delayed indefinitely, every byte forwarded eagerly, or something else? -- Jamie From w@1wt.eu Fri Jul 16 23:15:50 2010 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 BB8FE3A67F0 for ; Fri, 16 Jul 2010 23:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=-2.420, 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 nysU9cDiJcCU for ; Fri, 16 Jul 2010 23:15:49 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 7CC573A6359 for ; Fri, 16 Jul 2010 23:15:48 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6H6Fv1Y030056; Sat, 17 Jul 2010 08:15:57 +0200 Date: Sat, 17 Jul 2010 08:15:57 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100717061557.GB29907@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100717023749.GA2426@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Sat, 17 Jul 2010 06:15:50 -0000 On Sat, Jul 17, 2010 at 03:37:49AM +0100, Jamie Lokier wrote: > hybi issue tracker wrote: > > #4: handshake does not work properly with HTTP reverse proxy. > > -------------------------------------------+-------------------------------- > > Reporter: salvatore.loreto@??? | Owner: > > Type: defect | Status: new > > Priority: critical | Milestone: > > Component: thewebsocketprotocol | Version: > > Severity: Active WG Document | Keywords: > > -------------------------------------------+-------------------------------- > > the handshake in draft-ietf-hybi-thewebsocketprotocol-00 (as in draft 76) > > does not work properly in presence of HTTP reverse proxy. > > > > The 8-bytes nonce from the client is not advertised as a content-length, > > so it is not forwarded by the reverse proxy as it is either part of a next > > request or pending data for when the handshake completes. Unfortunately, > > the server wants those bytes to complete the handshake, so we have a dirty > > deadlock not even detectable by the end user. > > > > for more information: > > http://www.ietf.org/mail-archive/web/hybi/current/msg02149.html > > >From discussions on the hybi list several months ago, several times, I > got the impression that failure to work through any kind of HTTP proxy > was *intentional* in the handshake design. > > I don't personally agree with that as a design goal, but if it is the > design goal than this issue #4 isn't a bug. If that goal really is to be supported, then the initial HTTP-like handshake is overly complicated and expensive, and will serve no purpose, as nobody will be able to use the protocol that way on shared HTTP ports. Then let's go on with the framing protocol alone without the fake initial handshake and let's have another draft later suggest how to use WS over HTTP as a standard protocol Upgrade request. Regards, Willy From julian.reschke@gmx.de Mon Jul 19 00:38:03 2010 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 175B03A6403 for ; Mon, 19 Jul 2010 00:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=-1.005, 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 hxyqO65TuKIE for ; Mon, 19 Jul 2010 00:38:01 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 906D53A683E for ; Mon, 19 Jul 2010 00:37:59 -0700 (PDT) Received: (qmail invoked by alias); 19 Jul 2010 07:38:11 -0000 Received: from p508FC2C5.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.194.197] by mail.gmx.net (mp069) with SMTP; 19 Jul 2010 09:38:11 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Wvrc8XnyWcvFKgTR7s4woEEOmiqYzkbPBk3L0Fg GAe7gLyyO4EG8Q Message-ID: <4C4400DB.7000400@gmx.de> Date: Mon, 19 Jul 2010 09:38:03 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alexey Melnikov References: <4C35CA30.80308@isode.com> In-Reply-To: <4C35CA30.80308@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] Reminder to document editors: Internet Draft final submission cut-off is July 12 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, 19 Jul 2010 07:38:03 -0000 On 08.07.2010 14:53, Alexey Melnikov wrote: > Hi, > This is a friendly reminder from the Area Director responsible for this > WG that Internet Draft submission cut-off is July 12: > http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 > > It looks like there are some changes that need to be implemented to WG > documents, so it would be good to see documents updated before the IETF > meeting in Maastricht. This hasn't happened. But: as far as I recall, IDs can be submitted again starting Monday next week. Of course that doesn't help those who want to read all current drafts before/during travel. Best regards, Julian From alex@noemax.com Mon Jul 19 03:50:27 2010 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 B6DF53A6864 for ; Mon, 19 Jul 2010 03:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 aovNCCEHgDfy for ; Mon, 19 Jul 2010 03:50:26 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by core3.amsl.com (Postfix) with ESMTP id 29A533A69E8 for ; Mon, 19 Jul 2010 03:50:25 -0700 (PDT) Received: from HPdv73190ev by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id BRR36333; Mon, 19 Jul 2010 13:50:33 +0300 From: "Alexander Philippou" To: "'Greg Wilkins'" , References: In-Reply-To: Date: Mon, 19 Jul 2010 13:50:22 +0300 Organization: Noemax Technologies Message-ID: <002901cb2730$33c7b2b0$9b571810$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcslQz3LvqlDTVKDSkW881mEw9MEpAB5Bcxg Content-Language: en-us Subject: Re: [hybi] New editors? 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, 19 Jul 2010 10:50:27 -0000 > So zero progress has been made. And we will continue to do so while = we have partisan and/or inactive editors. >=20 > At the next meeting, under the topic: "Way of working, how to measure = consensus, drafts ownership" I strongly urge those that attend the = meeting to consider appointing new editors who will actually engage in = this process. +1 Alexander From trac@tools.ietf.org Mon Jul 19 10:03:27 2010 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 C45E73A6B4D for ; Mon, 19 Jul 2010 10:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 DAEi4BZeFQIz for ; Mon, 19 Jul 2010 10:03:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9D6193A6B39 for ; Mon, 19 Jul 2010 10:03:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oatkj-0006o6-1f; Mon, 19 Jul 2010 10:03:41 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:03:41 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/6 Message-ID: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol 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: Mon, 19 Jul 2010 17:03:27 -0000 #6: HTTP Upgrade in relation to the WebSocket protocol --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: Active WG Document | Keywords: --------------------------------------+------------------------------------- Specify along the lines of RFC2817, namely, that the HTTP handshake is to be used only if there is port sharing with HTTP, but is, of course, not required if no port sharing is going on. In this case there is no HTTP from which to Upgrade into WebSockets. There would simply be WebSocket protocol over a dedicated port. See http://www.ietf.org/mail- archive/web/hybi/current/msg02175.html. Also clarify that support for port sharing mode of operation MUST be defined by the spec, but that it remains optional operationally. It is not clear what is the use case for a websocket completely independent of HTTP. -- 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 Mon Jul 19 10:04:38 2010 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 74DD53A6B1B for ; Mon, 19 Jul 2010 10:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 wHItOpN1sn+o for ; Mon, 19 Jul 2010 10:04:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A3FBE3A6B00 for ; Mon, 19 Jul 2010 10:04:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oatls-0006pL-Gn; Mon, 19 Jul 2010 10:04:52 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:04:52 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/7 Message-ID: <063.4934547450d115309b290660f42ea69a@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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: [hybi] #7: Size of messages and/or total message size 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: Mon, 19 Jul 2010 17:04:38 -0000 #7: Size of messages and/or total message size --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: Active WG Document | Keywords: --------------------------------------+------------------------------------- Should the spec say anything about message size? The current requirements spec talks about message blocks (Req. #12, #13, #15, #16) but says nothing about the size of those blocks. Blocks, imply there is some limit on those at least for DoS protection but also to be able to interoperate ("what is the largest block we can exchange?"). The protocol draft in section 4.2 (Data Framing) item 3.6 mentions length of the messages and the fact that some lengths may not be reasonable, but no mention as to what that value is. The aggregation of blocks is another issue for which there may be no limit (e.g., for streaming). -- 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 Mon Jul 19 10:06:54 2010 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 23E343A6992 for ; Mon, 19 Jul 2010 10:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 cV312qxiBqBe for ; Mon, 19 Jul 2010 10:06:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 49FB23A68A4 for ; Mon, 19 Jul 2010 10:06:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oato4-0007C2-4u; Mon, 19 Jul 2010 10:07:08 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:07:08 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/8 Message-ID: <063.947b3d6512b8af900ad04ed45e00f8ef@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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: [hybi] #8: Support for binary data in addition to textual data. 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: Mon, 19 Jul 2010 17:06:54 -0000 #8: Support for binary data in addition to textual data. --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: design-space | Version: Severity: - | Keywords: --------------------------------------+------------------------------------- Both types of data must be supported by the protocol spec. -- 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 Mon Jul 19 10:07:08 2010 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 822153A67C0 for ; Mon, 19 Jul 2010 10:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 V17JPFtmLpBq for ; Mon, 19 Jul 2010 10:07:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8C07B3A6992 for ; Mon, 19 Jul 2010 10:07:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OatoI-0007HO-Dy; Mon, 19 Jul 2010 10:07:22 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:07:22 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/8#comment:1 Message-ID: <072.807890520d278e3fe01b25f8cac0d693@tools.ietf.org> References: <063.947b3d6512b8af900ad04ed45e00f8ef@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <063.947b3d6512b8af900ad04ed45e00f8ef@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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] #8: Support for binary data in addition to textual data. 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: Mon, 19 Jul 2010 17:07:08 -0000 #8: Support for binary data in addition to textual data. --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: - | Keywords: --------------------------------------+------------------------------------- Changes (by g_e_montenegro@…): * component: design-space => websocket-requirements -- 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 Mon Jul 19 10:07:32 2010 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 14FCF3A6B41 for ; Mon, 19 Jul 2010 10:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 s5pCtMmTfgvx for ; Mon, 19 Jul 2010 10:07:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F19173A67C0 for ; Mon, 19 Jul 2010 10:07:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oatoc-0007Hd-RS; Mon, 19 Jul 2010 10:07:42 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:07:42 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/8#comment:2 Message-ID: <072.0770b790aec39199db5d55ee3ec341b3@tools.ietf.org> References: <063.947b3d6512b8af900ad04ed45e00f8ef@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <063.947b3d6512b8af900ad04ed45e00f8ef@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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] #8: Support for binary data in addition to textual data. 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: Mon, 19 Jul 2010 17:07:32 -0000 #8: Support for binary data in addition to textual data. --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: Candidate WG Document | Keywords: --------------------------------------+------------------------------------- Changes (by g_e_montenegro@…): * severity: - => Candidate WG Document -- 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 salvatore.loreto@ericsson.com Mon Jul 19 10:08:07 2010 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 C262B3A6B48 for ; Mon, 19 Jul 2010 10:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-1.818, 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 p0boRlftKBin for ; Mon, 19 Jul 2010 10:08:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 099CC3A6B40 for ; Mon, 19 Jul 2010 10:07:40 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-58-4c44866af6c8 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C7.89.06895.A66844C4; Mon, 19 Jul 2010 19:07:54 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 19:07:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 19:07:54 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6E45724DC for ; Mon, 19 Jul 2010 20:07:54 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2D33B4F76F for ; Mon, 19 Jul 2010 20:07:54 +0300 (EEST) Received: from cs78166197.pp.htv.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C427B4F38F for ; Mon, 19 Jul 2010 20:07:53 +0300 (EEST) Message-ID: <4C448669.4090604@ericsson.com> Date: Mon, 19 Jul 2010 20:07:53 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 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-OriginalArrivalTime: 19 Jul 2010 17:07:54.0863 (UTC) FILETIME=[EDB77FF0:01CB2764] X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Agenda update 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, 19 Jul 2010 17:08:07 -0000 folks, we have received a slot request from Gabriel, So here you can find the latest Agenda: http://www.ietf.org/proceedings/78/agenda/hybi.txt cheers /Sal -- Salvatore Loreto www.sloreto.com From trac@tools.ietf.org Mon Jul 19 10:08:57 2010 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 3913E3A67C0 for ; Mon, 19 Jul 2010 10:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 u3saE5RpiEPn for ; Mon, 19 Jul 2010 10:08:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 782293A6B41 for ; Mon, 19 Jul 2010 10:08:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oatq1-0007Im-5o; Mon, 19 Jul 2010 10:09:09 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:09:09 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/9 Message-ID: <063.9ea6dee46d64a0f9040694e86a9db584@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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: [hybi] #9: Sub-Protocol support 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: Mon, 19 Jul 2010 17:08:57 -0000 #9: Sub-Protocol support --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: - | Keywords: --------------------------------------+------------------------------------- Client and server may agree on a given sub-protocol. In the non-default case in which the native wire protocol and framing are not used, enhance reuse of components by allowing sub-protocols to simply use the established communication channel without imposing any further requirements on them. -- 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 Mon Jul 19 10:09:43 2010 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 D90443A6B40 for ; Mon, 19 Jul 2010 10:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 l6ciWutTtofd for ; Mon, 19 Jul 2010 10:09:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0845B3A6B54 for ; Mon, 19 Jul 2010 10:09:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oatqm-0007JI-Q6; Mon, 19 Jul 2010 10:09:56 -0700 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 X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:09:56 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/10 Message-ID: <063.7e4f77308ff1cfa9c20d6f6a484227ea@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.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: [hybi] #10: Proxy requirements 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: Mon, 19 Jul 2010 17:09:44 -0000 #10: Proxy requirements --------------------------------------+------------------------------------- Reporter: g_e_montenegro@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: - | Keywords: --------------------------------------+------------------------------------- Proxy traversal is one of the major motivations for WebSockets specially as an Upgrade to HTTP. -- 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 Mon Jul 19 10:28:39 2010 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 406DB3A69CA for ; Mon, 19 Jul 2010 10:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 6ZV7sXRVhV6U for ; Mon, 19 Jul 2010 10:28:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 477763A685A for ; Mon, 19 Jul 2010 10:28:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oau95-0004qi-Po; Mon, 19 Jul 2010 10:28:51 -0700 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: julian.reschke@gmx.de X-Trac-Project: hybi Date: Mon, 19 Jul 2010 17:28:51 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/hybi/trac/ticket/5#comment:1 Message-ID: <077.fd4159730fb037173f923755b2123b0e@tools.ietf.org> References: <068.e1fb505269e30e62f69c37cca39640c9@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <068.e1fb505269e30e62f69c37cca39640c9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, 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] #5: IANA registration for the Upgrade token 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: Mon, 19 Jul 2010 17:28:39 -0000 #5: IANA registration for the Upgrade token -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: thewebsocketprotocol | Version: Severity: - | Keywords: -------------------------------------------+-------------------------------- Comment(by julian.reschke@…): (the same applies to the IANA registration of the "ws" and "wss" URI schemes) -- 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 prvs=809b1fa09=roderick.baier@hs-weingarten.de Mon Jul 19 10:58:14 2010 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 685DE3A6821 for ; Mon, 19 Jul 2010 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 4VdP-ekoABuz for ; Mon, 19 Jul 2010 10:58:13 -0700 (PDT) Received: from ironport.hs-weingarten.de (ironport.hs-weingarten.de [141.69.1.3]) by core3.amsl.com (Postfix) with ESMTP id 9D6213A6818 for ; Mon, 19 Jul 2010 10:58:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,227,1278280800"; d="scan'208";a="1086494" Received: from mail3.fh-weingarten.de (HELO mail3.hs-weingarten.de) ([141.69.46.149]) by ironportmgt.hs-weingarten.de with ESMTP; 19 Jul 2010 19:58:23 +0200 Received: from [192.168.1.102] (p549D7E2B.dip.t-dialin.net [84.157.126.43]) (authenticated bits=0) by mail3.hs-weingarten.de (8.13.8/8.13.8/Debian-3) with ESMTP id o6JHwLBI002503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Jul 2010 19:58:22 +0200 Message-ID: <4C44923B.7000900@hs-weingarten.de> Date: Mon, 19 Jul 2010 19:58:19 +0200 From: Roderick Baier User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: hybi@ietf.org References: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> In-Reply-To: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang / Hochschule Ravensburg-Weingarten (Rechenzentrum) on 141.69.46.149 Subject: Re: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol 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, 19 Jul 2010 17:58:14 -0000 Hi How could a WebSocket client detect if there is port sharing with HTTP or not? I'm using WebSockets without HTTP, HTML, JavaScript and so on. From my point of view there is no HTTP upgrade handshake, it's just a WebSocket handshake that looks like HTTP. "... not required if no port sharing is going on. In this case there is no HTTP from which to Upgrade into WebSockets. There would simply be WebSocket protocol over a dedicated port." What is "simply WebSocket protocol"? You'll still need an opening handshake for resource, sub-protocol etc. Best regards Roderick hybi issue tracker schrieb: > #6: HTTP Upgrade in relation to the WebSocket protocol > --------------------------------------+------------------------------------- > Reporter: g_e_montenegro@… | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: websocket-requirements | Version: > Severity: Active WG Document | Keywords: > --------------------------------------+------------------------------------- > Specify along the lines of RFC2817, namely, that the HTTP handshake is to > be used only if there is port sharing with HTTP, but is, of course, not > required if no port sharing is going on. In this case there is no HTTP > from which to Upgrade into WebSockets. There would simply be WebSocket > protocol over a dedicated port. See http://www.ietf.org/mail- > archive/web/hybi/current/msg02175.html. Also clarify that support for port > sharing mode of operation MUST be defined by the spec, but that it remains > optional operationally. It is not clear what is the use case for a > websocket completely independent of HTTP. > From w@1wt.eu Mon Jul 19 11:07:54 2010 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 BFCD53A6809 for ; Mon, 19 Jul 2010 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[AWL=-2.310, 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 ygANKd+w5ZEu for ; Mon, 19 Jul 2010 11:07:52 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A02663A67CC for ; Mon, 19 Jul 2010 11:07:50 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6JI83s4013576; Mon, 19 Jul 2010 20:08:03 +0200 Date: Mon, 19 Jul 2010 20:08:03 +0200 From: Willy Tarreau To: Roderick Baier Message-ID: <20100719180803.GC9894@1wt.eu> References: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> <4C44923B.7000900@hs-weingarten.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C44923B.7000900@hs-weingarten.de> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol 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, 19 Jul 2010 18:07:54 -0000 Hi Roderick, On Mon, Jul 19, 2010 at 07:58:19PM +0200, Roderick Baier wrote: > Hi > > How could a WebSocket client detect if there is port sharing with HTTP > or not? I'm using WebSockets without HTTP, HTML, JavaScript and so on. Just the same way it's done for TLS as per RFC2817 : when you want to work over port 80, you use the HTTP protocol. It's that simple. > From my point of view there is no HTTP upgrade handshake, it's just a > WebSocket handshake that looks like HTTP. Unfortunately, it does not look like HTTP anymore and is not even compatible with it anymore. And for some people, the overhead added by the "HTTP-like" handshake is a big waste. Regards, Willy From ferg@caucho.com Mon Jul 19 11:20:09 2010 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 87ADB3A6868 for ; Mon, 19 Jul 2010 11:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, WEIRD_PORT=0.001] 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 bb2wGCN-Wwnr for ; Mon, 19 Jul 2010 11:20:08 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id 688E53A67CC for ; Mon, 19 Jul 2010 11:20:08 -0700 (PDT) Received: (qmail 20834 invoked from network); 19 Jul 2010 18:20:20 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 19 Jul 2010 11:20:20 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: Wh3i8icVM1n7lZDlaoBtzL4FFDC5zI1mR5Gh65_.OTISn.U 8EmGPyx5ilrrxqN1AewTeN9K1ub0pgOuWl6sQo8KGjU76FmM1Xf6jZFqc8wf m2lRbiU0Z5R0iAJyDjsu0O2yh6ANMkqV9.ZMCbyOIh43GB8Jqd7FZAuKh.fD lzrRGTKML.iU0I959kJhebNhk8VlMoTxqpScFyoP2pxT_PUfjvxJDhND0nrz Wdc7a6dJFwX3KrMkADHs_DFxb4kt1k2H2bLBaI257h1HBzoQPNkQ384c7tix rxDzE550tizzhxuCJpCd9PAM.jqx9yCWAYi5XY7M2CAQaTJwhhmg26Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C449763.50900@caucho.com> Date: Mon, 19 Jul 2010 11:20:19 -0700 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Roderick Baier References: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> <4C44923B.7000900@hs-weingarten.de> In-Reply-To: <4C44923B.7000900@hs-weingarten.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol 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, 19 Jul 2010 18:20:09 -0000 Roderick Baier wrote: > Hi > > How could a WebSocket client detect if there is port sharing with HTTP > or not? I'm using WebSockets without HTTP, HTML, JavaScript and so on. > From my point of view there is no HTTP upgrade handshake, it's just a > WebSocket handshake that looks like HTTP. > > "... not required if no port sharing is going on. In this case > there is no HTTP from which to Upgrade into WebSockets. There would > simply be WebSocket protocol over a dedicated port." > > What is "simply WebSocket protocol"? You'll still need an opening > handshake for resource, sub-protocol etc. Perhaps something along the lines of the discussion we had earlier, which might look like: http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.txt The client handshake is a HELLO control frame that looks like the following: %x80.02.00.86 WebSocket/1.0 url: ws://example.com:880/sample/resource origin: http://example.com/launchpage.php protocol: tictactoe.example.com/1.0 The server handshake is a HELLO control frame that looks like the following: %x80.02.00.32 WebSocket/1.0 protocol: tictactoe.example.com/1.0 -- Scott > > Best regards > Roderick > > > > hybi issue tracker schrieb: >> #6: HTTP Upgrade in relation to the WebSocket protocol >> --------------------------------------+------------------------------------- >> >> Reporter: g_e_montenegro@… | Owner: Type: >> enhancement | Status: new >> Priority: major | Milestone: Component: >> websocket-requirements | Version: Severity: Active WG >> Document | Keywords: >> --------------------------------------+------------------------------------- >> >> Specify along the lines of RFC2817, namely, that the HTTP handshake >> is to >> be used only if there is port sharing with HTTP, but is, of course, not >> required if no port sharing is going on. In this case there is no HTTP >> from which to Upgrade into WebSockets. There would simply be WebSocket >> protocol over a dedicated port. See http://www.ietf.org/mail- >> archive/web/hybi/current/msg02175.html. Also clarify that support >> for port >> sharing mode of operation MUST be defined by the spec, but that it >> remains >> optional operationally. It is not clear what is the use case for a >> websocket completely independent of HTTP. >> > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From sm@resistor.net Mon Jul 19 11:40:55 2010 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 4C11B3A693F for ; Mon, 19 Jul 2010 11:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 RA0JHhcN4TaC for ; Mon, 19 Jul 2010 11:40:52 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id CEE443A6A79 for ; Mon, 19 Jul 2010 11:40:52 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o6JIec2V004897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 11:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1279564863; x=1279651263; bh=N0y647Oystpe2c/DqJyw/3ctoAgyTIuDzCjCfT3gBEU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=SCfpCET/7mcJfl1uwXxYyKinl+Rwxwm7jvPFjPQCN5ZRvZ/ofRYurCcWeTdYgXF8G 5MnHG9ZcLhi/95c0I7KSjdnu/wcvd1XsH6EGekF1Vw1VKxiPndWKqDQ7oVhlV2pMGH NYfMoP1RgQbwsMraAGXboi/I4bTXcRl5KW4prHxo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1279564863; x=1279651263; bh=N0y647Oystpe2c/DqJyw/3ctoAgyTIuDzCjCfT3gBEU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NpI+7ZM0u2oIQ9TIku52CfIjy9yfXIvtPx5MdINDVP4r0Qw0JJTCEesfmgr+lYHek EAUKzBWl/IFXpc7ar9sWlkKif3D0RtbLNXR84iQcOPTB8Lzi/Km0oMZIxsJDlmoBIo /iVrQf7M0cK0vNeGoKhiKlVSdRehEwDsdxEi6fWk= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=sCmJFA1TnWDc23KbnzazZmP6hG+f5aTp6ji46mlXJVw/9SlSp2B0KfDjAYhM5S8Tp 2C5aUdZsIej9Pq5v090eTrac1aKvpwYHcBTfIi5qa2qzdwJSQfjluqkBH8DRMfmCRtn vvAMoUki/Vvc3AvB9vUOl0yeb4bQen6ko2EJfbI= Message-Id: <6.2.5.6.2.20100719111648.0974c0b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Jul 2010 11:40:08 -0700 To: Julian Reschke From: SM In-Reply-To: <4C4400DB.7000400@gmx.de> References: <4C35CA30.80308@isode.com> <4C4400DB.7000400@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: hybi@ietf.org Subject: Re: [hybi] Reminder to document editors: Internet Draft final submission cut-off is July 12 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, 19 Jul 2010 18:40:55 -0000 Hi Julian, At 00:38 19-07-10, Julian Reschke wrote: >This hasn't happened. It's been nearly two months since you raised the issue. The HyBi WG Chair asked for some changes ( http://www.ietf.org/mail-archive/web/hybi/current/msg02137.html ) nearly a month ago. The IETF Area Director asked for the documents to be updated over a week ago ( http://www.ietf.org/mail-archive/web/hybi/current/msg02159.html ). If the editors of the documents are too busy, it would be better to appoint new editors to do the work. I suggest making the final decision through this mailing list and not at the upcoming meeting. Regards, -sm From alexey.melnikov@isode.com Mon Jul 19 14:59:53 2010 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 5D5D43A6984 for ; Mon, 19 Jul 2010 14:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 EAMrRJz8cWA5 for ; Mon, 19 Jul 2010 14:59:52 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6882A3A680F for ; Mon, 19 Jul 2010 14:59:52 -0700 (PDT) Received: from [92.40.178.109] (92.40.178.109.sub.mbb.three.co.uk [92.40.178.109]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 19 Jul 2010 23:00:05 +0100 Message-ID: <4C44CACB.5040108@isode.com> Date: Mon, 19 Jul 2010 22:59:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: SM References: <4C35CA30.80308@isode.com> <4C4400DB.7000400@gmx.de> <6.2.5.6.2.20100719111648.0974c0b8@resistor.net> In-Reply-To: <6.2.5.6.2.20100719111648.0974c0b8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Reminder to document editors: Internet Draft final submission cut-off is July 12 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, 19 Jul 2010 21:59:53 -0000 Hi SM, SM wrote: > If the editors of the documents are too busy, it would be better to > appoint new editors to do the work. I suggest making the final > decision through this mailing list and not at the upcoming meeting. While I would like to hear from editors (publicly on the mailing list or privately) if they think they are too busy to work on documents and need some help, I would like to let WG chairs to handle any changes or appointments to editors. Regards, Alexey From gregw@webtide.com Mon Jul 19 17:02:33 2010 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 A7A383A6BA5 for ; Mon, 19 Jul 2010 17:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=0.001] 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 yUS1YdBfJMt3 for ; Mon, 19 Jul 2010 17:02:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C823B3A6BBB for ; Mon, 19 Jul 2010 17:02:30 -0700 (PDT) Received: by fxm1 with SMTP id 1so2750761fxm.31 for ; Mon, 19 Jul 2010 17:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.116.147 with SMTP id m19mr4500975faq.52.1279584164119; Mon, 19 Jul 2010 17:02:44 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Mon, 19 Jul 2010 17:02:44 -0700 (PDT) In-Reply-To: <4C449763.50900@caucho.com> References: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> <4C44923B.7000900@hs-weingarten.de> <4C449763.50900@caucho.com> Date: Tue, 20 Jul 2010 10:02:44 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol 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, 20 Jul 2010 00:02:33 -0000 I think it is really important to make a very clear separation of the websocket protocol for an established websocket connection and for the protocol used to establish that connection. I would expect that over time there could develop several ways of establishing websocket connections, with HTTP upgrade being the first technique, but then I do see a good use-case for a websocket only handshake like Scott has described. Eventually there may be TLS dependent mechanisms as well. If we clearly separate out the wire protocol from the connection establishment, then we can be very clear about what information is needed from the handshake by the established connection and what information is purely part of the particular handshake and security mechanisms that might be particular just to HTTP upgrade (for example). If websocket does eventually get it's own port(s), then I think it would be highly desirable to have a handshake that does not look like HTTP at all. Having HTTP-like on other ports will at best be confusing, but at worst will result in some actually running real HTTP servers (with websocket capabilities) on the Websocket ports, thus importing all the security concerns of HTTP to the new ports. cheers On 20 July 2010 04:20, Scott Ferguson wrote: > Roderick Baier wrote: >> >> Hi >> >> How could a WebSocket client detect if there is port sharing with HTTP o= r >> not? I'm using WebSockets without HTTP, HTML, JavaScript and so on. From= my >> point of view there is no HTTP upgrade handshake, it's just a WebSocket >> handshake that looks like HTTP. >> >> =C2=A0 =C2=A0"... not required if no port sharing is going on. In this c= ase there is >> no HTTP from which to Upgrade into WebSockets. There would simply be >> WebSocket protocol over a dedicated port." >> >> What is "simply WebSocket protocol"? You'll still need an opening >> handshake for resource, sub-protocol etc. > > Perhaps something along the lines of the discussion we had earlier, which > might look like: > > =C2=A0http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-lat= est.txt > > =C2=A0The client handshake is a HELLO control frame that looks like the > =C2=A0following: > > =C2=A0 =C2=A0%x80.02.00.86 WebSocket/1.0 > =C2=A0 =C2=A0url: ws://example.com:880/sample/resource > =C2=A0 =C2=A0origin: http://example.com/launchpage.php > =C2=A0 =C2=A0protocol: tictactoe.example.com/1.0 > =C2=A0 =C2=A0 > > =C2=A0The server handshake is a HELLO control frame that looks like the > =C2=A0following: > > =C2=A0 =C2=A0%x80.02.00.32 WebSocket/1.0 > =C2=A0 =C2=A0protocol: tictactoe.example.com/1.0 > =C2=A0 =C2=A0 > > -- Scott > > >> >> Best regards >> Roderick >> >> >> >> hybi issue tracker schrieb: >>> >>> #6: HTTP Upgrade in relation to the WebSocket protocol >>> >>> --------------------------------------+--------------------------------= ----- >>> =C2=A0Reporter: =C2=A0g_e_montenegro@=E2=80=A6 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Owner: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= ype: >>> =C2=A0enhancement =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0Status: =C2=A0new >>> =C2=A0Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Milestone: =C2=A0 =C2=A0 Component: >>> =C2=A0websocket-requirements =C2=A0 =C2=A0| =C2=A0 =C2=A0 Version: =C2= =A0 =C2=A0 =C2=A0Severity: =C2=A0Active WG Document >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Keywords: >>> --------------------------------------+--------------------------------= ----- >>> =C2=A0Specify along the lines of RFC2817, namely, that the HTTP handsha= ke is >>> to >>> =C2=A0be used only if there is port sharing with HTTP, but is, of cours= e, not >>> =C2=A0required if no port sharing is going on. In this case there is no= HTTP >>> =C2=A0from which to Upgrade into WebSockets. There would simply be WebS= ocket >>> =C2=A0protocol over a dedicated port. See http://www.ietf.org/mail- >>> =C2=A0archive/web/hybi/current/msg02175.html. Also clarify that support= for >>> port >>> =C2=A0sharing mode of operation MUST be defined by the spec, but that i= t >>> remains >>> =C2=A0optional operationally. It is not clear what is the use case for = a >>> =C2=A0websocket completely independent of HTTP. >>> >> >> _______________________________________________ >> 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 > From gregw@webtide.com Mon Jul 19 17:14:59 2010 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 18E7A3A6BA7 for ; Mon, 19 Jul 2010 17:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Rlbh-QhmeGm0 for ; Mon, 19 Jul 2010 17:14:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BD57C3A69B5 for ; Mon, 19 Jul 2010 17:14:57 -0700 (PDT) Received: by fxm1 with SMTP id 1so2754605fxm.31 for ; Mon, 19 Jul 2010 17:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.35.2 with SMTP id i2mr3427883fgi.8.1279584912092; Mon, 19 Jul 2010 17:15:12 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Mon, 19 Jul 2010 17:15:12 -0700 (PDT) In-Reply-To: <072.0770b790aec39199db5d55ee3ec341b3@tools.ietf.org> References: <063.947b3d6512b8af900ad04ed45e00f8ef@tools.ietf.org> <072.0770b790aec39199db5d55ee3ec341b3@tools.ietf.org> Date: Tue, 20 Jul 2010 10:15:12 +1000 Message-ID: From: Greg Wilkins To: hybi issue tracker , hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] #8: Support for binary data in addition to textual data. 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, 20 Jul 2010 00:14:59 -0000 I have a little quibble with the wording of this issue: "Support for binary data in addition to textual data" I think it really should be "Support for binary data and textual data" because the "in addition to" wording strongly suggests that the only way this issue can be resolved is to have binary frames in addition to text frames. However, there are many ways that this issue can be solved, including: + making all frames binary, with a content type assumption of UTF-8 text unless otherwise indicated for the connection. + making all frames binary, with a content type assumption of UTF-8 text unless otherwise indicated for the message. + making all frames binary, with a content type being explicitly declared when the connection is established. + support multi-plexing with binary and/or text virtual channels + support a mime encoded frame type. let's not assume that the current protocol is the only solution - it may still be the chosen solution, but it is not the required solution. etc. etc. On 20 July 2010 03:07, hybi issue tracker wrote: > #8: Support for binary data in addition to textual data. > --------------------------------------+----------------------------------= --- > =C2=A0Reporter: =C2=A0g_e_montenegro@=E2=80=A6 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Owner: > =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0Status: =C2=A0new > =C2=A0Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Milestone: > Component: =C2=A0websocket-requirements =C2=A0 =C2=A0| =C2=A0 =C2=A0 Vers= ion: > =C2=A0Severity: =C2=A0Candidate WG Document =C2=A0 =C2=A0 | =C2=A0 =C2=A0= Keywords: > --------------------------------------+----------------------------------= --- > Changes (by g_e_montenegro@=E2=80=A6): > > =C2=A0* severity: =C2=A0- =3D> Candidate WG Document > > > -- > 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. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@webtide.com Mon Jul 19 17:28:12 2010 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 3183A3A6A85 for ; Mon, 19 Jul 2010 17:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 xBjVhk9Wq08E for ; Mon, 19 Jul 2010 17:28:11 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 283943A67F5 for ; Mon, 19 Jul 2010 17:28:10 -0700 (PDT) Received: by fxm1 with SMTP id 1so2757983fxm.31 for ; Mon, 19 Jul 2010 17:28:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.119.147 with SMTP id z19mr4514754faq.64.1279585705399; Mon, 19 Jul 2010 17:28:25 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Mon, 19 Jul 2010 17:28:25 -0700 (PDT) In-Reply-To: <20100717023749.GA2426@shareable.org> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> Date: Tue, 20 Jul 2010 10:28:25 +1000 Message-ID: From: Greg Wilkins To: hybi issue tracker , hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Tue, 20 Jul 2010 00:28:12 -0000 On 17 July 2010 12:37, Jamie Lokier wrote: > hybi issue tracker wrote: > From discussions on the hybi list several months ago, several times, I > got the impression that failure to work through any kind of HTTP proxy > was *intentional* in the handshake design. > > I don't personally agree with that as a design goal, but if it is the > design goal than this issue #4 isn't a bug. >From those same discussion, I concluded that the intent of this "feature" was to fast fail in the presence of any kind of HTTP proxy. Given that this "feature" is now resulting in a hang if there is such a proxy, then I think it is still a bug whatever way you look at it. More importantly, the best way to test if a connection will support websocket packets, is to just send websocket packets. Sending 8/16 random bytes immediately after the HTTP handshake may succeed for a huge variety of implementation reasons that still do not mean that websocket packets will succeed. More importantly, to detect the non-success of sending of the 8/16 random bytes will still involve the same timeout handling that would be required to check the transmission of websocket packets. Even successfully sending websocket packets is not a fool proof way of predicting future success of websocket packets, thus we already have started discussions about keep alives and other mechanisms to check the health of a connection. The checking of the initial health of the connection should really just be an edge case for these mechanism and not some special purpose exchange pseudo secure algorithms. cheers From w@1wt.eu Mon Jul 19 21:33:51 2010 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 9FF9E3A689E for ; Mon, 19 Jul 2010 21:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.339 X-Spam-Level: X-Spam-Status: No, score=-4.339 tagged_above=-999 required=5 tests=[AWL=-2.296, 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 MykwcqVQSmZy for ; Mon, 19 Jul 2010 21:32:51 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 4C0603A69CF for ; Mon, 19 Jul 2010 21:32:43 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6K4Wcp7018339; Tue, 20 Jul 2010 06:32:38 +0200 Date: Tue, 20 Jul 2010 06:32:38 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100720043238.GD14242@1wt.eu> References: <063.8d6c52995b7699ce8612481828d6c227@tools.ietf.org> <4C44923B.7000900@hs-weingarten.de> <4C449763.50900@caucho.com> 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: hybi@ietf.org Subject: Re: [hybi] #6: HTTP Upgrade in relation to the WebSocket protocol 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, 20 Jul 2010 04:33:51 -0000 On Tue, Jul 20, 2010 at 10:02:44AM +1000, Greg Wilkins wrote: > I think it is really important to make a very clear separation of the > websocket protocol for an established websocket connection and for the > protocol used to establish that connection. > > I would expect that over time there could develop several ways of > establishing websocket connections, with HTTP upgrade being the first > technique, but then I do see a good use-case for a websocket only > handshake like Scott has described. Eventually there may be TLS > dependent mechanisms as well. > > If we clearly separate out the wire protocol from the connection > establishment, then we can be very clear about what information is > needed from the handshake by the established connection and what > information is purely part of the particular handshake and security > mechanisms that might be particular just to HTTP upgrade (for > example). > > If websocket does eventually get it's own port(s), then I think it > would be highly desirable to have a handshake that does not look like > HTTP at all. Having HTTP-like on other ports will at best be > confusing, but at worst will result in some actually running real HTTP > servers (with websocket capabilities) on the Websocket ports, thus > importing all the security concerns of HTTP to the new ports. Totally agreed ! Cheers, Willy From w@1wt.eu Mon Jul 19 21:43:40 2010 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 87BBD3A6B33 for ; Mon, 19 Jul 2010 21:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.247 X-Spam-Level: X-Spam-Status: No, score=-4.247 tagged_above=-999 required=5 tests=[AWL=-2.204, 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 CRpSwU4fFS5i for ; Mon, 19 Jul 2010 21:43:39 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 4A3623A6B8F for ; Mon, 19 Jul 2010 21:43:39 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6K4hqTm018465; Tue, 20 Jul 2010 06:43:52 +0200 Date: Tue, 20 Jul 2010 06:43:52 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100720044352.GE14242@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> 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: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Tue, 20 Jul 2010 04:43:40 -0000 On Tue, Jul 20, 2010 at 10:28:25AM +1000, Greg Wilkins wrote: > >From those same discussion, I concluded that the intent of this > "feature" was to fast fail in the presence of any kind of HTTP proxy. It was to fail in the presence of any kind of WebSocket-incompatible HTTP transparent proxies, to give opportunity to spot them and upgrade them to support the protocol. But now the requirements are not compatible with HTTP, meaning that those proxies or reverse proxies will never be able to be upgraded. > Given that this "feature" is now resulting in a hang if there is such > a proxy, then I think it is still a bug whatever way you look at it. > > More importantly, the best way to test if a connection will support > websocket packets, is to just send websocket packets. Sending 8/16 > random bytes immediately after the HTTP handshake may succeed for a > huge variety of implementation reasons that still do not mean that > websocket packets will succeed. You make a good point here, because very old versions of haproxy would consider that whatever was sent after headers was data and could be immediately exchanged (there was no difference between GET and POST), so that in practice that would have worked, despite the brokenness of the product. Also, I would really insist that we add a "Connection: close" in the initial HTTP handshake, whatever it looks like in the end, so that we protect the servers against any form of request injection after the first one. Regards, Willy From gregw@webtide.com Mon Jul 19 23:40:20 2010 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 B70843A6922 for ; Mon, 19 Jul 2010 23:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 tL6yG4MaXPQz for ; Mon, 19 Jul 2010 23:40:19 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 41ECA3A681F for ; Mon, 19 Jul 2010 23:40:19 -0700 (PDT) Received: by fxm1 with SMTP id 1so2841425fxm.31 for ; Mon, 19 Jul 2010 23:40:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.105.129 with SMTP id t1mr4802746fao.12.1279608033331; Mon, 19 Jul 2010 23:40:33 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Mon, 19 Jul 2010 23:40:33 -0700 (PDT) In-Reply-To: <20100720044352.GE14242@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> <20100720044352.GE14242@1wt.eu> Date: Tue, 20 Jul 2010 16:40:33 +1000 Message-ID: From: Greg Wilkins To: Willy Tarreau Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Tue, 20 Jul 2010 06:40:20 -0000 On 20 July 2010 14:43, Willy Tarreau wrote: > Also, I would really insist that we add a "Connection: close" in the > initial HTTP handshake, whatever it looks like in the end, so that we > protect the servers against any form of request injection after the > first one. I think that if we fail to come up with a HTTP compliant handshake, then a Connection:close would be a good get out of goal free card. However, it does prevent one possible good use case of using the HTTP connection as a HTTP connection in the case that websocket is rejected. Until websocket is widely deployed, many sites will want to fall back to a HTTP transport if websockets is rejected. If the connection can be kept open, then it may be used by the browser for subsequent HTTP requests, saving a round trip. If a failed handshake response can contain other useful content, then you may be able to save 2 round trips in the establishment of HTTP transports. This is already an issue with cometd-2, now that we support websocket as an optional transport. When it is enabled, there is noticeable additional establishing a comet web page (eg logging into a chat room), while websocket hand shake is tried and fails, before the next handshake is tried. This is a discouragement to enabling websocket support in the framework, which is then does not encourage infrastructure providers to support websocket. regards From w@1wt.eu Tue Jul 20 02:06:25 2010 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 F0EBB3A687F for ; Tue, 20 Jul 2010 02:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-2.864, BAYES_05=-1.11, 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 piUV85knnVh2 for ; Tue, 20 Jul 2010 02:06:24 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 803E33A67F0 for ; Tue, 20 Jul 2010 02:06:22 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6K96Wee021157; Tue, 20 Jul 2010 11:06:32 +0200 Date: Tue, 20 Jul 2010 11:06:32 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100720090632.GB21095@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> <20100720044352.GE14242@1wt.eu> 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: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Tue, 20 Jul 2010 09:06:25 -0000 On Tue, Jul 20, 2010 at 04:40:33PM +1000, Greg Wilkins wrote: > On 20 July 2010 14:43, Willy Tarreau wrote: > > Also, I would really insist that we add a "Connection: close" in the > > initial HTTP handshake, whatever it looks like in the end, so that we > > protect the servers against any form of request injection after the > > first one. > > I think that if we fail to come up with a HTTP compliant handshake, then a > Connection:close would be a good get out of goal free card. > > However, it does prevent one possible good use case of using the HTTP > connection as a HTTP connection in the case that websocket is rejected. > Until websocket is widely deployed, many sites will want to fall back to a > HTTP transport if websockets is rejected. If the connection can be kept > open, then it may be used by the browser for subsequent HTTP requests, > saving a round trip. If a failed handshake response can contain other useful > content, then you may be able to save 2 round trips in the establishment of > HTTP transports. > > This is already an issue with cometd-2, now that we support websocket as > an optional transport. When it is enabled, there is noticeable additional > establishing a comet web page (eg logging into a chat room), while websocket > hand shake is tried and fails, before the next handshake is tried. This is a > discouragement to enabling websocket support in the framework, which is > then does not encourage infrastructure providers to support websocket. Agreed. Also, keeping the connection open is required with some authentication schemes such as NTLM which authenticate the connection instead of the request. While this will not be a problem on the Internet, it could make it difficult to integrate websocket into enterprise applications. This is another reason not to send any unadvertised data in the handshake by the way ! Regards, Willy From salvatore.loreto@ericsson.com Tue Jul 20 03:38:27 2010 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 29DFC3A67B6 for ; Tue, 20 Jul 2010 03:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, 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 w9BJYZz9x85k for ; Tue, 20 Jul 2010 03:38:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5FA003A6C5F for ; Tue, 20 Jul 2010 03:38:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-b2-4c457c9d4c75 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 32.3D.10125.D9C754C4; Tue, 20 Jul 2010 12:38:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 12:38:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 12:38:21 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5DD712997 for ; Tue, 20 Jul 2010 13:38:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 24C704FBC2 for ; Tue, 20 Jul 2010 13:38:21 +0300 (EEST) Received: from cs78166197.pp.htv.fi (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CE8844FA1B for ; Tue, 20 Jul 2010 13:38:20 +0300 (EEST) Message-ID: <4C457C9C.4030101@ericsson.com> Date: Tue, 20 Jul 2010 13:38:20 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: hybi@ietf.org References: <4C35CA30.80308@isode.com> <4C4400DB.7000400@gmx.de> <6.2.5.6.2.20100719111648.0974c0b8@resistor.net> <4C44CACB.5040108@isode.com> In-Reply-To: <4C44CACB.5040108@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 20 Jul 2010 10:38:21.0680 (UTC) FILETIME=[ACA08F00:01CB27F7] X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Reminder to document editors: Internet Draft final submission cut-off is July 12 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, 20 Jul 2010 10:38:27 -0000 as chairs we are working on how to solve those issues. Greg Wilkins has clearly resigned from being the co-editor of the Requirement draft, and Maciej Stachowiak has been busy on other stuff... we are looking for a new co-editor(s) so to avoid in the future the lack of progress. We have already some name in mind, but if you want volunteer or have some name to suggest please do not hesitate to send an email to the chairs. Anyway the chairs will announce the decision shortly in the mailing list. we are also thinking and working on how to speed up the work on theWebSocketProtocol, and solve the issues that has been raised on it both technical and procedural issues. cheers Sal -- Salvatore Loreto www.sloreto.com On 7/20/10 12:59 AM, Alexey Melnikov wrote: > Hi SM, > > SM wrote: > > >> If the editors of the documents are too busy, it would be better to >> appoint new editors to do the work. I suggest making the final >> decision through this mailing list and not at the upcoming meeting. >> > While I would like to hear from editors (publicly on the mailing list or > privately) if they think they are too busy to work on documents and need > some help, I would like to let WG chairs to handle any changes or > appointments to editors. > > Regards, > Alexey > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ferg@caucho.com Tue Jul 20 09:36:42 2010 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 5A0B03A6B0B for ; Tue, 20 Jul 2010 09:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 cGP16NbgEcnr for ; Tue, 20 Jul 2010 09:36:40 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 5A19C3A6878 for ; Tue, 20 Jul 2010 09:36:40 -0700 (PDT) Received: (qmail 50599 invoked from network); 20 Jul 2010 16:36:50 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 20 Jul 2010 09:36:50 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: Ec79EJwVM1mXOnk5iXSwQAycJrOF_dGlqeVSg2E3ldJslF_ 3Jm7oE25jtUGAP7BUmo6bl8t3inVOIWqaWc4ZhQ68Okkp7itGGG6sxpe_NXf aQZIgwLwUKcJ4y8HuGsxYUCOTMJyBzDNUWr30dzeeeuCCCwBgxFR4LrqD.o5 TsyT_k2ZKeHCncXoi4QvtvF8AGYGcT0D8q208dVH2t2RfasK4CWaoUnarn_E DOBGT8wfc_r82SDdjI5Sys45.Rh8KoFrHKBJMUf5xfXONyAQnMMubvqMs3S_ it_t2wPwGHBN.4f0C1Mzp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C45D098.2010501@caucho.com> Date: Tue, 20 Jul 2010 09:36:40 -0700 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Salvatore Loreto References: <4C35CA30.80308@isode.com> <4C4400DB.7000400@gmx.de> <6.2.5.6.2.20100719111648.0974c0b8@resistor.net> <4C44CACB.5040108@isode.com> <4C457C9C.4030101@ericsson.com> In-Reply-To: <4C457C9C.4030101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Reminder to document editors: Internet Draft final submission cut-off is July 12 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, 20 Jul 2010 16:36:42 -0000 Salvatore Loreto wrote: > > Anyway the chairs will announce the decision shortly in the mailing list. > > we are also thinking and working on how to speed up the work on > theWebSocketProtocol, > and solve the issues that has been raised on it both technical and > procedural issues. Appointing an editor willing to work with the working group would be a good start. :) -- Scott > > cheers > Sal > > From mike@belshe.com Tue Jul 20 11:38:49 2010 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 17F423A68BE for ; Tue, 20 Jul 2010 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 mAwT8WBfZHEX for ; Tue, 20 Jul 2010 11:38:47 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 838FE3A67A7 for ; Tue, 20 Jul 2010 11:38:47 -0700 (PDT) Received: by pzk6 with SMTP id 6so2837111pzk.31 for ; Tue, 20 Jul 2010 11:39:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.199.20 with SMTP id w20mr9738718wff.251.1279651129662; Tue, 20 Jul 2010 11:38:49 -0700 (PDT) Received: by 10.142.253.4 with HTTP; Tue, 20 Jul 2010 11:38:49 -0700 (PDT) In-Reply-To: <20100720090632.GB21095@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> <20100720044352.GE14242@1wt.eu> <20100720090632.GB21095@1wt.eu> Date: Tue, 20 Jul 2010 11:38:49 -0700 Message-ID: From: Mike Belshe To: Willy Tarreau Content-Type: multipart/alternative; boundary=000e0cd25882075bd1048bd5ffc8 Cc: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Tue, 20 Jul 2010 18:38:49 -0000 --000e0cd25882075bd1048bd5ffc8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 2:06 AM, Willy Tarreau wrote: > On Tue, Jul 20, 2010 at 04:40:33PM +1000, Greg Wilkins wrote: > > On 20 July 2010 14:43, Willy Tarreau wrote: > > > Also, I would really insist that we add a "Connection: close" in the > > > initial HTTP handshake, whatever it looks like in the end, so that we > > > protect the servers against any form of request injection after the > > > first one. > > > > I think that if we fail to come up with a HTTP compliant handshake, then > a > > Connection:close would be a good get out of goal free card. > > > > However, it does prevent one possible good use case of using the HTTP > > connection as a HTTP connection in the case that websocket is rejected. > > Until websocket is widely deployed, many sites will want to fall back to > a > > HTTP transport if websockets is rejected. If the connection can be kept > > open, then it may be used by the browser for subsequent HTTP requests, > > saving a round trip. If a failed handshake response can contain other > useful > > content, then you may be able to save 2 round trips in the establishment > of > > HTTP transports. > > > > This is already an issue with cometd-2, now that we support websocket as > > an optional transport. When it is enabled, there is noticeable > additional > > establishing a comet web page (eg logging into a chat room), while > websocket > > hand shake is tried and fails, before the next handshake is tried. This > is a > > discouragement to enabling websocket support in the framework, which is > > then does not encourage infrastructure providers to support websocket. > > Agreed. Also, keeping the connection open is required with some > authentication > schemes such as NTLM which authenticate the connection instead of the > request. > While this will not be a problem on the Internet, it could make it > difficult > to integrate websocket into enterprise applications. This is another reason > not > to send any unadvertised data in the handshake by the way ! > +1. > > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd25882075bd1048bd5ffc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 2:06 AM, Willy T= arreau <w@1wt.eu> wrote:
On Tue, Jul 20, 2010 at 04:40:33PM +1000,= Greg Wilkins wrote:
> On 20 July 2010 14:43, Willy Tarreau <w= @1wt.eu> wrote:
> > Also, I would really insist that we add a "Connection: close= " in the
> > initial HTTP handshake, whatever it looks like in the end, so tha= t we
> > protect the servers against any form of request injection after t= he
> > first one.
>
> I think that if we fail to come up with a HTTP compliant handshake, th= en a
> Connection:close would be a good get out of goal free card.
>
> However, it does prevent one possible good use case of using the HTTP<= br> > connection as a HTTP connection in the case that websocket is rejected= .
> Until websocket is widely deployed, many sites will want to fall back = to a
> HTTP transport if websockets is rejected. =A0If the connection can be = kept
> open, then it may be used by the browser for subsequent HTTP requests,=
> saving a round trip. =A0If a failed handshake response can contain oth= er useful
> content, then you may be able to save 2 round trips in the establishme= nt of
> HTTP transports.
>
> This is already an issue with cometd-2, now that we support websocket = as
> an optional transport. =A0When it is enabled, there is noticeable addi= tional
> establishing a comet web page (eg logging into a chat room), while web= socket
> hand shake is tried and fails, before the next handshake is tried. =A0= This is a
> discouragement to enabling websocket support in the framework, which i= s
> then does not encourage infrastructure providers to support websocket.=

Agreed. Also, keeping the connection open is required with some= authentication
schemes such as NTLM which authenticate the connection instead of the reque= st.
While this will not be a problem on the Internet, it could make it difficul= t
to integrate websocket into enterprise applications. This is another reason= not
to send any unadvertised data in the handshake by the way !

+1.
=A0

Regards,
Willy

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

--000e0cd25882075bd1048bd5ffc8-- From ian@hixie.ch Tue Jul 20 15:03:18 2010 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 C7D463A67EC for ; Tue, 20 Jul 2010 15:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=1.169, 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 76cemVtwfdzy for ; Tue, 20 Jul 2010 15:03:17 -0700 (PDT) Received: from looneymail-a3.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 6793F3A67E7 for ; Tue, 20 Jul 2010 15:03:17 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a3.g.dreamhost.com (Postfix) with ESMTP id 06EE77D96B; Tue, 20 Jul 2010 15:03:33 -0700 (PDT) Date: Tue, 20 Jul 2010 22:03:32 +0000 (UTC) From: Ian Hickson To: Vladimir Katardjiev In-Reply-To: <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> Message-ID: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 20 Jul 2010 22:03:18 -0000 On Mon, 19 Apr 2010, Vladimir Katardjiev wrote: > > But wouldn't it be better if [the whole point of having a standard like > websocket, is so that the network infrastructure can implement the RFC > and then we have known semantics over that connection that > intermediaries can at least handle correctly, but may also do clever > stuff with]? IMHO no, not really. I think experience has taught us that while having intelligence in the network seems like a great idea, in practice having all the intelligence at the edge of the network is far superior. Indeed some of the biggest problems with deploying new technologies have been "intelligent" intermediaries -- for example, deployment of pipelining in HTTP has been delayed on the order of a decade because of man-in-the- middle proxies. Indeed, this insight -- that the core network should be dumb and the clverness should be in the edge -- is one of the underlying principles on which TCP/IP was built. > Let's take a couple of hypothetical scenarios where an amateur > programmer can _transparently_ gain additional, desirable functionality > by an intermediary "messing" with a well-defined protocol. > > 1. Compression > For all the talk about transferring 5gb using WebSockets, the FCC still > maintains a fairly conservative definition of "broadband" at 768kbps. I > believe the US average broadband speed was a handy contribution to the > speed savings that SPDY's compression of data made possible. In other > words, it's not unlikely that a future iteration of WebSockets adds > compression (let's say gzip) to the equation. > > Obviously, for this to work it needs to be optional, because otherwise > we raise the barrier of entry. But in some deployments it is a desirable > thing for the ISP to add. An ISP might want to compress the traffic to > lower the load on their edge network (or their 768kbps broadband > customers) In the case of a mobile network, the shorter time the radio > is kept alive, the more battery savings, so it's highly desirable to > compress WebSocket connections if appropriate. Why would they compress jsut WebSockets and not simply compress all IP traffic? Suppose though that there is some reason why WebSocket traffic should be compressed specifically. Nothing prevents a man-in-the-middle proxy from intercepting WebSocket handshakes and traffic and implementing the compression for the client transparently. The proxy would just act as a server for the real client, and act as a client for the real server. Neither side need know that anything is going on. So this case appears to already be handled. (Or will be, once we define how to opt into compression at the WebSocket layer, if we add that.) > 2. Optimisation > Suppose we had a way of determining that a client cannot receive > messages larger than 1mb, due to memory restrictions. (Feel free to > substitute it with 5gb for the 2020 scenario). Wouldn't it be a waste of > time to send all that data to the remote client only for it to discover > that state on its own? For a mobile client, if the behaviour on too > large frames is well-defined, we may even handle it without waking the > client up (or close the connection if that's the defined behaviour) > potentially saving a lot of bandwidth and battery. If you have control over the device, then there's no reason not to define the client as being a distributed piece of software that spans the network from the base station to the device, and thus there's no need to wake the device to handle an incoming frame that's too big. (That seems like a weird optimisation though. You're likely going to have to wake the device anyway to let it know the connection was terminated, since that can run some JS.) > 3. Error checking > A properly written intermediary is also expertly written. So it would be > able to prevent protocol exploits that may appear. In addition, these > types of intermediaries would be maintained for the purpose of security > and thus updated faster than you could hypothetically update client(s) > and server(s). While it doesn't eliminate the spread of exploits and > malware, it can reduce it. If we are supposed to be as concerned as we > are about security, we should also cover the possibility that there may > be a security hole in the future (one that we couldn't consider now) and > make sure it can be protected. An intermediary can be a part of such a > solution, but that also implies we must have intermediaries that can > talk WebSockets. That's such a hypothetical case (a well-written intermediary that is updated faster than the client is something that I've never heard of before, and fixing a security bug in the protocol or in the client might well require violating the protocol by definition) that I'm not really sure how to apply it concretely. > 4. Deployment > This falls into the category of "making the protocol actually work", but > I do count it as a benefit to the amateur programmer because, yeah, I > don't quite think TLS is so trivial to implement either. I don't > remember where the original reference is, but I don't think creating a > protocol whose design goal is to be wrapped end to end in TLS to > simulate having open network access is going to work. > > For one, you can't guarantee having no intermediaries with TLS (for the > amateur programmer). All you need to do to MITM a TLS connection is, > well, an intermediary box (I'd wager most ISPs can arrange one of those) > and a signed certificate (shouldn't be an issue either). Since the > WebSocket connection is user transparent they won't notice that the > certificate no longer says Bank.com but ISP.com. Or Corporation.com for > that matter. (I won't discuss ethics/morality/legality, just technology) The protocol would reject such a connection if the certification didn't match the host name. > I don't think working on bypassing intermediaries for all traffic is a > productive avenue. Rather, I think it'd just lead to a pointless arms > race. The spec's design doesn't intentionally bypass intermediaries, it just doesn't consider compatibility with intermediaries or supporting intermediaries to be a priority. Having seen what a mess HTTP has had to contend with when it comes to intermediaries, this seems wise, IMHO. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Tue Jul 20 15:13:50 2010 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 0A88C3A6892 for ; Tue, 20 Jul 2010 15:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.780, 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 XoqQ4RLVgy3S for ; Tue, 20 Jul 2010 15:13:48 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 8F0B73A67E7 for ; Tue, 20 Jul 2010 15:13:48 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 6434B2BA84; Tue, 20 Jul 2010 15:14:04 -0700 (PDT) Date: Tue, 20 Jul 2010 22:14:04 +0000 (UTC) From: Ian Hickson To: Roberto Peon In-Reply-To: Message-ID: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 20 Jul 2010 22:13:50 -0000 (By the way, I spoke to Joe and he suggested that I post an e-mail to each thread to which I was replying, rather than replying to all threads in one bulk e-mail or replying to all the e-mails I'm replying to individually. I hope this compromise works for everyone; I know there was some controversy when I replied in bulk a few months ago. I apologise in advance if this causes a spike in traffic to the list.) On Mon, 19 Apr 2010, Roberto Peon wrote: > On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote: > > > On 19.04.2010 10:48, Ian Hickson wrote: > > > > > > > > There are many many implementations of HTTP. Some fast, some not > > > > so. Some complete, some not so. > > > > > > I think we can get orders of magnitude more complete implementations > > > of Web Sockets than of HTTP if we keep the protocol trivial. > > > > Yes. That's a given. Make it less complex, and it will be easier to > > completely implement. > > This isn't true! Make it (the protocol) less complex and it will be easy > to implement something which *conforms to the spec*, but not necessarily > something which scales and is robust, reliable, and scalable in the face > of all the stuff that happens out there. Not all implementations have to scale to a million QPS or withstand DDOS attacks for weeks at a time. Most implementations of Web Sockets will likely be for small amateur projects that are lucky if they average 1 QPH, let alone 1 QPS. > The latter part is what really worries me. We really need to be sure > that the protocol that we create allows for an implementation of a > server to do these things. I agree that we shouldn't make the protocol impossible to scale. If there are specific features in the protocol that make it impossible to scale, please do raise these as issues. However, one doesn't have to make a protocol complex to make it scale. > If the (hopefully small) added complexity is too much for the amateur > programmer, then they should use the API level. What I'm interested in personally is writing a protocol that amateur programmers can implement easily. If we say they have to use someone else's code to do this, then that's a failure, IMHO. (Though as I've mentioned before, if people have different goals or priorities, I have no problem with separate protocols also being designed to address those -- Web Sockets doesn't have to be everything for everybody.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jat@google.com Tue Jul 20 15:21:11 2010 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 8A2873A6809 for ; Tue, 20 Jul 2010 15:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yIT5BFA6V4YQ for ; Tue, 20 Jul 2010 15:21:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8A7F83A65A5 for ; Tue, 20 Jul 2010 15:21:08 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6KMLNHw020554 for ; Tue, 20 Jul 2010 15:21:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279664484; bh=hLKv/xyFf9AldcK47ns6iCi68xQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kS2VebJHvkiM/xRO2rGCFEREcSc0L+jf22ohDy6R/R/+nKwDrNbfpsK4SDlEnPbuY AONspueqGzITvcluSshmg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=U0jW01ZaX/gC+GTW6rGM0WmGJcXVGKQIea58Bh6BVfInqfD1l3rIhKj0/sijVHn69 2dCYTjOFL7uwI8o43Agrg== Received: from gxk26 (gxk26.prod.google.com [10.202.11.26]) by kpbe20.cbf.corp.google.com with ESMTP id o6KMKPx7017670 for ; Tue, 20 Jul 2010 15:21:23 -0700 Received: by gxk26 with SMTP id 26so4451564gxk.10 for ; Tue, 20 Jul 2010 15:21:22 -0700 (PDT) Received: by 10.150.225.17 with SMTP id x17mr1212256ybg.6.1279664482212; Tue, 20 Jul 2010 15:21:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.60.3 with HTTP; Tue, 20 Jul 2010 15:21:02 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> From: John Tamplin Date: Tue, 20 Jul 2010 18:21:02 -0400 Message-ID: To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd40332e4daf8048bd91ab5 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 20 Jul 2010 22:21:11 -0000 --000e0cd40332e4daf8048bd91ab5 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 20, 2010 at 6:14 PM, Ian Hickson wrote: > What I'm interested in personally is writing a protocol that amateur > programmers can implement easily. If we say they have to use someone > else's code to do this, then that's a failure, IMHO. (Though as I've > mentioned before, if people have different goals or priorities, I have no > problem with separate protocols also being designed to address those -- > Web Sockets doesn't have to be everything for everybody.) I still don't see the argument for servers written by amateurs. I have used far more quick-and-dirty web clients (telnet, socket/connect/write in C, wget/curl, etc) than I have quick-and-dirty servers. If some amateur needs to write a server anyway, they aren't going to write it from scratch even if it were possible for them to do so -- they will find some library. Contrast this with embedded clients, which might well have tighter constraints than most clients, and could benefit from having optional features they could leave out that would be useful for more powerful clients. Meanwhile, the servers are going to almost certainly be on more powerful machines, though granted they have more connections to support. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd40332e4daf8048bd91ab5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 20, 2010 at 6:14 PM, Ian Hickson <ian@hixie.ch> wrote:
What I'm interested in personally is writing a protocol that amateur programmers can implement easily. If we say they have to use someone
else's code to do this, then that's a failure, IMHO. (Though as I&#= 39;ve
mentioned before, if people have different goals or priorities, I have no problem with separate protocols also being designed to address those --
Web Sockets doesn't have to be everything for everybody.)
<= div>
I still don't see the argument for servers written b= y amateurs. =C2=A0I have used far more quick-and-dirty web clients (telnet,= socket/connect/write in C, wget/curl, etc) than I have quick-and-dirty ser= vers. =C2=A0If some amateur needs to write a server anyway, they aren't= going to write it from scratch even if it were possible for them to do so = -- they will find some library.

Contrast this with embedded clients, which might well h= ave tighter constraints than most clients, and could benefit from having op= tional features they could leave out that would be useful for more powerful= clients. =C2=A0Meanwhile, the servers are going to almost certainly be on = more powerful machines, though granted they have more connections to suppor= t.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd40332e4daf8048bd91ab5-- From fenix@google.com Tue Jul 20 15:33:45 2010 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 3B7613A6892 for ; Tue, 20 Jul 2010 15:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 BfYbuYY7x3TM for ; Tue, 20 Jul 2010 15:33:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C6F813A6809 for ; Tue, 20 Jul 2010 15:33:41 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o6KMXv8b003211 for ; Tue, 20 Jul 2010 15:33:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279665237; bh=6bMQp1tNjSx0zGbunOIwPckVbug=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bmN4UJh3s9Z555oEZ5FmxzGXatj4jnlIONL+nkdS5vP5XqtKdP59Pl7VLebegEF+M qDXoANK+CRE8puYi+g0Wg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Z8GfQQAITzopW643bS74mmcQ7W/xJXiONrS9cIlr1UrT5r2Nd3AK6RBjYbRR9z2uI glvPKcWsfkNF64Mod9Gvg== Received: from gwb10 (gwb10.prod.google.com [10.200.2.10]) by kpbe16.cbf.corp.google.com with ESMTP id o6KMXehl017716 for ; Tue, 20 Jul 2010 15:33:56 -0700 Received: by gwb10 with SMTP id 10so3805535gwb.12 for ; Tue, 20 Jul 2010 15:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.116.1 with SMTP id t1mr1083016ybm.329.1279665235754; Tue, 20 Jul 2010 15:33:55 -0700 (PDT) Received: by 10.150.59.4 with HTTP; Tue, 20 Jul 2010 15:33:55 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> Date: Tue, 20 Jul 2010 15:33:55 -0700 Message-ID: From: Roberto Peon To: Ian Hickson Content-Type: multipart/alternative; boundary=001e680f13b8cf03f2048bd947e9 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 20 Jul 2010 22:33:45 -0000 --001e680f13b8cf03f2048bd947e9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 3:14 PM, Ian Hickson wrote: > > (By the way, I spoke to Joe and he suggested that I post an e-mail to each > thread to which I was replying, rather than replying to all threads in one > bulk e-mail or replying to all the e-mails I'm replying to individually. I > hope this compromise works for everyone; I know there was some controversy > when I replied in bulk a few months ago. I apologise in advance if this > causes a spike in traffic to the list.) > > On Mon, 19 Apr 2010, Roberto Peon wrote: > > On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote: > > > > On 19.04.2010 10:48, Ian Hickson wrote: > > > > > > > > > > There are many many implementations of HTTP. Some fast, some not > > > > > so. Some complete, some not so. > > > > > > > > I think we can get orders of magnitude more complete implementations > > > > of Web Sockets than of HTTP if we keep the protocol trivial. > > > > > > Yes. That's a given. Make it less complex, and it will be easier to > > > completely implement. > > > > This isn't true! Make it (the protocol) less complex and it will be easy > > to implement something which *conforms to the spec*, but not necessarily > > something which scales and is robust, reliable, and scalable in the face > > of all the stuff that happens out there. > > Not all implementations have to scale to a million QPS or withstand DDOS > attacks for weeks at a time. Most implementations of Web Sockets will > likely be for small amateur projects that are lucky if they average 1 QPH, > let alone 1 QPS. > > > > The latter part is what really worries me. We really need to be sure > > that the protocol that we create allows for an implementation of a > > server to do these things. > > I agree that we shouldn't make the protocol impossible to scale. If there > are specific features in the protocol that make it impossible to scale, > please do raise these as issues. However, one doesn't have to make a > protocol complex to make it scale. > We need browser-owned connections with a security model that allows multiple tabs to share the connection safely. This is probably the most important requirement for scalability as far as I'm concerned. This requires fewer keep-alives (both because of fewer TCP connections and because the TCP connection is more likely to have real content sent on it instead of near-zero value'd keep-alives), it requires fewer file descriptors, it requires fewer handshakes. -=R > > > > If the (hopefully small) added complexity is too much for the amateur > > programmer, then they should use the API level. > > What I'm interested in personally is writing a protocol that amateur > programmers can implement easily. If we say they have to use someone > else's code to do this, then that's a failure, IMHO. (Though as I've > mentioned before, if people have different goals or priorities, I have no > problem with separate protocols also being designed to address those -- > Web Sockets doesn't have to be everything for everybody.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > --001e680f13b8cf03f2048bd947e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 3:14 PM, Ian Hic= kson <ian@hixie.ch= > wrote:

(By the way, I spoke to Joe and he suggested that I post an e-mail to each<= br> thread to which I was replying, rather than replying to all threads in one<= br> bulk e-mail or replying to all the e-mails I'm replying to individually= . I
hope this compromise works for everyone; I know there was some controversy<= br> when I replied in bulk a few months ago. I apologise in advance if this
causes a spike in traffic to the list.)

On Mon, 19 Apr 2010, Roberto Peon wrote:
> On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote:
> > > On 19.04.2010 10:48, Ian Hickson wrote:
> > > >
> > > > There are many many implementations of HTTP. Some fast,= some not
> > > > so. =A0Some complete, some not so.
> > >
> > > I think we can get orders of magnitude more complete impleme= ntations
> > > of Web Sockets than of HTTP if we keep the protocol trivial.=
> >
> > Yes. That's a given. Make it less complex, and it will be eas= ier to
> > completely implement.
>
> This isn't true! Make it (the protocol) less complex and it will b= e easy
> to implement something which *conforms to the spec*, but not necessari= ly
> something which scales and is robust, reliable, and scalable in the fa= ce
> of all the stuff that happens out there.

Not all implementations have to scale to a million QPS or withstand D= DOS
attacks for weeks at a time. Most implementations of Web Sockets will
likely be for small amateur projects that are lucky if they average 1 QPH,<= br> let alone 1 QPS.


> The latter part is what really worries me. We really need to be sure > that the protocol that we create allows for an implementation of a
> server to do these things.

I agree that we shouldn't make the protocol impossible to scale. = If there
are specific features in the protocol that make it impossible to scale,
please do raise these as issues. However, one doesn't have to make a protocol complex to make it scale.

We n= eed browser-owned connections with a security model that allows multiple ta= bs to share the connection safely.
This is probably the most impo= rtant requirement for scalability as far as I'm concerned. This require= s fewer keep-alives (both because of fewer TCP connections and because the = TCP connection is more likely to have real content sent on it instead of ne= ar-zero value'd keep-alives), it requires fewer file descriptors, it re= quires fewer handshakes.

-=3DR
=A0


> If the (hopefully small) added complexity is too much for the amateur<= br> > programmer, then they should use the API level.

What I'm interested in personally is writing a protocol that amat= eur
programmers can implement easily. If we say they have to use someone
else's code to do this, then that's a failure, IMHO. (Though as I&#= 39;ve
mentioned before, if people have different goals or priorities, I have no problem with separate protocols also being designed to address those --
Web Sockets doesn't have to be everything for everybody.)

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'

--001e680f13b8cf03f2048bd947e9-- From mike@belshe.com Tue Jul 20 16:09:54 2010 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 4385C3A68D5 for ; Tue, 20 Jul 2010 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 2QC9-5iw6N9D for ; Tue, 20 Jul 2010 16:09:52 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 69BA63A6892 for ; Tue, 20 Jul 2010 16:09:52 -0700 (PDT) Received: by pwj1 with SMTP id 1so3458451pwj.31 for ; Tue, 20 Jul 2010 16:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.199.20 with SMTP id w20mr10234233wff.254.1279667407896; Tue, 20 Jul 2010 16:10:07 -0700 (PDT) Received: by 10.142.75.9 with HTTP; Tue, 20 Jul 2010 16:10:07 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> Date: Tue, 20 Jul 2010 16:10:07 -0700 Message-ID: From: Mike Belshe To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd25882475dfb048bd9c9a5 Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 20 Jul 2010 23:09:54 -0000 --000e0cd25882475dfb048bd9c9a5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 3:14 PM, Ian Hickson wrote: > > (By the way, I spoke to Joe and he suggested that I post an e-mail to each > thread to which I was replying, rather than replying to all threads in one > bulk e-mail or replying to all the e-mails I'm replying to individually. I > hope this compromise works for everyone; I know there was some controversy > when I replied in bulk a few months ago. I apologise in advance if this > causes a spike in traffic to the list.) > > On Mon, 19 Apr 2010, Roberto Peon wrote: > > On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote: > > > > On 19.04.2010 10:48, Ian Hickson wrote: > > > > > > > > > > There are many many implementations of HTTP. Some fast, some not > > > > > so. Some complete, some not so. > > > > > > > > I think we can get orders of magnitude more complete implementations > > > > of Web Sockets than of HTTP if we keep the protocol trivial. > > > > > > Yes. That's a given. Make it less complex, and it will be easier to > > > completely implement. > > > > This isn't true! Make it (the protocol) less complex and it will be easy > > to implement something which *conforms to the spec*, but not necessarily > > something which scales and is robust, reliable, and scalable in the face > > of all the stuff that happens out there. > > Not all implementations have to scale to a million QPS or withstand DDOS > attacks for weeks at a time. Most implementations of Web Sockets will > likely be for small amateur projects that are lucky if they average 1 QPH, > let alone 1 QPS. > > > > The latter part is what really worries me. We really need to be sure > > that the protocol that we create allows for an implementation of a > > server to do these things. > > I agree that we shouldn't make the protocol impossible to scale. If there > are specific features in the protocol that make it impossible to scale, > please do raise these as issues. However, one doesn't have to make a > protocol complex to make it scale. > > > > If the (hopefully small) added complexity is too much for the amateur > > programmer, then they should use the API level. > > What I'm interested in personally is writing a protocol that amateur > programmers can implement easily. If we say they have to use someone > else's code to do this, then that's a failure, IMHO. (Though as I've > mentioned before, if people have different goals or priorities, I have no > problem with separate protocols also being designed to address those -- > Web Sockets doesn't have to be everything for everybody.) > For as adamantly as Ian states that it should be a requirement, I am just as adamant that it should not. But more importantly, this single issue has been holding protocol progress hostage. Naturally, any feature has some amount of complexity. But this requirement creates an invisible, and subjective barrier to each feature. Is the feature too complex for an amateur programmer? Nobody knows, and everyone disagrees, because it is a subjective criteria. So we spin and can't agree. Every protocol expert I've spoken with agrees that amateur protocol implementors should not be a requirement. Is there some way we can vote to either keep or nullify this requirement now and never come back to it again? I'm tired of this obstacle holding everything up. Mike > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd25882475dfb048bd9c9a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 3:14 PM, Ian Hic= kson <ian@hixie.ch= > wrote:

(By the way, I spoke to Joe and he suggested that I post an e-mail to each<= br> thread to which I was replying, rather than replying to all threads in one<= br> bulk e-mail or replying to all the e-mails I'm replying to individually= . I
hope this compromise works for everyone; I know there was some controversy<= br> when I replied in bulk a few months ago. I apologise in advance if this
causes a spike in traffic to the list.)

On Mon, 19 Apr 2010, Roberto Peon wrote:
> On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote:
> > > On 19.04.2010 10:48, Ian Hickson wrote:
> > > >
> > > > There are many many implementations of HTTP. Some fast,= some not
> > > > so. =A0Some complete, some not so.
> > >
> > > I think we can get orders of magnitude more complete impleme= ntations
> > > of Web Sockets than of HTTP if we keep the protocol trivial.=
> >
> > Yes. That's a given. Make it less complex, and it will be eas= ier to
> > completely implement.
>
> This isn't true! Make it (the protocol) less complex and it will b= e easy
> to implement something which *conforms to the spec*, but not necessari= ly
> something which scales and is robust, reliable, and scalable in the fa= ce
> of all the stuff that happens out there.

Not all implementations have to scale to a million QPS or withstand D= DOS
attacks for weeks at a time. Most implementations of Web Sockets will
likely be for small amateur projects that are lucky if they average 1 QPH,<= br> let alone 1 QPS.


> The latter part is what really worries me. We really need to be sure > that the protocol that we create allows for an implementation of a
> server to do these things.

I agree that we shouldn't make the protocol impossible to scale. = If there
are specific features in the protocol that make it impossible to scale,
please do raise these as issues. However, one doesn't have to make a protocol complex to make it scale.


> If the (hopefully small) added complexity is too much for the amateur<= br> > programmer, then they should use the API level.

What I'm interested in personally is writing a protocol that amat= eur
programmers can implement easily. If we say they have to use someone
else's code to do this, then that's a failure, IMHO. (Though as I&#= 39;ve
mentioned before, if people have different goals or priorities, I have no problem with separate protocols also being designed to address those --
Web Sockets doesn't have to be everything for everybody.)

For as adamantly as Ian states that it should be a r= equirement, I am just as adamant that it should not.

But more importantly, this single issue has been holding protocol prog= ress hostage. =A0Naturally, any feature has some amount of complexity. =A0 = But this requirement creates an invisible, and subjective barrier to each f= eature. =A0Is the feature too complex for an amateur programmer? =A0Nobody = knows, and everyone disagrees, because it is a subjective criteria. =A0So w= e spin and can't agree.

Every protocol expert I've spoken with agrees that = amateur protocol implementors should not be a requirement.

Is there some way we can vote to either keep or nullify this requi= rement now and never come back to it again? =A0I'm tired of this obstac= le holding everything up.

Mike


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'
_______________________________________________

--000e0cd25882475dfb048bd9c9a5-- From ian@hixie.ch Tue Jul 20 16:14:17 2010 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 D07F33A68D5 for ; Tue, 20 Jul 2010 16:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, 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 SWMOChe9HZlO for ; Tue, 20 Jul 2010 16:14:08 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 030393A6925 for ; Tue, 20 Jul 2010 16:14:01 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 3C87D15D572; Tue, 20 Jul 2010 16:14:17 -0700 (PDT) Date: Tue, 20 Jul 2010 23:14:16 +0000 (UTC) From: Ian Hickson To: Wellington Fernando de Macedo , Christian Biesinger , "Thomson, Martin" , Greg Wilkins , Jamie Lokier In-Reply-To: <20100423103715.GB32366@shareable.org> Message-ID: References: <4BCF4932.8040303@gmail.com> <4BD09A2C.6060506@gmail.com> <8B0A9FCBB9832F43971E38010638454F03E7D06DF7@SISPE7MB1.commscope.com> <20100422225448.GG13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E00@SISPE7MB1.commscope.com> <20100422230957.GI13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E06@SISPE7MB1.commscope.com> <20100423001858.GA22326@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E28@SISPE7MB1.commscope.com> <20100423103715.GB32366@shareable.org> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiple connections serialization and proxies 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, 20 Jul 2010 23:14:18 -0000 On Wed, 21 Apr 2010, Wellington Fernando de Macedo wrote: > > A question has been raised in the Mozilla implementation. The spec > states: > > 1. If the user agent already has a WebSocket connection to the > remote host (IP address) identified by /host/, even if known by > another name, wait until that connection has been established or > for that connection to have failed. > > However, when the WS is under proxies, we can't leak the host names to > the DNS server. In this case, what should be done? I think the spec > should clarify this. Done. It now says that in that case, host names should be assumed to be distinct from each other, but that the UA should have an overall limit. http://html5.org/tools/web-apps-tracker?from=5169&to=5170 On Thu, 22 Apr 2010, Christian Biesinger wrote: > > Note that if you want websockets to be similar to HTTP, it should always > use host names instead of IP addresses for connection limits. At least > Firefox uses hostnames for HTTP's limit, I'm not quite sure on the other > browsers. Using host names for this particular limit wouldn't work since it would mean an attacker could just have a bunch of different host names all binding to the same IP to DOS the host. On Fri, 23 Apr 2010, Thomson, Martin wrote: > > So, the only protection against multi-connection-DOS from the one client > is to request that the client not have more than one connection attempt > in progress at a time. > > This only works if the client doesn't get rejected straight away, > otherwise, the round trip time is the only limiting factor, which isn't > that great. > > Some (security considerations) advice on what a server might do to take > advantage of the client-side requirement would be good. I've slightly ammended the note in the aforementioned step to mention that the server can simply delay before terminating the connection if it wants to take advantage of this. It seems pretty obvious though, I don't know that we need to belabour the point. On Fri, 23 Apr 2010, Greg Wilkins wrote: > > My preference would be to enable the use of a single connection > with multiplexing - so that multiple "connections" would not need to > suffer the cost of any RTT for TCP, TLS etc. and would certainly > not need to be serialized with other "connections" establishment. That seems reasonably straight-forward to support at the application layer. On Fri, 23 Apr 2010, Jamie Lokier wrote: > > Once the number is limited, the bandwidth can be limited by the server > itself slowing down responses when it see repeated requests from the > same client IP. > > Unfortunately it can't distinguish different clients from the same IP - > so clients can DOS other clients if the server does this, which is also > a problem. It seems relatively simple for a browser to rotate amongst the various origins that are trying to connect, to avoid this problem being serious. The UA could also explicitly announce to the user that one tab (from one origin) is being prevented from connecting to a particular server while another tab (from another origin) connects to it, especially if the latter one keeps getting declined. In practice, though, this is unlikely to be that much of a problem -- this attack is already possible today using HTTP, and yet is rarely an issue. (In fact the only time I've seen it be a real issue is when an origin DOSsed itself, e.g. if you open three tabs to the same host and all three try to do a long-lived GET.) > Therefore clients should identify themselves somehow. (Clients could > cheat, but cheating clients won't obey the anti-DOS requirements > anyway.) The "client" here is the origin, which is already in the handshake. > Another aspect of client-side DOS protection is at what point is the > "connection" considered "established", to permit more? It should be > later rather than earlier in the negotiation process, to prevent DOS > against server-side negotiation resources especially TLS. As far as I can tell, the definition is unambiguous here. > I favour the server being able to send back a number saying how many > more connections are permitted now. Negotiated flow control, rather > than spec'd fixed values (except the first). There could still be a > default, for simple implementations. That seems like something we should add in a future version, if it really is needed. Baby steps, keep things simple, etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From metajack@gmail.com Tue Jul 20 16:16:12 2010 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 854A63A6959 for ; Tue, 20 Jul 2010 16:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 t8rT-jAvKauO for ; Tue, 20 Jul 2010 16:16:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 88C9C3A693B for ; Tue, 20 Jul 2010 16:16:11 -0700 (PDT) Received: by vws13 with SMTP id 13so1170577vws.31 for ; Tue, 20 Jul 2010 16:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=D2bqpwON6zH7Fi8F/75RBh3oTRZqaEqh2sU9DG+Ja6A=; b=pWBwNJ1b6a+64+8qQ4or1z1IHMN50DveSK2JXlgCxT58Hx/R6ryYXaGtQMYH07Jzjh 23x4AEHpHqQsltgq/3hWJiHpifGr4dnQrgnRDn1fILksWD7Ld5A+QMhSoHfG15sA1E70 mR+vTkQScWUEi/cAUrspF10cB4NNPHI4yHMS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=IeCwuMLLc/Y/4f4s9kDdUKDLWplUeAltHfMXPwtQFB34U3E3Gkt3iCfspsxOKxfxmZ wWBi8bg0yso1Q+AKCdcmKwiHgvkc6CHcnT/8fPQTMoF1Ll6KkMcgXs1laiaud/VLxJJf FpwC0cBIezZOf/v9VsKpxziZ/eKbC7ixi2eDY= MIME-Version: 1.0 Received: by 10.224.59.195 with SMTP id m3mr6516304qah.34.1279667785933; Tue, 20 Jul 2010 16:16:25 -0700 (PDT) Sender: metajack@gmail.com Received: by 10.229.74.7 with HTTP; Tue, 20 Jul 2010 16:16:25 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> Date: Tue, 20 Jul 2010 17:16:25 -0600 X-Google-Sender-Auth: -73uUAEOzWJP-PEIa1BU7iKipks Message-ID: From: Jack Moffitt To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Extensibility mechanisms? 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, 20 Jul 2010 23:16:12 -0000 > Every protocol expert I've spoken with agrees that amateur protocol > implementors should not be a requirement. > Is there some way we can vote to either keep or nullify this requirement = now > and never come back to it again? =A0I'm tired of this obstacle holding > everything up. It seems to me that any protocol that requires security is already outside the reach of amateur developers without library support. If they must rely on libraries written by professionals for security, why is it so bizarre to ask them to rely on libraries for other functions that are also complex and hairy? I think this is getting at the root of the issues. We either need to strike this requirement or give it some concrete meaning. As I'm not sure such meaning can be easily provided, striking the 'amateur programmer' requirement seems prudent. jack. From ferg@caucho.com Tue Jul 20 16:22:06 2010 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 CBD753A6972 for ; Tue, 20 Jul 2010 16:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 JokZuEgTznV6 for ; Tue, 20 Jul 2010 16:22:01 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 1DB3F3A6925 for ; Tue, 20 Jul 2010 16:22:00 -0700 (PDT) Received: (qmail 63335 invoked from network); 20 Jul 2010 23:22:11 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 20 Jul 2010 16:22:11 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: lssh2sgVM1k.OsicPkVyTZCmh64wQSqmPebhvuRxvofTLR0 3heGK0WlSO3MtJZLJulOS8s2cQWXuYgAZUvHu9lxHM9XhKolHThLFue7GNbc 6Ho64cn8iJNrUshAiPMeqiP5MjUmW.tRZxBJ9WA4qhIiU5jMNNDPb4zMsRJw NuNEua0FY07btSYJIoU0Te.U.ownvvA1x_eQKLs4MX2MC11Eq2lS0RBaQdEt 45EPTfFmffae7MMXAHWarrc9EgwYy.A_PuLeMN7O_AsO27NhKSMjAWLNJBGp nPht5LEdq.mAKYezGOW9C X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C462F9E.9030207@caucho.com> Date: Tue, 20 Jul 2010 16:22:06 -0700 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mike Belshe References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 20 Jul 2010 23:22:06 -0000 Mike Belshe wrote: > > For as adamantly as Ian states that it should be a requirement, I am > just as adamant that it should not. > > Every protocol expert I've spoken with agrees that amateur protocol > implementors should not be a requirement. > > Is there some way we can vote to either keep or nullify this > requirement now and never come back to it again? I'm tired of this > obstacle holding everything up. +1 -- Scott From mike@belshe.com Tue Jul 20 16:28:54 2010 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 CFB773A68DB for ; Tue, 20 Jul 2010 16:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 IQYBm-ci5YVg for ; Tue, 20 Jul 2010 16:28:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 9E9823A65A5 for ; Tue, 20 Jul 2010 16:28:51 -0700 (PDT) Received: by pvd12 with SMTP id 12so3466442pvd.31 for ; Tue, 20 Jul 2010 16:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.174.4 with SMTP id w4mr4489274wfe.264.1279668547401; Tue, 20 Jul 2010 16:29:07 -0700 (PDT) Received: by 10.142.75.9 with HTTP; Tue, 20 Jul 2010 16:29:07 -0700 (PDT) In-Reply-To: <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> Date: Tue, 20 Jul 2010 16:29:07 -0700 Message-ID: From: Mike Belshe To: Vladimir Katardjiev Content-Type: multipart/alternative; boundary=000e0cd2be4632ba5d048bda0da7 Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 20 Jul 2010 23:28:55 -0000 --000e0cd2be4632ba5d048bda0da7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 19, 2010 at 7:47 AM, Vladimir Katardjiev wrote: > On 16 apr 2010, at 22.13, Ian Hickson wrote: > > On Fri, 16 Apr 2010, Greg Wilkins wrote: > >> > >> The whole point of having a standard like websocket, is so that the > >> network infrastructure can implement the RFC and then we have known > >> semantics over that connection that intermediaries can at least handle > >> correctly, but may also do clever stuff with. > > > > That wasn't even on my list of reasons for originally coming up with > > TCPConnection, let alone the main reason. > > > > > The main reason for the Web Socket protocol is to have one protocol that > > the browsers can all implement in an interoperable fashion so that > servers > > can implement things once and have them work with all browsers. In the > > ideal deployment the connection is wrapped in end-to-end TLS, so the > > intermediaries can't do anything with it. There were only two reasons for > > even allowing unencrypted Web Socket originally: requiring amateurs to > > figure out TLS seemed like too high a bar, and there is still some > concern > > that when the connection is being used for entirely public information, > > the TLS connection overhead is too expensive to justify. > > Fair enough, it wasn't originally. But wouldn't it be better if it did? > Let's take a couple of hypothetical scenarios where an amateur programmer > can _transparently_ gain additional, desirable functionality by an > intermediary "messing" with a well-defined protocol. > > 1. Compression > For all the talk about transferring 5gb using WebSockets, the FCC still > maintains a fairly conservative definition of "broadband" at 768kbps. I > believe the US average broadband speed was a handy contribution to the speed > savings that SPDY's compression of data made possible. In other words, it's > not unlikely that a future iteration of WebSockets adds compression (let's > say gzip) to the equation. > For the SPDY data point - for low speed links, the header compression matters. For high speed links, it doesn't. SPDYs gains mostly come from other factors. I wish I had the graphs handy, but I do not. > > Obviously, for this to work it needs to be optional, because otherwise we > raise the barrier of entry. But in some deployments it is a desirable thing > for the ISP to add. An ISP might want to compress the traffic to lower the > load on their edge network (or their 768kbps broadband customers) In the > case of a mobile network, the shorter time the radio is kept alive, the more > battery savings, so it's highly desirable to compress WebSocket connections > if appropriate. > > 2. Optimisation > Suppose we had a way of determining that a client cannot receive messages > larger than 1mb, due to memory restrictions. (Feel free to substitute it > with 5gb for the 2020 scenario). Wouldn't it be a waste of time to send all > that data to the remote client only for it to discover that state on its > own? For a mobile client, if the behaviour on too large frames is > well-defined, we may even handle it without waking the client up (or close > the connection if that's the defined behaviour) potentially saving a lot of > bandwidth and battery. > > 3. Error checking > A properly written intermediary is also expertly written. So it would be > able to prevent protocol exploits that may appear. In addition, these types > of intermediaries would be maintained for the purpose of security and thus > updated faster than you could hypothetically update client(s) and server(s). > While it doesn't eliminate the spread of exploits and malware, it can reduce > it. If we are supposed to be as concerned as we are about security, we > should also cover the possibility that there may be a security hole in the > future (one that we couldn't consider now) and make sure it can be > protected. An intermediary can be a part of such a solution, but that also > implies we must have intermediaries that can talk WebSockets. > Let me try to be objective about the tradeoff here: When everything is encrypted and authenticated at the endpoints, it prevents an intermediary (who's motivations may be different than yours) from taking action. When data is not encrypted & authenticated, intermediaries, which have different motivations (good or bad) are possible. So the sad news is that for every good motivation, there is an equal and opposite bad motivation as a counter argument... > > 4. Deployment > This falls into the category of "making the protocol actually work", but I > do count it as a benefit to the amateur programmer because, yeah, I don't > quite think TLS is so trivial to implement either. I don't remember where > the original reference is, but I don't think creating a protocol whose > design goal is to be wrapped end to end in TLS to simulate having open > network access is going to work. > > For one, you can't guarantee having no intermediaries with TLS (for the > amateur programmer). All you need to do to MITM a TLS connection is, well, > an intermediary box (I'd wager most ISPs can arrange one of those) and a > signed certificate (shouldn't be an issue either). Since the WebSocket > connection is user transparent they won't notice that the certificate no > longer says Bank.com but ISP.com. Or Corporation.com for that matter. (I > won't discuss ethics/morality/legality, just technology) > Actually, if you do that, the browser throws up a huge red box saying "danger". The MITM will not have a signing cert for a CA trusted by the browser. So, the cert will be signed by the ISP or other transparent intermediary, which won't match the trusted CA list, and the browser will complain. Corporations can get around this by forcing a CA cert onto the browser; but that is no longer a transparent intermediary - it was specifically granted permission at the endpoint. Of course, the user, not knowing what the hell is going on, will click through anyway, think "that's weird", and everything else will still work. BTW - there is another data point here; deployment of WebSockets over port 80 was measured in Chrome to have ~67% success rate today. Deployment over port 443 (with TLS) has a >95% success rate. So, if you don't use TLS, then browsers and websites will need to be made more complex to deal with the edge case of WebSockets failing in weird ways due to existing intermediaries which fail, even after the WebSocket handshake. Mike > > (course, this won't work if the TLS box shares https and wss traffic, but > then we're not dealing with the amateur programmer are we?) > > I don't think working on bypassing intermediaries for all traffic is a > productive avenue. Rather, I think it'd just lead to a pointless arms race. > It was my impression that what this wg was out to make was a protocol that > played "nice" with both nonexistent, current and future intermediaries. > > Don't get me wrong, the actual data passed through the WebSocket connection > should be (possible to be?) opaque to any intermediaries, but the fact that > it is a message, or a keepalive, or a graceful close, should be information > available for intermediaries. > > Vladimir > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd2be4632ba5d048bda0da7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 19, 2010 at 7:47 AM, Vladimi= r Katardjiev <vla= dimir@d2dx.com> wrote:
On 16 apr 2010, at 22.13, Ian Hickson wrote:
> On Fri, 16 Apr 2010, Greg Wilkins wrote:
>>
>> The whole point of having a standard like websocket, is so that th= e
>> network infrastructure can implement the RFC and then we have know= n
>> semantics over that connection that intermediaries can at least ha= ndle
>> correctly, but may also do clever stuff with.
>
> That wasn't even on my list of reasons for originally coming up wi= th
> TCPConnection, let alone the main reason.

>
> The main reason for the Web Socket protocol is to have one protocol th= at
> the browsers can all implement in an interoperable fashion so that ser= vers
> can implement things once and have them work with all browsers. In the=
> ideal deployment the connection is wrapped in end-to-end TLS, so the > intermediaries can't do anything with it. There were only two reas= ons for
> even allowing unencrypted Web Socket originally: requiring amateurs to=
> figure out TLS seemed like too high a bar, and there is still some con= cern
> that when the connection is being used for entirely public information= ,
> the TLS connection overhead is too expensive to justify.

Fair enough, it wasn't originally. But wouldn't it be better if it = did? Let's take a couple of hypothetical scenarios where an amateur pro= grammer can _transparently_ gain additional, desirable functionality by an = intermediary "messing" with a well-defined protocol.

1. Compression
For all the talk about transferring 5gb using WebSockets, the FCC still mai= ntains a fairly conservative definition of "broadband" at 768kbps= . I believe the US average broadband speed was a handy contribution to the = speed savings that SPDY's compression of data made possible. In other w= ords, it's not unlikely that a future iteration of WebSockets adds comp= ression (let's say gzip) to the equation.

For the SPDY data point - for low speed li= nks, the header compression matters. =A0For high speed links, it doesn'= t. =A0SPDYs gains mostly come from other factors. =A0I wish I had the graph= s handy, but I do not.
=A0

Obviously, for this to work it needs to be optional, because otherwise we r= aise the barrier of entry. But in some deployments it is a desirable thing = for the ISP to add. An ISP might want to compress the traffic to lower the = load on their edge network (or their 768kbps broadband customers) In the ca= se of a mobile network, the shorter time the radio is kept alive, the more = battery savings, so it's highly desirable to compress WebSocket connect= ions if appropriate.

2. Optimisation
Suppose we had a way of determining that a client cannot receive messages l= arger than 1mb, due to memory restrictions. (Feel free to substitute it wit= h 5gb for the 2020 scenario). Wouldn't it be a waste of time to send al= l that data to the remote client only for it to discover that state on its = own? For a mobile client, if the behaviour on too large frames is well-defi= ned, we may even handle it without waking the client up (or close the conne= ction if that's the defined behaviour) potentially saving a lot of band= width and battery.

3. Error checking
A properly written intermediary is also expertly written. So it would be ab= le to prevent protocol exploits that may appear. In addition, these types o= f intermediaries would be maintained for the purpose of security and thus u= pdated faster than you could hypothetically update client(s) and server(s).= While it doesn't eliminate the spread of exploits and malware, it can = reduce it. If we are supposed to be as concerned as we are about security, = we should also cover the possibility that there may be a security hole in t= he future (one that we couldn't consider now) and make sure it can be p= rotected. An intermediary can be a part of such a solution, but that also i= mplies we must have intermediaries that can talk WebSockets.

Let me try to be objective about the trade= off here: =A0When everything is encrypted and authenticated at the endpoint= s, it prevents an intermediary (who's motivations may be different than= yours) from taking action. =A0When data is not encrypted & authenticat= ed, intermediaries, which have different motivations (good or bad) are poss= ible.

So the sad news is that for every good motivation, ther= e is an equal and opposite bad motivation as a counter argument...

=A0

4. Deployment
This falls into the category of "making the protocol actually work&quo= t;, but I do count it as a benefit to the amateur programmer because, yeah,= I don't quite think TLS is so trivial to implement either. I don't= remember where the original reference is, but I don't think creating a= protocol whose design goal is to be wrapped end to end in TLS to simulate = having open network access is going to work.


For one, you can't guarantee having no intermediaries with TLS (for the= amateur programmer). All you need to do to MITM a TLS connection is, well,= an intermediary box (I'd wager most ISPs can arrange one of those) and= a signed certificate (shouldn't be an issue either). Since the WebSock= et connection is user transparent they won't notice that the certificat= e no longer says Bank.com but ISP.com. Or Corporation.com for that matter. = (I won't discuss ethics/morality/legality, just technology)

Actually, if you do that, the browser thro= ws up a huge red box saying "danger". =A0The MITM will not have a= signing cert for a CA trusted by the browser. =A0So, the cert will be sign= ed by the ISP or other transparent intermediary, which won't match the = trusted CA list, and the browser will complain. =A0Corporations can get aro= und this by forcing a CA cert onto the browser; but that is no longer a tra= nsparent intermediary - it was specifically granted permission at the endpo= int. =A0Of course, the user, not knowing what the hell is going on, will cl= ick through anyway, think "that's weird", and everything else= will still work.

BTW - there is another data point here; deployment of W= ebSockets over port 80 was measured in Chrome to have ~67% success rate tod= ay. =A0Deployment over port 443 (with TLS) has a >95% success rate. =A0S= o, if you don't use TLS, then browsers and websites will need to be mad= e more complex to deal with the edge case of WebSockets failing in weird wa= ys due to existing intermediaries which fail, even after the WebSocket hand= shake.

Mike


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
(course, this won't work if the TLS box shares https and wss traffic, b= ut then we're not dealing with the amateur programmer are we?)

I don't think working on bypassing intermediaries for all traffic is a = productive avenue. Rather, I think it'd just lead to a pointless arms r= ace. It was my impression that what this wg was out to make was a protocol = that played "nice" with both nonexistent, current and future inte= rmediaries.

Don't get me wrong, the actual data passed through the WebSocket connec= tion should be (possible to be?) opaque to any intermediaries, but the fact= that it is a message, or a keepalive, or a graceful close, should be infor= mation available for intermediaries.

Vladimir

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

--000e0cd2be4632ba5d048bda0da7-- From jat@google.com Tue Jul 20 16:39:20 2010 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 DA5A93A68E7 for ; Tue, 20 Jul 2010 16:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1+HOrtGginti for ; Tue, 20 Jul 2010 16:39:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 846E73A6840 for ; Tue, 20 Jul 2010 16:39:19 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o6KNdYka019999 for ; Tue, 20 Jul 2010 16:39:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279669175; bh=9nihyvujpHqKv5LgVDduk2wAjoM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cxQzZL75xKo49jSutsuTYlgWMA+kN5O+LIkxoResDzmUp6qEphXQxJEZkhJIW6jwf l30tAsMlYTpi7nr4yloPw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=bXsry0yG7CtEtcu1DXZNbt1bo/bmj8rgLZcuzWnEdUD+ty+k/cTLawpY9WpngGoUD xyJLyhbCaRQG1yWIk/4LA== Received: from qyk12 (qyk12.prod.google.com [10.241.83.140]) by hpaq1.eem.corp.google.com with ESMTP id o6KNdXEj017779 for ; Tue, 20 Jul 2010 16:39:33 -0700 Received: by qyk12 with SMTP id 12so3190255qyk.0 for ; Tue, 20 Jul 2010 16:39:32 -0700 (PDT) Received: by 10.224.49.66 with SMTP id u2mr6213316qaf.250.1279669172217; Tue, 20 Jul 2010 16:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.193 with HTTP; Tue, 20 Jul 2010 16:39:12 -0700 (PDT) In-Reply-To: References: <4BCF4932.8040303@gmail.com> <4BD09A2C.6060506@gmail.com> <8B0A9FCBB9832F43971E38010638454F03E7D06DF7@SISPE7MB1.commscope.com> <20100422225448.GG13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E00@SISPE7MB1.commscope.com> <20100422230957.GI13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E06@SISPE7MB1.commscope.com> <20100423001858.GA22326@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E28@SISPE7MB1.commscope.com> <20100423103715.GB32366@shareable.org> From: John Tamplin Date: Tue, 20 Jul 2010 19:39:12 -0400 Message-ID: To: Ian Hickson Content-Type: multipart/alternative; boundary=001485e98b3670a717048bda324e X-System-Of-Record: true Cc: "hybi@ietf.org" , "Thomson, Martin" Subject: Re: [hybi] Multiple connections serialization and proxies 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, 20 Jul 2010 23:39:21 -0000 --001485e98b3670a717048bda324e Content-Type: text/plain; charset=UTF-8 On Tue, Jul 20, 2010 at 7:14 PM, Ian Hickson wrote: > > I favour the server being able to send back a number saying how many > > more connections are permitted now. Negotiated flow control, rather > > than spec'd fixed values (except the first). There could still be a > > default, for simple implementations. > > That seems like something we should add in a future version, if it really > is needed. Baby steps, keep things simple, etc. Given the lack of extensibility and negotiation, how would it be added in the future without breaking backwards compatibility? -- John A. Tamplin Software Engineer (GWT), Google --001485e98b3670a717048bda324e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 20, 2010 at 7:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> I favour the server being able to send back a number= saying how many
> more connections are permitted now. =C2=A0Negotiated flow control, rat= her
> than spec'd fixed values (except the first). =C2=A0There could sti= ll be a
> default, for simple implementations.

That seems like something we should add in a future version, if it re= ally
is needed. Baby steps, keep things simple, etc.

=
Given the lack of extensibility and negotiation, how would it be added= in the future without breaking backwards compatibility?=C2=A0
<= br> --
John A. Tamplin
Software Engineer (GWT), Google
--001485e98b3670a717048bda324e-- From mjs@apple.com Tue Jul 20 17:00:49 2010 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 9D19D3A67FA for ; Tue, 20 Jul 2010 17:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8erfBNC1BtTv for ; Tue, 20 Jul 2010 17:00:48 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 7F5583A65A5 for ; Tue, 20 Jul 2010 17:00:48 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 78B189EA877B for ; Tue, 20 Jul 2010 17:01:04 -0700 (PDT) X-AuditID: 11807134-b7b53ae000005755-a5-4c4638bea128 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id B6.8E.22357.EB8364C4; Tue, 20 Jul 2010 17:01:02 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gl2HeSIjJYnWzCELGXHPVQ)" Received: from [17.151.78.226] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5V00JCSS1QYA20@et.apple.com> for hybi@ietf.org; Tue, 20 Jul 2010 17:01:02 -0700 (PDT) From: Maciej Stachowiak In-reply-to: Date: Tue, 20 Jul 2010 17:01:02 -0700 Message-id: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> To: Mike Belshe X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 00:00:49 -0000 --Boundary_(ID_gl2HeSIjJYnWzCELGXHPVQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jul 20, 2010, at 4:29 PM, Mike Belshe wrote: > > 3. Error checking > A properly written intermediary is also expertly written. So it would be able to prevent protocol exploits that may appear. In addition, these types of intermediaries would be maintained for the purpose of security and thus updated faster than you could hypothetically update client(s) and server(s). While it doesn't eliminate the spread of exploits and malware, it can reduce it. If we are supposed to be as concerned as we are about security, we should also cover the possibility that there may be a security hole in the future (one that we couldn't consider now) and make sure it can be protected. An intermediary can be a part of such a solution, but that also implies we must have intermediaries that can talk WebSockets. > > Let me try to be objective about the tradeoff here: When everything is encrypted and authenticated at the endpoints, it prevents an intermediary (who's motivations may be different than yours) from taking action. When data is not encrypted & authenticated, intermediaries, which have different motivations (good or bad) are possible. > > So the sad news is that for every good motivation, there is an equal and opposite bad motivation as a counter argument... Also, in practice it does not seem to be the case that intermediaries are updated faster than clients or servers. One of the challenges to deploying new protocols or protocol features is old intermediaries that are not updated. > > Actually, if you do that, the browser throws up a huge red box saying "danger". The MITM will not have a signing cert for a CA trusted by the browser. So, the cert will be signed by the ISP or other transparent intermediary, which won't match the trusted CA list, and the browser will complain. Corporations can get around this by forcing a CA cert onto the browser; but that is no longer a transparent intermediary - it was specifically granted permission at the endpoint. Of course, the user, not knowing what the hell is going on, will click through anyway, think "that's weird", and everything else will still work. Browsers don't have to accept broken certs for WebSocket with a clickthrough the way many still do for Web sites. I would argue that they should not, because the security consequences of the decision cannot possibly be understood by the typical user. > > BTW - there is another data point here; deployment of WebSockets over port 80 was measured in Chrome to have ~67% success rate today. Deployment over port 443 (with TLS) has a >95% success rate. So, if you don't use TLS, then browsers and websites will need to be made more complex to deal with the edge case of WebSockets failing in weird ways due to existing intermediaries which fail, even after the WebSocket handshake. This point is very important. Building on top of TLS has huge practical benefits. I think this outweighs the desire to more easily build transparent intermediaries. Any mechanism that allows intermediaries without being authorized by either endpoint is by definition a security vulnerability in the protocol. I think the benefits of TLS also outweigh the "amateur server implementor" argument. I don't think we want to make it easy to implement a security hole. Regards, Maciej --Boundary_(ID_gl2HeSIjJYnWzCELGXHPVQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

3. Error checking
A properly written intermediary is also expertly written. So it would be = able to prevent protocol exploits that may appear. In addition, these = types of intermediaries would be maintained for the purpose of security = and thus updated faster than you could hypothetically update client(s) = and server(s). While it doesn't eliminate the spread of exploits and = malware, it can reduce it. If we are supposed to be as concerned as we = are about security, we should also cover the possibility that there may = be a security hole in the future (one that we couldn't consider now) and = make sure it can be protected. An intermediary can be a part of such a = solution, but that also implies we must have intermediaries that can = talk WebSockets.

Let me try to be objective about the = tradeoff here:  When everything is encrypted and authenticated at = the endpoints, it prevents an intermediary (who's motivations may be = different than yours) from taking action.  When data is not = encrypted & authenticated, intermediaries, which have different = motivations (good or bad) are possible.

So the sad news is that for every good motivation, = there is an equal and opposite bad motivation as a counter = argument...

Also, in = practice it does not seem to be the case that intermediaries are updated = faster than clients or servers. One of the challenges to deploying new = protocols or protocol features is old intermediaries that are not = updated.


Actually, if you do that, the = browser throws up a huge red box saying "danger".  The MITM will = not have a signing cert for a CA trusted by the browser.  So, the = cert will be signed by the ISP or other transparent intermediary, which = won't match the trusted CA list, and the browser will complain. =  Corporations can get around this by forcing a CA cert onto the = browser; but that is no longer a transparent intermediary - it was = specifically granted permission at the endpoint.  Of course, the = user, not knowing what the hell is going on, will click through anyway, = think "that's weird", and everything else will still = work.

Browsers don't have to = accept broken certs for WebSocket with a clickthrough the way many still = do for Web sites. I would argue that they should not, because the = security consequences of the decision cannot possibly be understood by = the typical user.


BTW - there is another data point here; deployment = of WebSockets over port 80 was measured in Chrome to have ~67% success = rate today.  Deployment over port 443 (with TLS) has a >95% = success rate.  So, if you don't use TLS, then browsers and websites = will need to be made more complex to deal with the edge case of = WebSockets failing in weird ways due to existing intermediaries which = fail, even after the WebSocket handshake.

This point is very important. Building = on top of TLS has huge practical benefits. I think this outweighs the = desire to more easily build transparent intermediaries. Any mechanism = that allows intermediaries without being authorized by either endpoint = is by definition a security vulnerability in the = protocol.

I think the benefits of TLS also = outweigh the "amateur server implementor" argument. I don't think we = want to make it easy to implement a security = hole.

Regards,
Maciej

= --Boundary_(ID_gl2HeSIjJYnWzCELGXHPVQ)-- From jat@google.com Tue Jul 20 17:04:54 2010 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 915CC3A65A5 for ; Tue, 20 Jul 2010 17:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ZeJrksufEsaH for ; Tue, 20 Jul 2010 17:04:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7CB973A6970 for ; Tue, 20 Jul 2010 17:04:53 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o6L058G1023720 for ; Tue, 20 Jul 2010 17:05:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279670708; bh=QzNCF9/wFFXwi6JEWqgG2SsLdEM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aUe5Z05X0j2v7qvCeGzeVCPTdvHRObYpAdwUUnls/dPq/RrrXqmeIzGBPrKSCqbEm HjoZgq4mHbbEvS1KQ23Nw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=vcWJ7rALqhQ+lj/YXl4rHA9Wu4FInUBI/sz9iS1Arn2VMgZr5MnRhC7ZgutjcP4Qh 0fmWN24DEaKn/+JKFc7Vg== Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by hpaq3.eem.corp.google.com with ESMTP id o6L052rK010285 for ; Tue, 20 Jul 2010 17:05:07 -0700 Received: by qyk7 with SMTP id 7so2456559qyk.4 for ; Tue, 20 Jul 2010 17:05:07 -0700 (PDT) Received: by 10.224.113.85 with SMTP id z21mr6031468qap.214.1279670707196; Tue, 20 Jul 2010 17:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.193 with HTTP; Tue, 20 Jul 2010 17:04:46 -0700 (PDT) In-Reply-To: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> From: John Tamplin Date: Tue, 20 Jul 2010 20:04:46 -0400 Message-ID: To: Maciej Stachowiak Content-Type: multipart/alternative; boundary=000feaead823ee9961048bda8d50 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 00:04:54 -0000 --000feaead823ee9961048bda8d50 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 20, 2010 at 8:01 PM, Maciej Stachowiak wrote: > This point is very important. Building on top of TLS has huge practical > benefits. I think this outweighs the desire to more easily build transparent > intermediaries. Any mechanism that allows intermediaries without being > authorized by either endpoint is by definition a security vulnerability in > the protocol. > > I think the benefits of TLS also outweigh the "amateur server implementor" > argument. I don't think we want to make it easy to implement a security > hole. > How would requiring TLS impact games over WebSocket, such as GWT Quake? Maybe one day we will have a connection-oriented datagram protocol for WS, but until then we have to make do with running over TCP. Adding encryption overhead might render WS unusable for this purpose. -- John A. Tamplin Software Engineer (GWT), Google --000feaead823ee9961048bda8d50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 20, 2010 at 8:01 PM, Maciej Stachowi= ak <mjs@apple.com= > wrote:
This point is very important.= Building on top of TLS has huge practical benefits. I think this outweighs= the desire to more easily build transparent intermediaries. Any mechanism = that allows intermediaries without being authorized by either endpoint is b= y definition a security vulnerability in the protocol.

I think the benefits of TLS also outweigh the &qu= ot;amateur server implementor" argument. I don't think we want to = make it easy to implement a security hole.

How would requiring TLS impact games over WebSocket, such as= GWT Quake? =C2=A0Maybe one day we will have a connection-oriented datagram= protocol for WS, but until then we have to make do with running over TCP. = =C2=A0Adding encryption overhead might render WS unusable for this purpose.= =C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000feaead823ee9961048bda8d50-- From gregw@webtide.com Tue Jul 20 17:10:35 2010 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 0F7EA3A6961 for ; Tue, 20 Jul 2010 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 eDbJVp-3VLVo for ; Tue, 20 Jul 2010 17:10:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 54A073A696D for ; Tue, 20 Jul 2010 17:10:33 -0700 (PDT) Received: by fxm1 with SMTP id 1so3545040fxm.31 for ; Tue, 20 Jul 2010 17:10:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.115.200 with SMTP id j8mr2009167faq.107.1279671048464; Tue, 20 Jul 2010 17:10:48 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Tue, 20 Jul 2010 17:10:48 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> Date: Wed, 21 Jul 2010 10:10:48 +1000 Message-ID: From: Greg Wilkins To: Roberto Peon Content-Type: multipart/alternative; boundary=00504502e44d45e990048bdaa265 Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 00:10:35 -0000 --00504502e44d45e990048bdaa265 Content-Type: text/plain; charset=UTF-8 On 21 July 2010 08:33, Roberto Peon wrote: > On Tue, Jul 20, 2010 at 3:14 PM, Ian Hickson wrote: > >> >> I agree that we shouldn't make the protocol impossible to scale. If there >> are specific features in the protocol that make it impossible to scale, >> please do raise these as issues. However, one doesn't have to make a >> protocol complex to make it scale. >> > > We need browser-owned connections with a security model that allows > multiple tabs to share the connection safely. > This is probably the most important requirement for scalability as far as > I'm concerned. This requires fewer keep-alives (both because of fewer TCP > connections and because the TCP connection is more likely to have real > content sent on it instead of near-zero value'd keep-alives), it requires > fewer file descriptors, it requires fewer handshakes. > +1 Currently websocket solves none of my pain points implementing large scale cometd solutions, namely the issues associated with the number of connections, keeping them alive and detecting when they fail. The only advantage websockets currently have over long polling is that they have marginally better latency and better data density, but neither of these are killer issues for a large class of application. Surely we can come up with a solution that has good latency, good data density and address some if not all of the issues associated with connection management. Delegating the connection management to the application developer does not make that problem any simpler, it just means that it will be done badly more often than not. cheers --00504502e44d45e990048bdaa265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 21 July 2010 08:33, Roberto Peon <fenix@google.com&= gt; wrote:
On Tue, Jul 20, 2010 at 3:14 P= M, Ian Hickson <ian@hixie.ch> wrote:

I agree that we shouldn't make the protocol impossible to scale. If the= re
are specific features in the protocol that make it impossible to scale,
please do raise these as issues. However, one doesn't have to make a protocol complex to make it scale.

We need browser-owned connections with a security model that allows= multiple tabs to share the connection safely.
This is probably t= he most important requirement for scalability as far as I'm concerned. = This requires fewer keep-alives (both because of fewer TCP connections and = because the TCP connection is more likely to have real content sent on it i= nstead of near-zero value'd keep-alives), it requires fewer file descri= ptors, it requires fewer handshakes.

+1

Currently websocket solves none of my= pain points implementing large scale cometd solutions, namely the issues a= ssociated with the number of connections, keeping them alive and detecting = when they fail.

The only advantage websockets currently have over long polling is that = they have marginally better latency and better data density, but neither of= these are killer issues for a large class of application.

Surely we= can come up with a solution that has good latency, good data density and a= ddress some if not all of the issues associated with connection management.= =C2=A0 Delegating the connection management to the application developer do= es not make that problem any simpler, it just means that it will be done ba= dly more often than not.

cheers

=C2=A0

--00504502e44d45e990048bdaa265-- From fenix@google.com Tue Jul 20 17:11:05 2010 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 422FA3A65A5 for ; Tue, 20 Jul 2010 17:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 uc0hJeW6jtpc for ; Tue, 20 Jul 2010 17:11:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DB63F3A6985 for ; Tue, 20 Jul 2010 17:11:03 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o6L0BJVe026391 for ; Tue, 20 Jul 2010 17:11:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279671079; bh=83k6kfj0zD7jGK2g24AgGDqc8kk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BsoPsGGYrm/65m6dsKANfkfaooQF69D+DQ2aOPg2ElFB60+M92Iy9co3n64tvO5QO UvcrJopjjZGaF3r2iucqw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=I5C1Qn6dl6zPnvDyXkUadt3PGprzTLoHDEq62tafhSGKw5po0Xxfh9SMQswKBYHX8 6Qgjs6qxxbmZ+kVhrGLvA== Received: from vws9 (vws9.prod.google.com [10.241.21.137]) by hpaq13.eem.corp.google.com with ESMTP id o6L0BHnk032369 for ; Tue, 20 Jul 2010 17:11:17 -0700 Received: by vws9 with SMTP id 9so6693409vws.38 for ; Tue, 20 Jul 2010 17:11:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.115.157 with SMTP id i29mr6019165qaq.262.1279671076399; Tue, 20 Jul 2010 17:11:16 -0700 (PDT) Received: by 10.229.106.214 with HTTP; Tue, 20 Jul 2010 17:11:16 -0700 (PDT) In-Reply-To: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> Date: Tue, 20 Jul 2010 17:11:16 -0700 Message-ID: From: Roberto Peon To: John Tamplin Content-Type: multipart/alternative; boundary=00c09f9b0bbaf02cf7048bdaa37c X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 00:11:05 -0000 --00c09f9b0bbaf02cf7048bdaa37c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 5:04 PM, John Tamplin wrote: > On Tue, Jul 20, 2010 at 8:01 PM, Maciej Stachowiak wrote: > >> This point is very important. Building on top of TLS has huge practical >> benefits. I think this outweighs the desire to more easily build transparent >> intermediaries. Any mechanism that allows intermediaries without being >> authorized by either endpoint is by definition a security vulnerability in >> the protocol. >> >> I think the benefits of TLS also outweigh the "amateur server implementor" >> argument. I don't think we want to make it easy to implement a security >> hole. >> > > How would requiring TLS impact games over WebSocket, such as GWT Quake? > Maybe one day we will have a connection-oriented datagram protocol for WS, > but until then we have to make do with running over TCP. Adding encryption > overhead might render WS unusable for this purpose. > I'd be pretty surprised if SSL added enough overhead that it made WS unsuitable for games. It is far, far, far, more likely that the fact that we're using TCP renders it useless for certain classes of games. Also, while perhaps I don't count as an 'amateur' programmer, I did add SSL/TLS support to a server recently. It tool no more than a day to do! t was surprisingly easy! -=R > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --00c09f9b0bbaf02cf7048bdaa37c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 5:04 PM, John Ta= mplin <jat@google.co= m> wrote:
On Tue, Jul 20, 2010 at 8:01 P= M, Maciej Stachowiak <mjs@apple.com> wrote:
This point is very important.= Building on top of TLS has huge practical benefits. I think this outweighs= the desire to more easily build transparent intermediaries. Any mechanism = that allows intermediaries without being authorized by either endpoint is b= y definition a security vulnerability in the protocol.

I think the benefits of TLS also outweigh the &qu= ot;amateur server implementor" argument. I don't think we want to = make it easy to implement a security hole.

How would requiring TLS impact games over WebSocket, s= uch as GWT Quake? =A0Maybe one day we will have a connection-oriented datag= ram protocol for WS, but until then we have to make do with running over TC= P. =A0Adding encryption overhead might render WS unusable for this purpose.= =A0

I'd be pretty surprised if SSL a= dded enough overhead that it made WS unsuitable for games. It is far, far, = far, more likely that the fact that we're using TCP renders it useless = for certain classes of games.
=A0
Also, while perhaps I don't count as an 'amateur= ' programmer, I did add SSL/TLS support to a server recently. It tool n= o more than a day to do! t was surprisingly easy!

-=3DR


--
John A. Tamplin
Software Engine= er (GWT), Google

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


--00c09f9b0bbaf02cf7048bdaa37c-- From gregw@webtide.com Tue Jul 20 17:11:09 2010 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 6A4D53A6991 for ; Tue, 20 Jul 2010 17:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 3-zozyWxtccI for ; Tue, 20 Jul 2010 17:11:08 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6751B3A696D for ; Tue, 20 Jul 2010 17:11:08 -0700 (PDT) Received: by fxm1 with SMTP id 1so3545181fxm.31 for ; Tue, 20 Jul 2010 17:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.122.195 with SMTP id m3mr6059095far.86.1279671083586; Tue, 20 Jul 2010 17:11:23 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Tue, 20 Jul 2010 17:11:23 -0700 (PDT) In-Reply-To: <4C462F9E.9030207@caucho.com> References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> Date: Wed, 21 Jul 2010 10:11:23 +1000 Message-ID: From: Greg Wilkins To: Scott Ferguson Content-Type: multipart/alternative; boundary=001636c5b1425dd69a048bdaa4ac Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 00:11:09 -0000 --001636c5b1425dd69a048bdaa4ac Content-Type: text/plain; charset=UTF-8 On 21 July 2010 09:22, Scott Ferguson wrote: > Mike Belshe wrote: > >> >> For as adamantly as Ian states that it should be a requirement, I am just >> as adamant that it should not. >> >> Every protocol expert I've spoken with agrees that amateur protocol >> implementors should not be a requirement. >> >> Is there some way we can vote to either keep or nullify this requirement >> now and never come back to it again? I'm tired of this obstacle holding >> everything up. >> > +1 +1 --001636c5b1425dd69a048bdaa4ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 21 July 2010 09:22, Scott Ferguson <ferg@caucho.com&= gt; wrote:
Mike Belshe wrote:

For as adamantly as Ian states that it should be a requirement, I am just a= s adamant that it should not.

Every protocol expert I've spoken with agrees that amateur protocol imp= lementors should not be a requirement.

Is there some way we can vote to either keep or nullify this requirement no= w and never come back to it again? =C2=A0I'm tired of this obstacle hol= ding everything up.
+1
+1
--001636c5b1425dd69a048bdaa4ac-- From fenix@google.com Tue Jul 20 17:14:52 2010 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 9C2663A65A5 for ; Tue, 20 Jul 2010 17:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 J2i570LytoKj for ; Tue, 20 Jul 2010 17:14:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 00EEC3A67FA for ; Tue, 20 Jul 2010 17:14:50 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6L0F4Z3003204 for ; Tue, 20 Jul 2010 17:15:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279671304; bh=pmf/hvcXOA2eKAZBpH8iQyhLOSg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TSEf3UX61PXjCjx8iLdXRU1bIISSMp/4FKiK2C3tGgJKTtijQKvXUG3f6kpVja+wr lLqpuOsek/LYZ6v5jWTqg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=jf6Czjv+wX5bPQCSFrbu8+eIHfo54D9SA0YNyClo6I538pfXvVApd7cYii49oad9Q ma17PQckeE/Fw3okpZvNA== Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by wpaz17.hot.corp.google.com with ESMTP id o6L0F3mJ017321 for ; Tue, 20 Jul 2010 17:15:03 -0700 Received: by qyk27 with SMTP id 27so2425022qyk.3 for ; Tue, 20 Jul 2010 17:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.60.205 with SMTP id q13mr6431441qah.335.1279671302790; Tue, 20 Jul 2010 17:15:02 -0700 (PDT) Received: by 10.229.106.214 with HTTP; Tue, 20 Jul 2010 17:15:02 -0700 (PDT) In-Reply-To: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> Date: Tue, 20 Jul 2010 17:15:02 -0700 Message-ID: From: Roberto Peon To: Maciej Stachowiak Content-Type: multipart/alternative; boundary=0015175caae46e9e90048bdab1ad X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 00:14:52 -0000 --0015175caae46e9e90048bdab1ad Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 5:01 PM, Maciej Stachowiak wrote: > > On Jul 20, 2010, at 4:29 PM, Mike Belshe wrote: > > >> 3. Error checking >> A properly written intermediary is also expertly written. So it would be >> able to prevent protocol exploits that may appear. In addition, these types >> of intermediaries would be maintained for the purpose of security and thus >> updated faster than you could hypothetically update client(s) and server(s). >> While it doesn't eliminate the spread of exploits and malware, it can reduce >> it. If we are supposed to be as concerned as we are about security, we >> should also cover the possibility that there may be a security hole in the >> future (one that we couldn't consider now) and make sure it can be >> protected. An intermediary can be a part of such a solution, but that also >> implies we must have intermediaries that can talk WebSockets. >> > > Let me try to be objective about the tradeoff here: When everything is > encrypted and authenticated at the endpoints, it prevents an intermediary > (who's motivations may be different than yours) from taking action. When > data is not encrypted & authenticated, intermediaries, which have different > motivations (good or bad) are possible. > > So the sad news is that for every good motivation, there is an equal and > opposite bad motivation as a counter argument... > > > Also, in practice it does not seem to be the case that intermediaries are > updated faster than clients or servers. One of the challenges to deploying > new protocols or protocol features is old intermediaries that are not > updated. > Hear, hear. This is the part about intermediaries that is really terrible. They ossify the net. There is another concern w.r.t. intermediaries. Schools and other institutions will block port 443 if they feel unacceptable content is flowing over it and they have other means of dealing with it. I believe that this means that we need an 'authorized proxy' model. No proxy would be fully transparent (unless it was a reverse proxy representing the real endpoint), however it should be exceptionally easy to install a policy allowing the proxy explicitly. It is a hair more annoying for the user than no proxy, but it gives schools, etc. a way to control the computers that they own without blocking port 443 for everyone and everything. > > Actually, if you do that, the browser throws up a huge red box saying > "danger". The MITM will not have a signing cert for a CA trusted by the > browser. So, the cert will be signed by the ISP or other transparent > intermediary, which won't match the trusted CA list, and the browser will > complain. Corporations can get around this by forcing a CA cert onto the > browser; but that is no longer a transparent intermediary - it was > specifically granted permission at the endpoint. Of course, the user, not > knowing what the hell is going on, will click through anyway, think "that's > weird", and everything else will still work. > > > Browsers don't have to accept broken certs for WebSocket with a > clickthrough the way many still do for Web sites. I would argue that they > should not, because the security consequences of the decision cannot > possibly be understood by the typical user. > > > BTW - there is another data point here; deployment of WebSockets over port > 80 was measured in Chrome to have ~67% success rate today. Deployment over > port 443 (with TLS) has a >95% success rate. So, if you don't use TLS, then > browsers and websites will need to be made more complex to deal with the > edge case of WebSockets failing in weird ways due to existing intermediaries > which fail, even after the WebSocket handshake. > > > This point is very important. Building on top of TLS has huge practical > benefits. I think this outweighs the desire to more easily build transparent > intermediaries. Any mechanism that allows intermediaries without being > authorized by either endpoint is by definition a security vulnerability in > the protocol. > > I think the benefits of TLS also outweigh the "amateur server implementor" > argument. I don't think we want to make it easy to implement a security > hole. > > Regards, > Maciej > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --0015175caae46e9e90048bdab1ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 5:01 PM, Maciej = Stachowiak <mjs@apple= .com> wrote:

On Jul = 20, 2010, at 4:29 PM, Mike Belshe wrote:


3. Error checking
A properly written intermediary is also expertly written. So it would be ab= le to prevent protocol exploits that may appear. In addition, these types o= f intermediaries would be maintained for the purpose of security and thus u= pdated faster than you could hypothetically update client(s) and server(s).= While it doesn't eliminate the spread of exploits and malware, it can = reduce it. If we are supposed to be as concerned as we are about security, = we should also cover the possibility that there may be a security hole in t= he future (one that we couldn't consider now) and make sure it can be p= rotected. An intermediary can be a part of such a solution, but that also i= mplies we must have intermediaries that can talk WebSockets.

Let me try to be objective about the trade= off here: =A0When everything is encrypted and authenticated at the endpoint= s, it prevents an intermediary (who's motivations may be different than= yours) from taking action. =A0When data is not encrypted & authenticat= ed, intermediaries, which have different motivations (good or bad) are poss= ible.

So the sad news is that for every good motivation, ther= e is an equal and opposite bad motivation as a counter argument...

Also, in practice it does not see= m to be the case that intermediaries are updated faster than clients or ser= vers. One of the challenges to deploying new protocols or protocol features= is old intermediaries that are not updated.


Hear, hear. Thi= s is the part about intermediaries that is really terrible. They ossify the= net.
There is another concern w.r.t. intermediaries.
Schools and other institutions will block port 443 if they feel unacceptabl= e content is flowing over it and they have other means of dealing with it.<= /div>
I believe that this means that we need an 'authorized proxy&#= 39; model. No proxy would be fully transparent (unless it was a reverse pro= xy representing the real endpoint), however it should be exceptionally easy= to install a policy allowing the proxy explicitly. It is a hair more annoy= ing for the user than no proxy, but it gives schools, etc. a way to control= the computers that they own without blocking port 443 for everyone and eve= rything.
=A0


=

Actually, if you do that, the browser throws up a huge = red box saying "danger". =A0The MITM will not have a signing cert= for a CA trusted by the browser. =A0So, the cert will be signed by the ISP= or other transparent intermediary, which won't match the trusted CA li= st, and the browser will complain. =A0Corporations can get around this by f= orcing a CA cert onto the browser; but that is no longer a transparent inte= rmediary - it was specifically granted permission at the endpoint. =A0Of co= urse, the user, not knowing what the hell is going on, will click through a= nyway, think "that's weird", and everything else will still w= ork.

Browsers don't have to acc= ept broken certs for WebSocket with a clickthrough the way many still do fo= r Web sites. I would argue that they should not, because the security conse= quences of the decision cannot possibly be understood by the typical user.<= /div>


BTW - there is another data point here; deployment of W= ebSockets over port 80 was measured in Chrome to have ~67% success rate tod= ay. =A0Deployment over port 443 (with TLS) has a >95% success rate. =A0S= o, if you don't use TLS, then browsers and websites will need to be mad= e more complex to deal with the edge case of WebSockets failing in weird wa= ys due to existing intermediaries which fail, even after the WebSocket hand= shake.

This point is very important. Build= ing on top of TLS has huge practical benefits. I think this outweighs the d= esire to more easily build transparent intermediaries. Any mechanism that a= llows intermediaries without being authorized by either endpoint is by defi= nition a security vulnerability in the protocol.

I think the benefits of TLS also outweigh the "ama= teur server implementor" argument. I don't think we want to make i= t easy to implement a security hole.

Regards,
Maciej


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


--0015175caae46e9e90048bdab1ad-- From fenix@google.com Tue Jul 20 17:16:07 2010 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 163B83A67FA for ; Tue, 20 Jul 2010 17:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 CpR+-uis3yL7 for ; Tue, 20 Jul 2010 17:16:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A6BFA3A65A5 for ; Tue, 20 Jul 2010 17:16:05 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6L0GKNv004941 for ; Tue, 20 Jul 2010 17:16:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279671381; bh=301u8gQZ/yPNKbzG9vowrtGLwGk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qSgs8C1dRIH/404cYXJiwAC1hFWuCgRa13VFoKSma4ljH5RDj9PU6Y9fDm3xI8XvI IGFNq+QTY8uFxzW6wKS7g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=RWbgfSP/W4GTNoijSfh3378dRIcRc9E0+VCBBzE3NWERQOgnfh7UTu2XuSFV0U1qW SQfQAhCp+lHbv+wyXU0nQ== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by kpbe17.cbf.corp.google.com with ESMTP id o6L0GCeS025744 for ; Tue, 20 Jul 2010 17:16:19 -0700 Received: by qwe5 with SMTP id 5so2566178qwe.31 for ; Tue, 20 Jul 2010 17:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.44.203 with SMTP id b11mr6238773qaf.184.1279671378879; Tue, 20 Jul 2010 17:16:18 -0700 (PDT) Received: by 10.229.106.214 with HTTP; Tue, 20 Jul 2010 17:16:18 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> Date: Tue, 20 Jul 2010 17:16:18 -0700 Message-ID: From: Roberto Peon To: Greg Wilkins Content-Type: multipart/alternative; boundary=00c09f88d1cef7a58b048bdab515 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 00:16:07 -0000 --00c09f88d1cef7a58b048bdab515 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 5:11 PM, Greg Wilkins wrote: > > > On 21 July 2010 09:22, Scott Ferguson wrote: > >> Mike Belshe wrote: >> >>> >>> For as adamantly as Ian states that it should be a requirement, I am just >>> as adamant that it should not. >>> >>> Every protocol expert I've spoken with agrees that amateur protocol >>> implementors should not be a requirement. >>> >>> Is there some way we can vote to either keep or nullify this requirement >>> now and never come back to it again? I'm tired of this obstacle holding >>> everything up. >>> >> +1 > > +1 > yes, please. +1. -=R > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --00c09f88d1cef7a58b048bdab515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 5:11 PM, Greg Wi= lkins <gregw@webt= ide.com> wrote:


On 21 July 2010 09:22,= Scott Ferguson <ferg@caucho.com> wrote:
Mike Belshe wrote:

For as adamantly as Ian states that it should be a requirement, I am just a= s adamant that it should not.

Every protocol expert I've spoken with agrees that amateur protocol imp= lementors should not be a requirement.

Is there some way we can vote to either keep or nullify this requirement no= w and never come back to it again? =A0I'm tired of this obstacle holdin= g everything up.
+1
+1

yes, please. +1.
-=3DR=A0
=

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


--00c09f88d1cef7a58b048bdab515-- From ian@hixie.ch Tue Jul 20 17:36:13 2010 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 6C84E3A69E6 for ; Tue, 20 Jul 2010 17:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, 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 jQRVGWgX0zSs for ; Tue, 20 Jul 2010 17:36:11 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 20A593A6976 for ; Tue, 20 Jul 2010 17:35:24 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id C23A315D565; Tue, 20 Jul 2010 17:35:20 -0700 (PDT) Date: Wed, 21 Jul 2010 00:35:19 +0000 (UTC) From: Ian Hickson To: Brad Spencer , Simon Pieters , Jamie Lokier , Scott Ferguson In-Reply-To: <4BE3BAEA.5010607@webtide.com> Message-ID: References: <20100505002429.GA31157@starscale.com> <20100506092944.GA24071@shareable.org> <20100506232709.GA4517@starscale.com> <4BE3BAEA.5010607@webtide.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hybi@ietf.org Subject: Re: [hybi] Questions on WebSocket RFC draft 76: "Early" data, whitespace, and integer sizes 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, 21 Jul 2010 00:36:13 -0000 On Tue, 4 May 2010, Brad Spencer wrote: > > Hi. I've been implementing the server side of the WebSocket RFC draft, > and I'm happy to report that not only is the specification very easy to > read and understand, but I also haven't really come across any obvious > errors or inconsistencies. The protocol seems very logical, easy to > deal with, and sensible. So, nice work :) Thanks! :-) > [Oh, and BTW, being very strict about exactly what the handshake may and > may not contain has made this much easier to implement than HTTP. I > can't say how happy I was to see rules like "there must be exactly one > space here", and so on ;)] I'm glad to see at least one person appreciates it. :-) > However, I do have some questions. (My apologies if they have been > answered already. I read some of the recent postings to this list, but > didn't find an easy way to search it.) > > 1. Can a client send any data to the server after the eight byte > "key3" data, but before the server has responded to the client's > initial handshake request? In other words, is the client allowed > to "pipeline" the first message? > > I am hoping the answer is "no" because: > > a) I don't think it makes sense to send messages before the > handshake is complete. This is probably especially true when > the subprotocol needs to be confirmed, etc. > > b) I am using at is part of the validation of the handshake, > sort of. If I have _more_ than what should be in a valid > handshake, I'd prefer to reject the connection out of hand. > > c) Preventing such data might make things simpler, although it > doesn't appear to be a practical problem for me to actually > interpret the any such "early" data as a frame data. The answer is indeed "no": the first thing the client is required to do after sending "key3" is wait for the response from the server. > 2. In HTTP, IIRC, header values can have arbitrary amounts of > whitespace between the "field-value" productions (i.e. leading > and trailing whitespace in the header value itself ends up > getting ignored). In WebSocket, this doesn't appear to be the > case (good), but it does mean that if a client sends, say, > > Connection:_Upgrade__ > > or > > Host:__www.example.com___ > > where _ represents a space, then the server is going to end up > failing the handshake, as I understand it. Is this intended? > > (To be clear, I am quite happy to have the server fail such > handshakes, as long as they are truly invalid. :) Yes, it is intended (and required as written). It is intended to reduce the number of "synonyms" for a particular semantic, thus helping increase the likelihood that UAs and servers will all act identically, reducing the chance of a security bug. > 3. When computing the server's /response/ to the /challenge/ in > Section 5.2, the RFC draft is explicit about the fact that /part1/ > and /part2/ are 32-bit numbers, but it isn't clear how large > /key-number_1/ and /key-number_2/ are allowed to be. I've presumed > they are also 32-bit numbers based on what's going on with regards > to the multiplication specified in Section 4.2 Item 19. > > Is it worth saying so explicitly in Section 5.2 Item 5 that the > /key-number_*/ numbers are also 32-bit? > > Also, I presume that all of these numbers are 32-bit _unsigned_ > numbers, but perhaps that goes without saying. I've tried to clarify this, thanks. On Thu, 6 May 2010, Jamie Lokier wrote: > > On Wed, 05 May 2010 02:24:29 +0200, Brad Spencer > > wrote: > > > I am hoping the answer is "no" because: > > > > > > a) I don't think it makes sense to send messages before the > > > handshake is complete. This is probably especially true when > > > the subprotocol needs to be confirmed, etc. > > If you don't care about extra time delays, it's easier with "no". > > With high latency links, such as mobile data, unnecessary extra round > trip times add up quickly to be annoying - hence the SPDY folks > interested in minimising connection setup latency in every way possible. > > Comet-style messaging over HTTP may be faster to start up than WebSocket > in those scenarios. It would be perverse if good WebSocket JavaScript > frameworks had to open a comet-style connection _and_ a WebSocket > connection to get good all round performance :-/ We don't really have a choice; we'd have to encrypt everything (to make it appear like random noise) to be safe from cross-protocol attacks if we didn't wait for the handshake. (If the content is random noise, we have plausible deniability -- it's a pretty poor protocol indeed that is vulnerable to attack from just random noise.) > > [[ > > Servers may close the WebSocket connection whenever desired. > > ]] > > Does that mean in normal operation, or only in error / timeout scenarios? It is unrestricted in scope. > If that's normal server behaviour, are we repeating the design flaw in > HTTP pipelining that stops it being safe to use for non-idempotent > messages? Web Socket cannot do anything on its own, so no. Your application layer protocol (which does do something) is welcome to add its own restrictions, e.g. requiring a closing handshake. > "32-bit unsigned" seems to be contrary to the debated requirement of > "easy to write by amateurs", as many "scripting" languages don't have > such a type conveniently available. That's news to me; which languages did you have in mind that can't represent all integers up to 4294967295? If this is indeed the case, then we should fix this. On Thu, 6 May 2010, Scott Ferguson wrote: > Simon Pieters wrote: > > > > Yes, but it's not unnecessary to wait with sending the first frame > > from the client, since if it were allowed to send a frame along with > > the opening handshake, then you would be able to send arbitrary HTTP > > requests by carefully crafting your first message so that an HTTP > > server sees first an HTTP upgrade request that it rejects, then a > > bogus HTTP request that it rejects (starting with the 8 random bytes), > > then the attacker's carefully crafted HTTP request which could do > > anything without the user's consent. > > That scenario doesn't really make sense. Nonetheless, it is the scenario for which the spec is designed. > If a server sees random junk, it doesn't keep processing until it sees > something that looks like a HTTP header. Instead, it needs to close the > connection, possibly after returning a 4xx response. (Broken servers are > irrelevant here. If the server is broken, it's a security hole no matter > what the spec says. Servers are not like browsers, which try to keep > processing after bogus data.) Broken servers are most definitely relevant if they are deployed. On Fri, 7 May 2010, Jamie Lokier wrote: > > So a "proper" solution is to ensure that any messages the client sends > after the HTTP headers, prior to the server response, _are_ valid HTTP > with no adverse effect. How does the client know if the server has responded yet or not? (Also, HTTP is not the only possible victim protocol here.) If getting the data from the Web Socket server ASAP is really that critical, it seems better to simply have the HTTP server include the first batch of data in the initial HTTP response that contains the JS that then opens the Web Socket connection. No need to play weird games of trying to make frames look like HTTP or some such. > > If that's the case, that seems like a good reason to lower the maximum > > number in the keys to something that all scripting languages support > > without the developer having to jump through hoops. Maybe we should > > make the range 0-32767 to allow usage of 16-bit signed integers. > > That sounds small enough to be susceptible to simple brute force > connection attempts. The values each time are random, so I don't really see how that would help. It's not like you can try each value in turn. On Sat, 8 May 2010, Brad Spencer wrote: > > So, presumably this means that the intended behaviour when a client > sends a WebSocket handshake directly to a non-WebSocket aware proxy is > to fail. Right. > Now in order to make the connection "fail fast", because I imagine most > HTTP servers are willing to wait for the expected CR LF for quite some > time, then it may be wise to require an additional CR LF after the eight > bytes. This will "force" those servers to look at the "Request-Line" > and fail it. Even that wouldn't really guarantee a fast failure -- I would imagine that it'd be pretty common for the proxy to not return anything until the server has responded, and the server would likely wait for hte 8 bytes (which aren't going to come) for a long time. The goal isn't so much to fail fast, so much as to not appear to succeed. The earlier handshake (what people refer to as "75") would appear to succeeded, only to then fail when the JS tried to send a frame. > Continuing with our "G" method example above, imagine that we allow > early frames from the client, and the client uses frame type 0x2f ('/'), > and sends the payload "1.1\r\nHost:...". Now suddenly we do have > something that looks like a valid HTTP request. I think what Scott > Ferguson suggested deals with this. The odds of this happening are pretty miniscule (somewhere in the range of 1 in 1e16), and that's assuming we ever define the 0x2f frame type. I don't think it's a viable enough attack scenario for anyone to ever use it. Even if the intermediary is truly willing to try hard to interpret anything as a request, so that you only need to get the first four characters to be a case-insensitive match for "GET " and the 8th bit is ignored, say, it's still way less than a one in a million chance with each request. The user is going to notice if you try to open half a million WebSocket connections one after the other (you can't do them all at once, since that is also stopped). But this is all moot, since you can't send any frames until the connection is established anyway. > So, even though I believe it is safe to rely on at least one of the > non-WebSocket servers or the client/browser to abort the connection for > us when a handshake fails, I think I have come to agree with the > WebSocket "draft 76" Section 1.6. I don't think untrusted browser > script should be allowed (by the browser) to send a arbitrarily large > amount of data to a server that has not been shown an intent to > communicate (by sending a valid handshake). Those with specialized > needs to send an initial frame to reduce RTT can probably just use the > /query/ string in the /url/, the old fashioned way. Agreed. On Mon, 10 May 2010, Simon Pieters wrote: > > Yeah, I agree with this. I've done this a lot in my test cases. I think > this is more reliable than any solution we come up with to send the > client's first frame along with the handshake. The subprotocol can also > be abused to send data with the handshake. It's also possible to just open the connection 200ms earlier than you would normally, e.g. by just preemptively opening a connection when the page is opened. I don't really see what concrete cases exist where the handshake will actually be a latency issue. The server can send the data before the connection is made, along with the script that makes the connection. The client isn't going to have data to send before the handshake is established, if it establishes it straight away. What other cases are there? On Mon, 10 May 2010, Jamie Lokier wrote: > > They don't allow the RTT reduction to be implemented as a transport > optimisation "below the API", because the URL and subprotocol fields are > owned by the application above the WebSocket API, and the WebSocket > implementation can't safely transform tem until the initial > negotiatation is complete. Which is too late for any benefit. I don't understand what that means. Both the URL and the subprotocol are under the control of the same script that started the connection and that is going to send the frames. > Maybe it's clearer with an example: > > Even if standardised, Opera/Firefox/Chrome could not implement a > transparent "WebSocket setup RTT reduction" feature using the URL > /query/ or subprotocol mechanisms. > > It would need the JavaScript application to explicitly enable the > extension, or implement it itself. What's the problem with that? > Both options make the API unnecessarily complicated. > > In contrast, the mechanisms I talked about could be implemented in the > browsers transparently, with no change to the JS API and no work by the > application authors at either end. Anything that requires a change on the server obviously requires some work on the server side, by definition. If what you want is for a future feature wherein browsers can opt in to sending some frames before the handshake, though, we can easily extend the protocol later if that's really necessary. We'd just include the payload in a field of the handshake, and then require the server to confirm receipt in its handshake; if the server doesn't confirm, send the frames once connected. But it's not at all clear that we need this; I strongly suggest we wait until we know we need this before doing it. On Tue, 11 May 2010, Brad Spencer wrote: > > FWIW, in line with the "the server and client must agree on the > protocol", I plan to reject any handshakes over a certain size > regardless of what the RFC says, because I know that no legitimate > clients of mine will ever use ridiculously large handshakes. From a > server's point of view, I consider this prudent behaviour. That's fine. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From gregw@webtide.com Tue Jul 20 17:36:14 2010 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 42EB43A6976 for ; Tue, 20 Jul 2010 17:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 fm1URPI-nzss for ; Tue, 20 Jul 2010 17:36:13 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 520D73A6A56 for ; Tue, 20 Jul 2010 17:35:51 -0700 (PDT) Received: by fxm1 with SMTP id 1so3550588fxm.31 for ; Tue, 20 Jul 2010 17:35:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.110.67 with SMTP id m3mr6093637fap.24.1279672542699; Tue, 20 Jul 2010 17:35:42 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Tue, 20 Jul 2010 17:35:42 -0700 (PDT) In-Reply-To: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> Date: Wed, 21 Jul 2010 10:35:42 +1000 Message-ID: From: Greg Wilkins To: Roberto Peon Content-Type: multipart/alternative; boundary=001636c9246e562269048bdafb71 Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 00:36:14 -0000 --001636c9246e562269048bdafb71 Content-Type: text/plain; charset=UTF-8 On 21 July 2010 10:15, Roberto Peon wrote: > > Schools and other institutions will block port 443 if they feel > unacceptable content is flowing over it and they have other means of dealing > with it. > I believe that this means that we need an 'authorized proxy' model. No > proxy would be fully transparent (unless it was a reverse proxy representing > the real endpoint), however it should be exceptionally easy to install a > policy allowing the proxy explicitly. It is a hair more annoying for the > user than no proxy, but it gives schools, etc. a way to control the > computers that they own without blocking port 443 for everyone and > everything. > +1 As Mike has said, there are good motives and bad motives for intermediaries. We have to find a way to allow the good motives to be supported, even if that costs a bit of complexity in the handshake/protocol. Having explicit intermediaries would be very useful for knowing timeouts, optimizing keepalives and security considerations. cheers --001636c9246e562269048bdafb71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 21 July 2010 10:15, Roberto Peon <fenix@google.com&= gt; wrote:

Schools and other institutions will block port 443 if they feel unacceptabl= e content is flowing over it and they have other means of dealing with it.<= /div>
I believe that this means that we need an 'authorized proxy&#= 39; model. No proxy would be fully transparent (unless it was a reverse pro= xy representing the real endpoint), however it should be exceptionally easy= to install a policy allowing the proxy explicitly. It is a hair more annoy= ing for the user than no proxy, but it gives schools, etc. a way to control= the computers that they own without blocking port 443 for everyone and eve= rything.

+1

As Mike has said, there are good mot= ives and bad motives for intermediaries. We have to find a way to allow the= good motives to be supported, even if that costs a bit of complexity in th= e handshake/protocol.

Having explicit intermediaries would be very useful for knowing=C2=A0 t= imeouts, optimizing keepalives and security considerations.

cheers
--001636c9246e562269048bdafb71-- From Martin.Thomson@andrew.com Tue Jul 20 17:37:17 2010 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 88B853A6A84 for ; Tue, 20 Jul 2010 17:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[AWL=-0.546, 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 9lTX5GTVoLve for ; Tue, 20 Jul 2010 17:37:16 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id CF3263A69A3 for ; Tue, 20 Jul 2010 17:37:15 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:51598 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S334577Ab0GUAhb (ORCPT ); Tue, 20 Jul 2010 19:37:31 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 19:37:31 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 21 Jul 2010 08:37:29 +0800 From: "Thomson, Martin" To: Roberto Peon , Greg Wilkins Date: Wed, 21 Jul 2010 08:39:38 +0800 Thread-Topic: [hybi] Extensibility mechanisms? Thread-Index: AcsobE4O4e5APmw+RgmZvmGcPtB4TAAAJddQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773162@SISPE7MB1.commscope.com> References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 00:37:17 -0000 PiBGb3IgYXMgYWRhbWFudGx5IGFzIElhbiBzdGF0ZXMgdGhhdCBpdCBzaG91bGQgYmUgYSByZXF1 aXJlbWVudCwgSSBhbSBqdXN0IGFzIGFkYW1hbnQgdGhhdCBpdCBzaG91bGQgbm90Lg0KPiBFdmVy eSBwcm90b2NvbCBleHBlcnQgSSd2ZSBzcG9rZW4gd2l0aCBhZ3JlZXMgdGhhdCBhbWF0ZXVyIHBy b3RvY29sIGltcGxlbWVudG9ycyBzaG91bGQgbm90IGJlIGEgcmVxdWlyZW1lbnQuDQo+IElzIHRo ZXJlIHNvbWUgd2F5IHdlIGNhbiB2b3RlIHRvIGVpdGhlciBrZWVwIG9yIG51bGxpZnkgdGhpcyBy ZXF1aXJlbWVudCBub3cgYW5kIG5ldmVyIGNvbWUgYmFjayB0byBpdCBhZ2Fpbj8gwqBJJ20gdGly ZWQgb2YgdGhpcyBvYnN0YWNsZSBob2xkaW5nIGV2ZXJ5dGhpbmcgdXAuDQoNCisxDQoNClRoYXQg c2hvdWxkbid0IG1lYW4gdGhhdCBzaW1wbGljaXR5IGlzIG5vdCBhIGRlc2lnbiBnb2FsLCBqdXN0 IHRoYXQgaXQncyBub3QgYW4gb3ZlcnJpZGluZyBjb25zdHJhaW50Lg0K From Martin.Thomson@andrew.com Tue Jul 20 17:45:11 2010 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 239303A69BB for ; Tue, 20 Jul 2010 17:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-0.531, 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 yoNE4nA+RMac for ; Tue, 20 Jul 2010 17:45:09 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 42AEA3A69B2 for ; Tue, 20 Jul 2010 17:45:09 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:52644 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S284895Ab0GUApZ (ORCPT ); Tue, 20 Jul 2010 19:45:25 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 19:45:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 21 Jul 2010 08:45:19 +0800 From: "Thomson, Martin" To: Greg Wilkins , Roberto Peon Date: Wed, 21 Jul 2010 08:47:28 +0800 Thread-Topic: [hybi] WebSocket, TLS and intermediaries Thread-Index: AcsobP215VdlkMHyQwK4cYE4AMXu8QAAHS1A Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773169@SISPE7MB1.commscope.com> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 00:45:11 -0000 DQoNCkdyZWcgV2lsa2lucyBvbiAyMSBKdWx5IDIwMTAgMTA6MzYgQU06DQo+IE9uIDIxIEp1bHkg MjAxMCAxMDoxNSwgUm9iZXJ0byBQZW9uIDxmZW5peEBnb29nbGUuY29tPiB3cm90ZToNCg0KPiA+ IFNjaG9vbHMgYW5kIG90aGVyIGluc3RpdHV0aW9ucyB3aWxsIGJsb2NrIHBvcnQgNDQzIGlmIHRo ZXkgZmVlbCB1bmFjY2VwdGFibGUgY29udGVudCBpcyBmbG93aW5nIG92ZXIgaXQgYW5kIHRoZXkg aGF2ZSBvdGhlciBtZWFucyBvZiBkZWFsaW5nIHdpdGggaXQuDQo+ID4gSSBiZWxpZXZlIHRoYXQg dGhpcyBtZWFucyB0aGF0IHdlIG5lZWQgYW4gJ2F1dGhvcml6ZWQgcHJveHknIG1vZGVsLiBObyBw cm94eSB3b3VsZCBiZSBmdWxseSB0cmFuc3BhcmVudCAodW5sZXNzIGl0IHdhcyBhIHJldmVyc2Ug cHJveHkgcmVwcmVzZW50aW5nIHRoZSByZWFsIGVuZHBvaW50KSwgaG93ZXZlciBpdCBzaG91bGQg YmUgZXhjZXB0aW9uYWxseSBlYXN5IHRvIGluc3RhbGwgYSBwb2xpY3kgYWxsb3dpbmcgdGhlIHBy b3h5IGV4cGxpY2l0bHkuIEl0IGlzIGEgaGFpciBtb3JlIGFubm95aW5nIGZvciB0aGUgdXNlciB0 aGFuIG5vIHByb3h5LCBidXQgaXQgZ2l2ZXMgc2Nob29scywgZXRjLiBhIHdheSB0byBjb250cm9s IHRoZSBjb21wdXRlcnMgdGhhdCB0aGV5IG93biB3aXRob3V0IGJsb2NraW5nIHBvcnQgNDQzIGZv ciBldmVyeW9uZSBhbmQgZXZlcnl0aGluZy4NCj4NCj4gKzENCj4NCj4gQXMgTWlrZSBoYXMgc2Fp ZCwgdGhlcmUgYXJlIGdvb2QgbW90aXZlcyBhbmQgYmFkIG1vdGl2ZXMgZm9yIGludGVybWVkaWFy aWVzLiBXZSBoYXZlIHRvIGZpbmQgYSB3YXkgdG8gYWxsb3cgdGhlIGdvb2QgbW90aXZlcyB0byBi ZSBzdXBwb3J0ZWQsIGV2ZW4gaWYgdGhhdCBjb3N0cyBhIGJpdCBvZiBjb21wbGV4aXR5IGluIHRo ZSBoYW5kc2hha2UvcHJvdG9jb2wuDQo+DQo+IEhhdmluZyBleHBsaWNpdCBpbnRlcm1lZGlhcmll cyB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBmb3Iga25vd2luZ8KgIHRpbWVvdXRzLCBvcHRpbWl6aW5n IGtlZXBhbGl2ZXMgYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KDQorMQ0KDQpEZXNwaXRl IHRoZSBmYWN0IHRoYXQgYSBwb2xpY3ktZW5mb3JjaW5nIHByb3h5IG9mdGVuIGNhdXNlcyBhIGxv dCBvZiBncmllZiwgdGhlIGFsdGVybmF0aXZlIGlzIHdvcnNlLiAgV2UgZG9uJ3QgbmVlZCBhbm90 aGVyIGFybXMgcmFjZS4gIFJlY29nbml6aW5nIHRoYXQgcGVvcGxlIHdpbGwgZW5hY3QgcG9saWN5 LCBhbmQgcHJvdmlkaW5nIHdheXMgdGhhdCBjbGllbnRzIGNhbiBjb29wZXJhdGUsIGlzIG1vcmUg Y29uc3RydWN0aXZlIHRoYW4gdHJ5aW5nIHRvIGNpcmN1bXZlbnQgcG9saWN5IG1lYXN1cmVzLg0K DQotLU1hcnRpbg0KDQoNCg== From jamie@shareable.org Tue Jul 20 17:50:27 2010 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 06F973A69B2 for ; Tue, 20 Jul 2010 17:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 0CvkD63dNQef for ; Tue, 20 Jul 2010 17:50:25 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 5F70B3A6800 for ; Tue, 20 Jul 2010 17:50:25 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObNWA-0007Ly-HR; Wed, 21 Jul 2010 01:50:38 +0100 Date: Wed, 21 Jul 2010 01:50:38 +0100 From: Jamie Lokier To: John Tamplin Message-ID: <20100721005038.GA27243@shareable.org> References: <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 00:50:27 -0000 John Tamplin wrote: > I still don't see the argument for servers written by amateurs. I > have used far more quick-and-dirty web clients (telnet, > socket/connect/write in C, wget/curl, etc) than I have quick-and-dirty > servers. If some amateur needs to write a server anyway, they aren't > going to write it from scratch even if it were possible for them to do > so -- they will find some library. > Contrast this with embedded clients, which might well have tighter > constraints than most clients, and could benefit from having optional > features they could leave out that would be useful for more powerful > clients. Meanwhile, the servers are going to almost certainly be on > more powerful machines, though granted they have more connections to > support. But I must say I don't see a problem with keeping it in reach to amateur programers, at the same time as supporting smarter features. The two requirements are easily reconciled. I'm a big fan of the "complex protocols" end of the spectrum - because I consistently advocate multiplexing, feature negotiation, proxy opt-ins, message splitting and other "complex" things; all of them are driven by the desire for good performance (over a variety of measures), and providing a consistently simple "it just works" API to the API users. All that's needed, for amateur programmer compatibility, is for the "complex" performance-enhancing features to be optional negotiated features on top of an extremely simple base protocol. And for the negotiation to be really simple too. That's a good idea anyway. We have a great analogue of this in HTTP's optional persistent connections. Simple clients and simple servers don't handle persistent connections; better ones do, and every combination works just fine. Here's how I imagine it working: The big browsers get decent WS implementations, and are good at performance-related things that are "hidden under the API", like automatic sharing of connections, merged keepalives, and maybe even things like network-signalled-callback on phones. They request the most useful enhancers in negotiation, but they work if the answer is "no". They can continue to be extended if we think of newer techniques. Well known servers (Apache etc.) get decent implementations, and can handle the performance-enhancing features. They negotiate "yes" to all the most useful enhancers. Some proxies like those on a mobile network recognise negotiation and can add enhancements like network-signalled-callback mentioned above, and even connection fan-in / fan-out if that proves to be technically workable. Other proxies, including HTTP ones, don't participate in negotiation and are simply transparent. Joe Random wants to write a quick WebSocket server in half a page of Python. That's fine: He implements the minimum base protocol, which is designed to be very simple (providing the minimum needed for the WebSocket API to work) and it *just works* with all browsers and other clients. Negotiation is basically "no" to all features. Same when Joe Random wants to write a quick client. The most important part of this model is that negotiation is sane and extensible right from the start, and that it has room for all the interested parties: "below the API" client requested features, proxy requested/recognised features, server requested features. The existing subprotocol field provides the fourth: "above the API" client requested features. As setup latency is an issue, it is also important that negotiation does not incur avoidable round trips. A second important thing is subtler: It is important that features negotiated transparently "below the API" are carefully designed to be *invisible* to WebSocket API users. Connection sharing is the best example (but it also applies to keepalive merging): Sending an erroneous message on one channel of a shared connection must not break all the others; if a receiver event queue fills, thereby stalling that channel, it must not block messages from flowing to the others; and sending a very large message on one channel must not block others for a long time. Otherwise the behaviour isn't transparent enough as an *automatic* under-the-hood replacement for separate connections. -- Jamie From ian@hixie.ch Tue Jul 20 17:57:05 2010 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 6605D3A67F5 for ; Tue, 20 Jul 2010 17:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 udpoXivJHGeB for ; Tue, 20 Jul 2010 17:57:04 -0700 (PDT) Received: from looneymail-a2.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 36BC53A6800 for ; Tue, 20 Jul 2010 17:57:04 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a2.g.dreamhost.com (Postfix) with ESMTP id 4BF4116D3E0; Tue, 20 Jul 2010 17:57:20 -0700 (PDT) Date: Wed, 21 Jul 2010 00:57:19 +0000 (UTC) From: Ian Hickson To: Doug Simpkinson , Greg Wilkins , Maciej Stachowiak In-Reply-To: Message-ID: References: <4BE5994E.4010701@webtide.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hybi@ietf.org Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 00:57:05 -0000 On Fri, 7 May 2010, Doug Simpkinson wrote: > > In draft 76, the upgrade request is said to include cookies that may be > relevant, but no mention of other HTTP headers is made. > > What about other relevant HTTP headers such as User-Agent and > Accept-Language? Shouldn't these also be sent? What's the use case? If there are clear and important use cases that are best handled by adding new fields to the handshake, then we should add them. > My concern is that if these headers are not explicitly mentioned in the > draft spec that they won't be sent by all implementations, and that will > make life more difficult for webmasters. I've clarified the spec to make it clearer that these headers are not included. On Sat, 8 May 2010, Greg Wilkins wrote: > > the 76 pre draft actually exclude header other than those mentioned with > phrase: > > The only options available in this version are the ... > > While I don't think this text is very clear, I did ask the editor if it > was meant to exclude headers not mentioned and he indicated that this > was the case. The text above is non-normative, but the requirements are pretty explicit and do indeed not include any provision for including other fields. On Sun, 9 May 2010, Doug Simpkinson wrote: > > Do you know what's the reasoning behind omitting any HTTP headers? > What advantage is there to not sending User-Agent and Accept-Language? That's the wrong question -- the question is, what's the advantage to sending them? The more we omit, the simpler the protocol is. The default should be to omit. In the case of User-Agent, for instance, one could put forward analytics as a use case. However, for that use case it seems best for the application-layer protocol to opt into sending the information. That way the author is in complete control as to what is logged. > It is quite common for different browsers to have different behavior, so > omitting User-Agent removes some flexibility in dealing with browser > quirks. Having the spec be trivial to implement makes it less likely that there will be differences, making this moot. In practice, browser sniffing has been as much of a problem as a help -- people sniff for a browser, then rely on that browser's behaviour, and when the browser vendor tries to fix the underlying problems, or tries to converge with other browsers, they find they cannot because pages send them different content than other browsers. This is why, for instance, every successful browser in the world claims to be "Mozilla". On Mon, 10 May 2010, Maciej Stachowiak wrote: > > Likewise for Accept-Language. I would be tempted say that language > selection could just be handled as part of subprotocol negotiation, but > at least currently JS in the browser does not have easy access to the > user's set of preferred languages. Nor does the user, in many cases... -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jamie@shareable.org Tue Jul 20 18:12:13 2010 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 DF4C33A69BB for ; Tue, 20 Jul 2010 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 oHjNI7SkR8P7 for ; Tue, 20 Jul 2010 18:12:11 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 7B5033A69B6 for ; Tue, 20 Jul 2010 18:12:11 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObNrB-0007Rn-Ej; Wed, 21 Jul 2010 02:12:21 +0100 Date: Wed, 21 Jul 2010 02:12:21 +0100 From: Jamie Lokier To: Ian Hickson Message-ID: <20100721011221.GC27243@shareable.org> References: <4BE5994E.4010701@webtide.com> 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 Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 01:12:13 -0000 Ian Hickson wrote: > On Fri, 7 May 2010, Doug Simpkinson wrote: > > > > In draft 76, the upgrade request is said to include cookies that may be > > relevant, but no mention of other HTTP headers is made. > > > > What about other relevant HTTP headers such as User-Agent and > > Accept-Language? Shouldn't these also be sent? > > What's the use case? > > If there are clear and important use cases that are best handled by adding > new fields to the handshake, then we should add them. The use case for User-Agent, normally determined by the client implementation (not the application running on top of the WebSocket API), is to provide servers with unreliable but pragmatically useful information about what client implementations are using the server. It is used for profiling, for general interest, for tracking what clients may need to be supported if there are particular issues to be avoided with some clients (such as a particular message that breaks one of them), for tracking when clients with particular workarounds on the server have fallen into sufficient misuse that the workarounds can be removed, and for implementing specific workarounds for particular recognised clients. Hopefully workarounds at the WebSocket framing level are unlikely to be commonly needed (although that might not be true if some clients have a small message size limit and particular server applications have to format their messages to accomodate this); but User-Agent turned out to be quite pragmatic in HTTP for dealing with client-specific issues that nobody had foreseen until they were too widely deployed to ignore or fix. -- Jamie From mjs@apple.com Tue Jul 20 18:20:32 2010 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 A584E3A6A84 for ; Tue, 20 Jul 2010 18:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KuC6JFIWx1u2 for ; Tue, 20 Jul 2010 18:20:31 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id EE25E3A69B0 for ; Tue, 20 Jul 2010 18:20:30 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id ED37C9EAB2B5 for ; Tue, 20 Jul 2010 18:20:46 -0700 (PDT) X-AuditID: 11807137-b7b43ae000004f8e-b4-4c464b6e247d Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id D4.57.20366.E6B464C4; Tue, 20 Jul 2010 18:20:46 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KG934hvKPjXk82SQ1QDmlA)" Received: from [17.151.78.226] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5V00JU2VQM6V10@gertie.apple.com> for hybi@ietf.org; Tue, 20 Jul 2010 18:20:46 -0700 (PDT) From: Maciej Stachowiak In-reply-to: Date: Tue, 20 Jul 2010 18:20:46 -0700 Message-id: <852209CE-F064-4FE3-A6FC-A91A90DEF749@apple.com> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> To: Greg Wilkins X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 01:20:32 -0000 --Boundary_(ID_KG934hvKPjXk82SQ1QDmlA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jul 20, 2010, at 5:35 PM, Greg Wilkins wrote: > > > On 21 July 2010 10:15, Roberto Peon wrote: > > Schools and other institutions will block port 443 if they feel unacceptable content is flowing over it and they have other means of dealing with it. > I believe that this means that we need an 'authorized proxy' model. No proxy would be fully transparent (unless it was a reverse proxy representing the real endpoint), however it should be exceptionally easy to install a policy allowing the proxy explicitly. It is a hair more annoying for the user than no proxy, but it gives schools, etc. a way to control the computers that they own without blocking port 443 for everyone and everything. > > +1 > > As Mike has said, there are good motives and bad motives for intermediaries. We have to find a way to allow the good motives to be supported, even if that costs a bit of complexity in the handshake/protocol. > > Having explicit intermediaries would be very useful for knowing timeouts, optimizing keepalives and security considerations. In the TLS case, authorizing an intermediary has to require some form of explicit configuration on at least one of the client or the server. Otherwise it is vulnerable to MITM. On the server side, the intermediary could plausibly have access to the server's certificate, so it can just pretend to be the endpoint to the client. On the client side, there has to be some way to authorize a root cert for use with WebSocket, so the intermediary can MITM you. If it needs to be easier than this, then that seems like primarily a browser UI issue, not a protocol issue. We could do other things for the non-TLS case, but I am increasingly convinced that the non-TLS case is uninteresting. Regards, Maciej --Boundary_(ID_KG934hvKPjXk82SQ1QDmlA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
On Jul 20, 2010, at 5:35 PM, Greg Wilkins wrote:



On 21 July 2010 10:15, Roberto Peon <fenix@google.com> wrote:

Schools and other institutions will block port 443 if they feel unacceptable content is flowing over it and they have other means of dealing with it.
I believe that this means that we need an 'authorized proxy' model. No proxy would be fully transparent (unless it was a reverse proxy representing the real endpoint), however it should be exceptionally easy to install a policy allowing the proxy explicitly. It is a hair more annoying for the user than no proxy, but it gives schools, etc. a way to control the computers that they own without blocking port 443 for everyone and everything.

+1

As Mike has said, there are good motives and bad motives for intermediaries. We have to find a way to allow the good motives to be supported, even if that costs a bit of complexity in the handshake/protocol.

Having explicit intermediaries would be very useful for knowing  timeouts, optimizing keepalives and security considerations.

In the TLS case, authorizing an intermediary has to require some form of explicit configuration on at least one of the client or the server. Otherwise it is vulnerable to MITM. On the server side, the intermediary could plausibly have access to the server's certificate, so it can just pretend to be the endpoint to the client. On the client side, there has to be some way to authorize a root cert for use with WebSocket, so the intermediary can MITM you. If it needs to be easier than this, then that seems like primarily a browser UI issue, not a protocol issue.

We could do other things for the non-TLS case, but I am increasingly convinced that the non-TLS case is uninteresting.

Regards,
Maciej

--Boundary_(ID_KG934hvKPjXk82SQ1QDmlA)-- From gregw@webtide.com Tue Jul 20 18:38:03 2010 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 D1F9B3A6A84 for ; Tue, 20 Jul 2010 18:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 59diD-KffRiJ for ; Tue, 20 Jul 2010 18:38:02 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 7596A3A698F for ; Tue, 20 Jul 2010 18:38:02 -0700 (PDT) Received: by fxm1 with SMTP id 1so3564517fxm.31 for ; Tue, 20 Jul 2010 18:38:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.5 with SMTP id y5mr3027467fap.93.1279676297523; Tue, 20 Jul 2010 18:38:17 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Tue, 20 Jul 2010 18:38:17 -0700 (PDT) In-Reply-To: References: <4BE5994E.4010701@webtide.com> Date: Wed, 21 Jul 2010 11:38:17 +1000 Message-ID: From: Greg Wilkins To: Ian Hickson Content-Type: multipart/alternative; boundary=0016e6db7bc02431b1048bdbdb9a Cc: hybi@ietf.org Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 01:38:04 -0000 --0016e6db7bc02431b1048bdbdb9a Content-Type: text/plain; charset=UTF-8 On 21 July 2010 10:57, Ian Hickson wrote: > On Fri, 7 May 2010, Doug Simpkinson wrote: > > > > In draft 76, the upgrade request is said to include cookies that may be > > relevant, but no mention of other HTTP headers is made. > > > > What about other relevant HTTP headers such as User-Agent and > > Accept-Language? Shouldn't these also be sent? > > What's the use case? > Ian, it is a little disingenuous of you to fall back on the "what's the use case?" stone wall on topics like this that have been long discussed and people have given many use cases at length. You might not understand and/or agree with the use cases presented, but that is entirely different to pretending that others have not motivated their contributions to the discussion with good reasoning. The result of continually asking "what is the use-case" when it has already been explained many times, is that the list just goes around and around in endless circles. In this particular case, it has been long argued that arbitrary headers should be allowed in the handshake for flexibility and anticipation of future needs. You've refuted the need for generally extensible header. Now Doug motivated his comment with the specific use-case of using user-agent for dealing with browser quirks. Let's flip this around the otherway... because allowing arbitrary headers is not really a feature of websocket is not really a feature because before the upgrade the connection is HTTP and thus arbitrary headers is allowed. In essence, you should be making the use-case for adding a "feature" to the websocket handshake to prevent the addition of arbitrary headers. So what is the use-case for that? I know you have previously argued that somehow it would be easier for amateur not to have to write code to ignore headers (surely they just don't write code to handle them?), but the amateur programmer requirement has been widely rejected. Is there any other use-case that motivates the rejection of websocket handshakes due to the presence of additional ignorable headers? --0016e6db7bc02431b1048bdbdb9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 21 July 2010 10:57, Ian Hickson <ian@hixie.ch> wrote:
On Fri, 7 May 2010, Doug Simpkinson wrote:
>
> In draft 76, the upgrade request is said to include cookies that may b= e
> relevant, but no mention of other HTTP headers is made.
>
> What about other relevant HTTP headers such as User-Agent and
> Accept-Language? =C2=A0Shouldn't these also be s= ent?

What's the use case?

Ian,

it is a= little disingenuous of you to fall back on the "what's the use ca= se?" stone wall
on topics like this that have been long discussed a= nd people have given many use
cases at length.=C2=A0=C2=A0 You might not understand and/or agree with the= use cases presented,
but that is entirely different to pretending that= others have not motivated their contributions
to the discussion with go= od reasoning.

The result of continually asking "what is the use-case" when = it has already been explained
many times, is that the list just goes ar= ound and around in endless circles.

In this particular case, it has = been long argued that arbitrary headers should be allowed in
the handshake for flexibility and anticipation of future needs. =C2=A0 You&= #39;ve refuted the need for
generally extensible header.=C2=A0 Now=C2=A0= Doug motivated his comment with the specific
use-case of using user-ag= ent for dealing with browser quirks.


Let's flip this around the otherway... because allowing arbitra= ry headers is not really
a feature of websocket is not really a feature= because before the upgrade the connection
is HTTP and thus arbitrary he= aders is allowed.

In essence, you should be making the use-case for adding a "featur= e" to the websocket
handshake to prevent the addition of arbitrary = headers.

So what is the use-case for that?=C2=A0 I know you have pre= viously argued that somehow it
would be easier for amateur not to have to write code to ignore headers (su= rely they
just don't write code to handle them?), but the amateur p= rogrammer requirement has been
widely rejected.=C2=A0=C2=A0=C2=A0=C2=A0 = Is there any other use-case that motivates the rejection of websocket
handshakes due to the presence of additional ignorable headers?


=













=C2=A0


<= /div>
--0016e6db7bc02431b1048bdbdb9a-- From gregw@webtide.com Tue Jul 20 18:49:18 2010 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 8C26E3A6A79 for ; Tue, 20 Jul 2010 18:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 1h2GCmi7IUoF for ; Tue, 20 Jul 2010 18:49:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 486993A65A6 for ; Tue, 20 Jul 2010 18:49:12 -0700 (PDT) Received: by fxm1 with SMTP id 1so3566650fxm.31 for ; Tue, 20 Jul 2010 18:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.122.146 with SMTP id l18mr6120764far.82.1279676967532; Tue, 20 Jul 2010 18:49:27 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Tue, 20 Jul 2010 18:49:27 -0700 (PDT) In-Reply-To: References: <4BE5994E.4010701@webtide.com> Date: Wed, 21 Jul 2010 11:49:27 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: multipart/alternative; boundary=001636c5a78f13b950048bdc0309 Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 01:49:18 -0000 --001636c5a78f13b950048bdc0309 Content-Type: text/plain; charset=UTF-8 I'll try writing that again in fully formed English sentences this time (sorry too much in a rush): Ian, it is a little disingenuous of you to fall back on the "what's the use case?" stone wall on topics like this that have been long discussed and people have given many use cases at length. You might not understand and/or agree with the use cases presented, but that is entirely different to pretending that others have not motivated their contributions to the discussion with good reasoning. The result of continually asking "what is the use-case" when it has already been explained many times, is that the list just goes around and around in endless circles. In this particular case, it has been long argued that arbitrary headers should be allowed in the handshake for flexibility and anticipation of future needs. You've refuted the need for generally extensible header. Now Doug motivated his comment with the specific use-case of using user-agent for dealing with browser quirks. Let's flip this around the otherway... because allowing arbitrary headers is not really a feature to be added to websocket because before the upgrade the connection is HTTP and thus arbitrary headers are by default allowed. In essence, you are trying to add a "feature" to the websocket handshake to prevent the addition of arbitrary headers. So what is the use-case for that? I know you have previously argued that somehow it would be easier for amateurs not to have to write code to ignore headers (surely they just don't write code to handle them?), but the amateur programmer requirement has been widely rejected. Is there any other use-case that motivates the rejection of websocket handshakes due to the presence of additional ignorable headers? regards On 21 July 2010 11:38, Greg Wilkins wrote: > > > On 21 July 2010 10:57, Ian Hickson wrote: > >> On Fri, 7 May 2010, Doug Simpkinson wrote: >> > >> > In draft 76, the upgrade request is said to include cookies that may be >> > relevant, but no mention of other HTTP headers is made. >> > >> > What about other relevant HTTP headers such as User-Agent and >> > Accept-Language? Shouldn't these also be sent? >> >> What's the use case? >> > > Ian, > > it is a little disingenuous of you to fall back on the "what's the use > case?" stone wall > on topics like this that have been long discussed and people have given > many use > cases at length. You might not understand and/or agree with the use cases > presented, > but that is entirely different to pretending that others have not motivated > their contributions > to the discussion with good reasoning. > > The result of continually asking "what is the use-case" when it has already > been explained > many times, is that the list just goes around and around in endless > circles. > > In this particular case, it has been long argued that arbitrary headers > should be allowed in > the handshake for flexibility and anticipation of future needs. You've > refuted the need for > generally extensible header. Now Doug motivated his comment with the > specific > use-case of using user-agent for dealing with browser quirks. > > > Let's flip this around the otherway... because allowing arbitrary headers > is not really > a feature of websocket is not really a feature because before the upgrade > the connection > is HTTP and thus arbitrary headers is allowed. > > In essence, you should be making the use-case for adding a "feature" to the > websocket > handshake to prevent the addition of arbitrary headers. > > So what is the use-case for that? I know you have previously argued that > somehow it > would be easier for amateur not to have to write code to ignore headers > (surely they > just don't write code to handle them?), but the amateur programmer > requirement has been > widely rejected. Is there any other use-case that motivates the > rejection of websocket > handshakes due to the presence of additional ignorable headers? > > > > > > > > > > > > > > > > > > > > --001636c5a78f13b950048bdc0309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll try writing that again in fully formed English sentences this = time (sorry too much in a rush):


Ian,

it is a little disi= ngenuous of you to fall back on the=20 "what's the use case?" stone wall
on topics like this that= have been=20 long discussed and people have given many use
cases at length.=C2=A0=C2=A0 You might not understand and/or agree with the= use=20 cases presented,
but that is entirely different to pretending that=20 others have not motivated their contributions
to the discussion with=20 good reasoning.

The result of continually asking "what is the use-case" when = it has=20 already been explained
many times, is that the list just goes around and around in endless circles.

In this particular case, it has=20 been long argued that arbitrary headers should be allowed in
the handshake for flexibility and anticipation of future needs. =C2=A0 You&= #39;ve refuted the need for
generally extensible header.=C2=A0 Now=C2=A0 Doug= =20 motivated his comment with the specific
use-case of using user-agent for dealing with browser quirks.

Let's flip this around the otherway... because allowing=20 arbitrary headers is not really
a feature to be added to=C2=A0 websocke= t=C2=A0 because before the upgrade the connection
is HTTP and thus arbitrary headers are by default allowed.

In essence, you are trying to add a "feature" to the websocket handshake to prevent
the addition of arbitrary=20 headers.

So what is the use-case for that?=C2=A0 I know you have=20 previously argued that somehow it
would be easier for amateurs not to have to write code to ignore headers=20 (surely they
just don't write code to handle them?), but the amateu= r programmer requirement has been
widely rejected.=C2=A0=C2=A0=C2=A0=C2= =A0 Is there any=20 other use-case that motivates the rejection of websocket
handshakes due to the presence of additional ignorable headers?

rega= rds





On 21 July 2010 11:38= , Greg Wilkins <g= regw@webtide.com> wrote:


On 21 July 2010 10:57, Ian Hickson <ian@hix= ie.ch> wrote:
On Fri, 7 May 2010, Doug Simpkinson wrote:
>
> In draft 76, the upgrade request is said to include cookies that may b= e
> relevant, but no mention of other HTTP headers is made.
>
> What about other relevant HTTP headers such as User-Agent and
> Accept-Language? =C2=A0Shouldn't these also be sent?

What's the use case?

Ian,

i= t is a little disingenuous of you to fall back on the "what's the = use case?" stone wall
on topics like this that have been long discu= ssed and people have given many use
cases at length.=C2=A0=C2=A0 You might not understand and/or agree with the= use cases presented,
but that is entirely different to pretending that= others have not motivated their contributions
to the discussion with go= od reasoning.

The result of continually asking "what is the use-case" when = it has already been explained
many times, is that the list just goes ar= ound and around in endless circles.

In this particular case, it has = been long argued that arbitrary headers should be allowed in
the handshake for flexibility and anticipation of future needs. =C2=A0 You&= #39;ve refuted the need for
generally extensible header.=C2=A0 Now=C2=A0= Doug motivated his comment with the specific
use-case of using user-ag= ent for dealing with browser quirks.


Let's flip this around the otherway... because allowing arbitra= ry headers is not really
a feature of websocket is not really a feature= because before the upgrade the connection
is HTTP and thus arbitrary he= aders is allowed.

In essence, you should be making the use-case for adding a "featur= e" to the websocket
handshake to prevent the addition of arbitrary = headers.

So what is the use-case for that?=C2=A0 I know you have pre= viously argued that somehow it
would be easier for amateur not to have to write code to ignore headers (su= rely they
just don't write code to handle them?), but the amateur p= rogrammer requirement has been
widely rejected.=C2=A0=C2=A0=C2=A0=C2=A0 = Is there any other use-case that motivates the rejection of websocket
handshakes due to the presence of additional ignorable headers?


=













=C2=A0


<= /div>

--001636c5a78f13b950048bdc0309-- From w@1wt.eu Tue Jul 20 21:44:52 2010 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 DA2373A6B59 for ; Tue, 20 Jul 2010 21:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[AWL=-2.169, 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 89O--8RR7tqy for ; Tue, 20 Jul 2010 21:44:52 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id B509A3A69D7 for ; Tue, 20 Jul 2010 21:44:51 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L4iuYh029456; Wed, 21 Jul 2010 06:44:56 +0200 Date: Wed, 21 Jul 2010 06:44:56 +0200 From: Willy Tarreau To: Mike Belshe Message-ID: <20100721044456.GB26999@1wt.eu> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> 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: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 04:44:53 -0000 On Tue, Jul 20, 2010 at 04:29:07PM -0700, Mike Belshe wrote: > BTW - there is another data point here; deployment of WebSockets over port > 80 was measured in Chrome to have ~67% success rate today. Deployment over > port 443 (with TLS) has a >95% success rate. So, if you don't use TLS, then > browsers and websites will need to be made more complex to deal with the > edge case of WebSockets failing in weird ways due to existing intermediaries > which fail, even after the WebSocket handshake. I'm not surprized at all by this, the handshake it build so that most cases which would transparently work by default will fail ! This is the big failure of this protocol right now. We're trying to break compatibility with 10 years of work towards interoperability between components that try their best to be transparent to each other, and everything will have to be reinvented from scratch. Willy From w@1wt.eu Tue Jul 20 21:48:06 2010 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 028513A6B59 for ; Tue, 20 Jul 2010 21:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.14 X-Spam-Level: X-Spam-Status: No, score=-4.14 tagged_above=-999 required=5 tests=[AWL=-2.097, 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 AM1wzEAWdwru for ; Tue, 20 Jul 2010 21:48:05 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 8C5C63A6B4F for ; Tue, 20 Jul 2010 21:48:04 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L4mGG5029486; Wed, 21 Jul 2010 06:48:16 +0200 Date: Wed, 21 Jul 2010 06:48:16 +0200 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20100721044816.GC26999@1wt.eu> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> 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: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 04:48:06 -0000 On Tue, Jul 20, 2010 at 05:01:02PM -0700, Maciej Stachowiak wrote: > > BTW - there is another data point here; deployment of WebSockets over port 80 was measured in Chrome to have ~67% success rate today. Deployment over port 443 (with TLS) has a >95% success rate. So, if you don't use TLS, then browsers and websites will need to be made more complex to deal with the edge case of WebSockets failing in weird ways due to existing intermediaries which fail, even after the WebSocket handshake. > > This point is very important. Building on top of TLS has huge practical benefits. I think this outweighs the desire to more easily build transparent intermediaries. Any mechanism that allows intermediaries without being authorized by either endpoint is by definition a security vulnerability in the protocol. > > I think the benefits of TLS also outweigh the "amateur server implementor" argument. I don't think we want to make it easy to implement a security hole. There's no "security hole" here. If you don't need security, use port 80, if you need security, use port 443. That's been working that way for the web for decades and that's no secret even for non-technical people. Clear traffic offers reliability and large possibilities while ciphered traffic offers security with less possibilities. Nothing new here. Willy From w@1wt.eu Tue Jul 20 21:51:51 2010 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 AF2A13A69CD for ; Tue, 20 Jul 2010 21:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.072 X-Spam-Level: X-Spam-Status: No, score=-4.072 tagged_above=-999 required=5 tests=[AWL=-2.029, 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 yv0jr-zRYmKF for ; Tue, 20 Jul 2010 21:51:50 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 855BB3A698F for ; Tue, 20 Jul 2010 21:51:50 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L4q21m029527; Wed, 21 Jul 2010 06:52:02 +0200 Date: Wed, 21 Jul 2010 06:52:02 +0200 From: Willy Tarreau To: Roberto Peon Message-ID: <20100721045202.GD26999@1wt.eu> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> 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: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 04:51:51 -0000 On Tue, Jul 20, 2010 at 05:11:16PM -0700, Roberto Peon wrote: > On Tue, Jul 20, 2010 at 5:04 PM, John Tamplin wrote: > > > On Tue, Jul 20, 2010 at 8:01 PM, Maciej Stachowiak wrote: > > > >> This point is very important. Building on top of TLS has huge practical > >> benefits. I think this outweighs the desire to more easily build transparent > >> intermediaries. Any mechanism that allows intermediaries without being > >> authorized by either endpoint is by definition a security vulnerability in > >> the protocol. > >> > >> I think the benefits of TLS also outweigh the "amateur server implementor" > >> argument. I don't think we want to make it easy to implement a security > >> hole. > >> > > > > How would requiring TLS impact games over WebSocket, such as GWT Quake? > > Maybe one day we will have a connection-oriented datagram protocol for WS, > > but until then we have to make do with running over TCP. Adding encryption > > overhead might render WS unusable for this purpose. > > > > I'd be pretty surprised if SSL added enough overhead that it made WS > unsuitable for games. It is far, far, far, more likely that the fact that > we're using TCP renders it useless for certain classes of games. SSL adds a lot of overhead due to the block mode for protocols exchanging a few bytes in each direction. Think about chats where each typed character will be sent as a few tens of bytes. This costs in terms of network bandwidth, CPU and perceived latency for the user. Compare SSH with telnet over slow links. Also, SSL will limit adoption because at many places it will simply not be available. It's very common to white-list only a handful of SSL sites in many enterprises, schools, etc... Willy From w@1wt.eu Tue Jul 20 22:06:32 2010 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 B20343A684C for ; Tue, 20 Jul 2010 22:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.009 X-Spam-Level: X-Spam-Status: No, score=-4.009 tagged_above=-999 required=5 tests=[AWL=-1.966, 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 ga-uKTvuJsO9 for ; Tue, 20 Jul 2010 22:06:31 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 7940C3A69CD for ; Tue, 20 Jul 2010 22:06:31 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L56hbF029891; Wed, 21 Jul 2010 07:06:43 +0200 Date: Wed, 21 Jul 2010 07:06:43 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100721050643.GE26999@1wt.eu> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> 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: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 05:06:32 -0000 On Wed, Jul 21, 2010 at 10:35:42AM +1000, Greg Wilkins wrote: > On 21 July 2010 10:15, Roberto Peon wrote: > > > > > Schools and other institutions will block port 443 if they feel > > unacceptable content is flowing over it and they have other means of dealing > > with it. > > I believe that this means that we need an 'authorized proxy' model. No > > proxy would be fully transparent (unless it was a reverse proxy representing > > the real endpoint), however it should be exceptionally easy to install a > > policy allowing the proxy explicitly. It is a hair more annoying for the > > user than no proxy, but it gives schools, etc. a way to control the > > computers that they own without blocking port 443 for everyone and > > everything. > > > > +1 > > As Mike has said, there are good motives and bad motives for intermediaries. > We have to find a way to allow the good motives to be supported, even if > that costs a bit of complexity in the handshake/protocol. In my opinion, supporting the good ones should exactly cost nothing : just rely on what they correctly support : HTTP. Many intermediaries are there because they're required in the infrastructure they're deployed in : (client side) - protocol-based proxy farm selection (eg: use the WS-compatible farm for WS and the other one for HTTP) - proxy load-balancers (server side) - IDS/Protocol inspection - reverse-proxy load balancers - reverse-proxies (SSL, compression, WAF, inter-DMZ bounce) - URL switching to select server pools The "bad motives" intermediaries are generally the ones that do transparent caching and such features. But they're not really "bad motives" in that they're here to improve users' bandwidth. However, they're often doing badness because the users can't decide to bypass them. But since they're themselves generally load-balanced, it's not difficult to add information in the request (eg: "Upgrade: WebSocket") that the load balancers can use to bypass the transparent proxy farm. There are generally a lot of cache bypass rules on such farms because ISPs are used to receive users complaints for site XXX or YYY which does not work. So adding bypass rules to such farms is just a matter of days at most places, once the first issues are encountered. And contrary to a common belief, it's probably the place where the fixes/workarounds can be implemented the fastest, because there are no security considerations and we know that ISPs don't take too much time validating products. Regards, Willy From w@1wt.eu Tue Jul 20 22:10:55 2010 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 1E3883A6B55 for ; Tue, 20 Jul 2010 22:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-1.906, 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 FumDBaxwHRC8 for ; Tue, 20 Jul 2010 22:10:53 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 125C23A6B33 for ; Tue, 20 Jul 2010 22:10:52 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L5B3BY030005; Wed, 21 Jul 2010 07:11:03 +0200 Date: Wed, 21 Jul 2010 07:11:03 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100721051103.GF26999@1wt.eu> References: <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <20100721005038.GA27243@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721005038.GA27243@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 05:10:55 -0000 On Wed, Jul 21, 2010 at 01:50:38AM +0100, Jamie Lokier wrote: > John Tamplin wrote: > > I still don't see the argument for servers written by amateurs. ? I > > have used far more quick-and-dirty web clients (telnet, > > socket/connect/write in C, wget/curl, etc) than I have quick-and-dirty > > servers. ? If some amateur needs to write a server anyway, they aren't > > going to write it from scratch even if it were possible for them to do > > so -- they will find some library. > > Contrast this with embedded clients, which might well have tighter > > constraints than most clients, and could benefit from having optional > > features they could leave out that would be useful for more powerful > > clients. ? Meanwhile, the servers are going to almost certainly be on > > more powerful machines, though granted they have more connections to > > support. > > But I must say I don't see a problem with keeping it in reach to > amateur programers, at the same time as supporting smarter features. > The two requirements are easily reconciled. > > I'm a big fan of the "complex protocols" end of the spectrum - because > I consistently advocate multiplexing, feature negotiation, proxy > opt-ins, message splitting and other "complex" things; all of them are > driven by the desire for good performance (over a variety of > measures), and providing a consistently simple "it just works" API to > the API users. > > All that's needed, for amateur programmer compatibility, is for the > "complex" performance-enhancing features to be optional negotiated > features on top of an extremely simple base protocol. And for the > negotiation to be really simple too. > > That's a good idea anyway. > > We have a great analogue of this in HTTP's optional persistent > connections. Simple clients and simple servers don't handle > persistent connections; better ones do, and every combination > works just fine. > > Here's how I imagine it working: > > The big browsers get decent WS implementations, and are good at > performance-related things that are "hidden under the API", like > automatic sharing of connections, merged keepalives, and maybe even > things like network-signalled-callback on phones. They request the > most useful enhancers in negotiation, but they work if the answer is > "no". They can continue to be extended if we think of newer techniques. > > Well known servers (Apache etc.) get decent implementations, and can > handle the performance-enhancing features. They negotiate "yes" > to all the most useful enhancers. > > Some proxies like those on a mobile network recognise negotiation and > can add enhancements like network-signalled-callback mentioned above, > and even connection fan-in / fan-out if that proves to be technically > workable. Other proxies, including HTTP ones, don't participate in > negotiation and are simply transparent. > > Joe Random wants to write a quick WebSocket server in half a page of > Python. That's fine: He implements the minimum base protocol, which > is designed to be very simple (providing the minimum needed for the > WebSocket API to work) and it *just works* with all browsers and other > clients. Negotiation is basically "no" to all features. > > Same when Joe Random wants to write a quick client. > > The most important part of this model is that negotiation is sane and > extensible right from the start, and that it has room for all the > interested parties: "below the API" client requested features, proxy > requested/recognised features, server requested features. The > existing subprotocol field provides the fourth: "above the API" client > requested features. +1 Willy From w@1wt.eu Tue Jul 20 22:13:56 2010 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 EB49F3A684C for ; Tue, 20 Jul 2010 22:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.893 X-Spam-Level: X-Spam-Status: No, score=-3.893 tagged_above=-999 required=5 tests=[AWL=-1.850, 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 r22OgMkZ-K2M for ; Tue, 20 Jul 2010 22:13:54 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 0BF893A6B33 for ; Tue, 20 Jul 2010 22:13:53 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L5DxPn030070; Wed, 21 Jul 2010 07:13:59 +0200 Date: Wed, 21 Jul 2010 07:13:59 +0200 From: Willy Tarreau To: "Thomson, Martin" Message-ID: <20100721051359.GG26999@1wt.eu> References: <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> <8B0A9FCBB9832F43971E38010638454F03EB773162@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB773162@SISPE7MB1.commscope.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 05:13:56 -0000 On Wed, Jul 21, 2010 at 08:39:38AM +0800, Thomson, Martin wrote: > > For as adamantly as Ian states that it should be a requirement, I am just as adamant that it should not. > > Every protocol expert I've spoken with agrees that amateur protocol implementors should not be a requirement. > > Is there some way we can vote to either keep or nullify this requirement now and never come back to it again? I'm tired of this obstacle holding everything up. > > +1 > > That shouldn't mean that simplicity is not a design goal, just that it's not an overriding constraint. +1 Willy From w@1wt.eu Tue Jul 20 22:19:05 2010 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 4874F3A6B2E for ; Tue, 20 Jul 2010 22:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.84 X-Spam-Level: X-Spam-Status: No, score=-3.84 tagged_above=-999 required=5 tests=[AWL=-1.797, 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 NaFFnFGtfQFQ for ; Tue, 20 Jul 2010 22:19:03 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 662313A6A86 for ; Tue, 20 Jul 2010 22:19:03 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L5JAsm030194; Wed, 21 Jul 2010 07:19:10 +0200 Date: Wed, 21 Jul 2010 07:19:10 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100721051910.GH26999@1wt.eu> References: <4BE5994E.4010701@webtide.com> <20100721011221.GC27243@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721011221.GC27243@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 05:19:05 -0000 On Wed, Jul 21, 2010 at 02:12:21AM +0100, Jamie Lokier wrote: > Ian Hickson wrote: > > On Fri, 7 May 2010, Doug Simpkinson wrote: > > > > > > In draft 76, the upgrade request is said to include cookies that may be > > > relevant, but no mention of other HTTP headers is made. > > > > > > What about other relevant HTTP headers such as User-Agent and > > > Accept-Language? Shouldn't these also be sent? > > > > What's the use case? > > > > If there are clear and important use cases that are best handled by adding > > new fields to the handshake, then we should add them. > > The use case for User-Agent, normally determined by the client > implementation (not the application running on top of the WebSocket > API), is to provide servers with unreliable but pragmatically useful > information about what client implementations are using the server. > > It is used for profiling, for general interest, for tracking what > clients may need to be supported if there are particular issues to be > avoided with some clients (such as a particular message that breaks > one of them), for tracking when clients with particular workarounds on > the server have fallen into sufficient misuse that the workarounds can > be removed, and for implementing specific workarounds for particular > recognised clients. And it's used a lot to act differently with smartphones. Maybe that could be used on the server side to try to group outgoing data into fewer packets in order to improve user experience or reduce communication costs. Willy From w@1wt.eu Tue Jul 20 22:25:03 2010 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 712B53A69F8 for ; Tue, 20 Jul 2010 22:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-1.747, 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 ly5BZP2Q3aIE for ; Tue, 20 Jul 2010 22:25:02 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 1B30E3A68A3 for ; Tue, 20 Jul 2010 22:25:01 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6L5PHdf030305; Wed, 21 Jul 2010 07:25:17 +0200 Date: Wed, 21 Jul 2010 07:25:17 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100721052517.GI26999@1wt.eu> References: <4BE5994E.4010701@webtide.com> 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: hybi@ietf.org Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 05:25:03 -0000 On Wed, Jul 21, 2010 at 11:49:27AM +1000, Greg Wilkins wrote: > I'll try writing that again in fully formed English sentences this time > (sorry too much in a rush): > > > Ian, > > it is a little disingenuous of you to fall back on the "what's the use > case?" stone wall > on topics like this that have been long discussed and people have given many > use > cases at length. You might not understand and/or agree with the use cases > presented, > but that is entirely different to pretending that others have not motivated > their contributions > to the discussion with good reasoning. > > The result of continually asking "what is the use-case" when it has already > been explained > many times, is that the list just goes around and around in endless circles. > > In this particular case, it has been long argued that arbitrary headers > should be allowed in > the handshake for flexibility and anticipation of future needs. You've > refuted the need for > generally extensible header. Now Doug motivated his comment with the > specific > use-case of using user-agent for dealing with browser quirks. And I see a very important one concerning cookies. Cookies are important to the server but also to the infrastructure. They're used a lot to enable "persistence" or "stickiness", depending how it's called. They make it possible for server-side load balancers to direct the users's connection to the same server he was on previous connection. This is of particular importance here because most often we'll need the WS connection to reach the same server as the one which initiated a local context. And for this it is important to be able to match reliable content in the request. This is normally performed using cookies that are assigned by either the server, the load balancer or sometimes even some JS on the client. This is one more reason to support standard headers with standard HTTP in the handshake. > Let's flip this around the otherway... because allowing arbitrary headers is > not really > a feature to be added to websocket because before the upgrade the > connection > is HTTP and thus arbitrary headers are by default allowed. > > In essence, you are trying to add a "feature" to the websocket handshake to > prevent > the addition of arbitrary headers. > > So what is the use-case for that? I know you have previously argued that > somehow it > would be easier for amateurs not to have to write code to ignore headers > (surely they > just don't write code to handle them?), but the amateur programmer > requirement has been > widely rejected. Is there any other use-case that motivates the > rejection of websocket > handshakes due to the presence of additional ignorable headers? Indeed, why break something which works well, is well understood, well mastered and well debugged ? Willy From fenix@google.com Tue Jul 20 22:38:20 2010 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 B517F3A6B5D for ; Tue, 20 Jul 2010 22:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 dMjQgNcZcGEE for ; Tue, 20 Jul 2010 22:38:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 648963A6783 for ; Tue, 20 Jul 2010 22:38:00 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o6L5bcQJ019620 for ; Tue, 20 Jul 2010 22:37:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279690659; bh=6kAUoQhdJf2c/WHKae57TArYqH0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RCG4N43lvx5eQ9oerHkWZ3HpqlEJdKscRHoI0XQm6jZiCBVyLHEWRtE8E7TCawjac BfBgEtpCXHEaNRBpsgHMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=RslFzO2LhvY7fvBnr9F6ZqO6Q4SLV1kZ3i7qpRfpeJO7F9wha3gNRVEFyB7AU4mc9 C1t4Ab//+CTrZldgHnO1A== Received: from yxj4 (yxj4.prod.google.com [10.190.3.68]) by kpbe17.cbf.corp.google.com with ESMTP id o6L5bagn011374 for ; Tue, 20 Jul 2010 22:37:37 -0700 Received: by yxj4 with SMTP id 4so2118756yxj.36 for ; Tue, 20 Jul 2010 22:37:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.175.17 with SMTP id x17mr1220215ybe.300.1279690656425; Tue, 20 Jul 2010 22:37:36 -0700 (PDT) Received: by 10.150.59.4 with HTTP; Tue, 20 Jul 2010 22:37:36 -0700 (PDT) In-Reply-To: <20100721005038.GA27243@shareable.org> References: <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <20100721005038.GA27243@shareable.org> Date: Tue, 20 Jul 2010 22:37:36 -0700 Message-ID: From: Roberto Peon To: Jamie Lokier Content-Type: multipart/alternative; boundary=00151748dc8effa85d048bdf32db X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 05:38:21 -0000 --00151748dc8effa85d048bdf32db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have some experience with dealing with broken HTTP client implementations in nearly-impossible-to-update devices such as televisions, phones, etc. We're starting from scratch, so hopefully we won't have the confusion of poor implementations that HTTP does, but I'd end up really sad if I had to make my server not use advanced features of a *new* protocol because some clients identify their capabilities wrongly. Yes, we've had to do this. It is really, really, painful. To be clear: I'm not motivated to make it possible for amateurs to make servers or clients. I am motivated to ensure that the protocol *just* complex enough to do what we want, and otherwise as simple and unambiguous as possible. If that enables "amateur programmers" to write clients or servers that spea= k a subset of the protocol... great! If not, hopefully they can hack on a reference implementation! I strongly hope that we'll end up with a 100% functional reference implementation that we publish with the spec. I also strongly hope that we'll end up with a conformance suite (as a resul= t of creating the reference implementation). -=3DR On Tue, Jul 20, 2010 at 5:50 PM, Jamie Lokier wrote: > John Tamplin wrote: > > I still don't see the argument for servers written by amateurs. =EF= =BF=BD I > > have used far more quick-and-dirty web clients (telnet, > > socket/connect/write in C, wget/curl, etc) than I have quick-and-dir= ty > > servers. =EF=BF=BD If some amateur needs to write a server anyway, t= hey aren't > > going to write it from scratch even if it were possible for them to = do > > so -- they will find some library. > > Contrast this with embedded clients, which might well have tighter > > constraints than most clients, and could benefit from having optiona= l > > features they could leave out that would be useful for more powerful > > clients. =EF=BF=BD Meanwhile, the servers are going to almost certai= nly be on > > more powerful machines, though granted they have more connections to > > support. > > But I must say I don't see a problem with keeping it in reach to > amateur programers, at the same time as supporting smarter features. > The two requirements are easily reconciled. > > I'm a big fan of the "complex protocols" end of the spectrum - because > I consistently advocate multiplexing, feature negotiation, proxy > opt-ins, message splitting and other "complex" things; all of them are > driven by the desire for good performance (over a variety of > measures), and providing a consistently simple "it just works" API to > the API users. > > All that's needed, for amateur programmer compatibility, is for the > "complex" performance-enhancing features to be optional negotiated > features on top of an extremely simple base protocol. And for the > negotiation to be really simple too. > > That's a good idea anyway. > > We have a great analogue of this in HTTP's optional persistent > connections. Simple clients and simple servers don't handle > persistent connections; better ones do, and every combination > works just fine. > > Here's how I imagine it working: > > The big browsers get decent WS implementations, and are good at > performance-related things that are "hidden under the API", like > automatic sharing of connections, merged keepalives, and maybe even > things like network-signalled-callback on phones. They request the > most useful enhancers in negotiation, but they work if the answer is > "no". They can continue to be extended if we think of newer techniques. > > Well known servers (Apache etc.) get decent implementations, and can > handle the performance-enhancing features. They negotiate "yes" > to all the most useful enhancers. > > Some proxies like those on a mobile network recognise negotiation and > can add enhancements like network-signalled-callback mentioned above, > and even connection fan-in / fan-out if that proves to be technically > workable. Other proxies, including HTTP ones, don't participate in > negotiation and are simply transparent. > > Joe Random wants to write a quick WebSocket server in half a page of > Python. That's fine: He implements the minimum base protocol, which > is designed to be very simple (providing the minimum needed for the > WebSocket API to work) and it *just works* with all browsers and other > clients. Negotiation is basically "no" to all features. > > Same when Joe Random wants to write a quick client. > > The most important part of this model is that negotiation is sane and > extensible right from the start, and that it has room for all the > interested parties: "below the API" client requested features, proxy > requested/recognised features, server requested features. The > existing subprotocol field provides the fourth: "above the API" client > requested features. > > As setup latency is an issue, it is also important that negotiation > does not incur avoidable round trips. > > A second important thing is subtler: It is important that features > negotiated transparently "below the API" are carefully designed to be > *invisible* to WebSocket API users. > > Connection sharing is the best example (but it also applies to > keepalive merging): Sending an erroneous message on one channel of a > shared connection must not break all the others; if a receiver event > queue fills, thereby stalling that channel, it must not block messages > from flowing to the others; and sending a very large message on one > channel must not block others for a long time. Otherwise the > behaviour isn't transparent enough as an *automatic* under-the-hood > replacement for separate connections. > > -- Jamie > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --00151748dc8effa85d048bdf32db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have some experience with dealing with broken HTTP client implementations= in nearly-impossible-to-update devices such as televisions, phones, etc.We're starting from scratch, so hopefully we won't have the conf= usion of poor implementations that HTTP does, but I'd end up really sad= if I had to make my server not use advanced features of a *new* protocol b= ecause some clients identify their=C2=A0capabilities=C2=A0wrongly.

Yes, we've had to do this. It is really, really, pa= inful.

To be clear: I'm not motivated to make = it possible for amateurs to make servers or clients.
I am motivat= ed to ensure that the protocol *just* complex enough to do what we want, an= d otherwise as simple and unambiguous as possible.

If that enables "amateur programmers" to writ= e clients or servers that speak a subset of the protocol... great!
If not, hopefully they can hack on a reference implementation!

I strongly hope that we'll end up with a 100% functional= reference implementation that we publish with the spec.
I also s= trongly hope that we'll end up with a conformance suite (as a result of= creating the reference implementation).

-=3DR

On Tue, = Jul 20, 2010 at 5:50 PM, Jamie Lokier <jamie@shareable.org> wrote:
John Tamplin wrote:
> =C2=A0 =C2=A0I still don't see the argument for servers written by= amateurs. =EF=BF=BD I
> =C2=A0 =C2=A0have used far more quick-and-dirty web clients (telnet, > =C2=A0 =C2=A0socket/connect/write in C, wget/curl, etc) than I have qu= ick-and-dirty
> =C2=A0 =C2=A0servers. =EF=BF=BD If some amateur needs to write a serve= r anyway, they aren't
> =C2=A0 =C2=A0going to write it from scratch even if it were possible f= or them to do
> =C2=A0 =C2=A0so -- they will find some library.
> =C2=A0 =C2=A0Contrast this with embedded clients, which might well hav= e tighter
> =C2=A0 =C2=A0constraints than most clients, and could benefit from hav= ing optional
> =C2=A0 =C2=A0features they could leave out that would be useful for mo= re powerful
> =C2=A0 =C2=A0clients. =EF=BF=BD Meanwhile, the servers are going to al= most certainly be on
> =C2=A0 =C2=A0more powerful machines, though granted they have more con= nections to
> =C2=A0 =C2=A0support.

But I must say I don't see a problem with keeping it in reach to<= br> amateur programers, at the same time as supporting smarter features.
The two requirements are easily reconciled.

I'm a big fan of the "complex protocols" end of the spectrum = - because
I consistently advocate multiplexing, feature negotiation, proxy
opt-ins, message splitting and other "complex" things; all of the= m are
driven by the desire for good performance (over a variety of
measures), and providing a consistently simple "it just works" AP= I to
the API users.

All that's needed, for amateur programmer compatibility, is for the
"complex" performance-enhancing features to be optional negotiate= d
features on top of an extremely simple base protocol. =C2=A0And for the
negotiation to be really simple too.

That's a good idea anyway.

We have a great analogue of this in HTTP's optional persistent
connections. =C2=A0Simple clients and simple servers don't handle
persistent connections; better ones do, and every combination
works just fine.

Here's how I imagine it working:

The big browsers get decent WS implementations, and are good at
performance-related things that are "hidden under the API", like<= br> automatic sharing of connections, merged keepalives, and maybe even
things like network-signalled-callback on phones. =C2=A0They request the most useful enhancers in negotiation, but they work if the answer is
"no". =C2=A0They can continue to be extended if we think of newer= techniques.

Well known servers (Apache etc.) get decent implementations, and can
handle the performance-enhancing features. =C2=A0They negotiate "yes&q= uot;
to all the most useful enhancers.

Some proxies like those on a mobile network recognise negotiation and
can add enhancements like network-signalled-callback mentioned above,
and even connection fan-in / fan-out if that proves to be technically
workable. =C2=A0Other proxies, including HTTP ones, don't participate i= n
negotiation and are simply transparent.

Joe Random wants to write a quick WebSocket server in half a page of
Python. =C2=A0That's fine: He implements the minimum base protocol, whi= ch
is designed to be very simple (providing the minimum needed for the
WebSocket API to work) and it *just works* with all browsers and other
clients. =C2=A0Negotiation is basically "no" to all features.

Same when Joe Random wants to write a quick client.

The most important part of this model is that negotiation is sane and
extensible right from the start, and that it has room for all the
interested parties: "below the API" client requested features, pr= oxy
requested/recognised features, server requested features. =C2=A0The
existing subprotocol field provides the fourth: "above the API" c= lient
requested features.

As setup latency is an issue, it is also important that negotiation
does not incur avoidable round trips.

A second important thing is subtler: It is important that features
negotiated transparently "below the API" are carefully designed t= o be
*invisible* to WebSocket API users.

Connection sharing is the best example (but it also applies to
keepalive merging): Sending an erroneous message on one channel of a
shared connection must not break all the others; if a receiver event
queue fills, thereby stalling that channel, it must not block messages
from flowing to the others; and sending a very large message on one
channel must not block others for a long time. =C2=A0Otherwise the
behaviour isn't transparent enough as an *automatic* under-the-hood
replacement for separate connections.

-- Jamie

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


--00151748dc8effa85d048bdf32db-- From julian.reschke@gmx.de Tue Jul 20 23:07:38 2010 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 47EC53A6A86 for ; Tue, 20 Jul 2010 23:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[AWL=-1.353, 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 dQdIkyg3N9ab for ; Tue, 20 Jul 2010 23:07:35 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1A00B3A684C for ; Tue, 20 Jul 2010 23:07:34 -0700 (PDT) Received: (qmail invoked by alias); 21 Jul 2010 06:07:49 -0000 Received: from p508FFB72.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.251.114] by mail.gmx.net (mp023) with SMTP; 21 Jul 2010 08:07:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18UvExo2PkUlANYjdgtsN4MYIFJyNxSAUX/bpAbgX nqH4j0TPfh9uxc Message-ID: <4C468EAE.4050507@gmx.de> Date: Wed, 21 Jul 2010 08:07:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Maciej Stachowiak References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 06:07:38 -0000 On 21.07.2010 02:01, Maciej Stachowiak wrote: > ... > Also, in practice it does not seem to be the case that intermediaries > are updated faster than clients or servers. One of the challenges to > deploying new protocols or protocol features is old intermediaries that > are not updated. > ... The same has been said about clients (IE6) and servers (Apache httpd prior to implementing DefaultType None) just within a week :-) From ian@hixie.ch Tue Jul 20 23:47:40 2010 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 2B8313A6A62 for ; Tue, 20 Jul 2010 23:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 njrlq4J4omtt for ; Tue, 20 Jul 2010 23:47:38 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 830E83A69CF for ; Tue, 20 Jul 2010 23:47:38 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 50DFB15D565; Tue, 20 Jul 2010 23:47:54 -0700 (PDT) Date: Wed, 21 Jul 2010 06:47:54 +0000 (UTC) From: Ian Hickson To: Jamie Lokier In-Reply-To: <20100519013238.GB2318@shareable.org> Message-ID: References: <4BF11920.2080307@webtide.com> <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 06:47:40 -0000 On Wed, 19 May 2010, Jamie Lokier wrote: > > > > If we want to support multiple subprotocols at once, we can do so > > quite easily by just making the subprotocol list be comma-separated. > > Would this be a good idea? > > I think it is a good idea, although there is a risk of low-quality > server but significant implementations matching a literal string, > breaking when other values are added to the comma-separate list, and > therefore making it impossible for clients to actually use the > capability. Yeah, though since that bug would be specific to implementations of particular subprotocols, it would be pretty localised to individual communities. That's probably an acceptable problem. I've added this to the spec for now. http://html5.org/tools/web-apps-tracker?from=5172&to=5173 > But assuming the comma-separated list did catch on, a consequence of > that would be the "below the API" part of WebSocket would have a place > to add its own distinct entries to the comma-separated list, for > recognition by the other side as transport option requests (such as > compression, etc.), safe in the knowledge it wouldn't break negotiation. > > (Separate headers would be much cleaner for that, though). I don't see why we wouldn't just use separate fields for that. No need to overload the subprotocol field. > > > - Trying a HTTP-based protocol if WebSocket is unavailable (ditto) > > > > That wouldn't work anyway because the WebSocket object isn't the same > > object as the XMLHttpRequest object and they therefore create entirely > > different connections. > > Just being different objects is not technical reason for different > connections. Separate XMLHttpRequest objects have no problem sharing > connections. There is no technical reason why a WebSocket object could > not do the same, just as easily. Especially in browsers which routinely > do this! I guess. I'm not convinced it's a good idea though. > > In any case, why wouldn't you know that Web Socket is available? I > > don't understand why you would guess that it is and then find it > > isn't. You need a URL to connect to a Web Socket, why would you make > > up a URL without knowing whether it'll work? > > Earlier in this thread, in a reply to you, we already gave an example. > It was the social networking client that talks to numerous de facto > standardised but different WebSocket protocols that the user shouldn't > have to know about. > > Basically because autonegotiation is more user-friendly, both in terms > of users having to be given and enter fewer details, and in terms of > telling the user what went wrong if things didn't work out. > > As you noted, people don't always pass around URLs - they often pass > around just a domain name, or a truncated URL that doesn't include the > "http:" prefix. > > I would agree if it were _complicated_ to do, but we are talking about > really trivial stuff here. Trying one thing, then trying another, is > already handled by the handshake, and it is utterly trivial to do from a > script. It's so easy that it's hard to see why any random web developer > wouldn't use it whenever it seemed like a good idea. > > It seems obvious to me that countless Javascripts will do exactly that. I could see trying multiple WebSocket protocols over one connection, but trying to try both HTTP or WebSocket connections, not to mention any other protocols the servers might provide, seems like massive complexity for negligible gain overall. > > This can be supported entirely in Web Socket if we want to do that. > > Currently, it's not clear that supporting this is even desireable, due > > to the UI issues with doing so. > > (On that topic, how do you propose to get through a proxy on port 443 > that needs proxy authentication before it passes a CONNECT request?) I guess the UA would have to use the existing (suboptimal) UI for proxy auth. It's not a good situation to be in; I wouldn't recommend it. > > WebSocket and HTTP are different protocols. Reusing the connection > > makes as much sense as reusing the connection of an FTP connection > > attempt to do an HTTP connection attempt. > > This is different. Both WebSockets and HTTP requests are transient in > many cases. FTP is more transient than WebSockets. WebSockets is intended for connections that just stay open. It's not intended for transient use. It's not at all designed for transient use. It will do poorly when used for transient use. > If FTP was also transient, and it shared the same port with > HTTP, and many servers especially those designed for high performance > implemented both together, and many clients implemented both, then of > course it would make sense to _permit_ connection reuse between them, > without _requiring_ any implementation to do so. I think it would be pretty silly even in those cases, personally. Reusing connections amongst multiple protocols is simply asking for bugs. The benefits are minimal and the costs are high. If you want to do multiple things on a connection, use a protocol that supports all those things, don't try to switch back and forth between protocols. (By extension, I think the Upgrade mechanism in HTTP isn't a particularly good idea. The number of times the mechanism has been used to great success on the Web somewhat supports my position on this, I think.) > There is a much stronger case for reusing a WebSocket connection after a > gracefully close that puts it into some kind of idle state. That's > because users follow links every few seconds - and therefore WebSocket > scripts in ordinary pages will connect and disconnect from the same > server and port every few seconds in the current model. What use cases are you imagining that have Web Sockets used in such scenarios? None of the intended use cases even remotely resemble this. Web Sockets is intended for use on pages that are long-lived. It's quite possible that there are use cases on short-lived pages also, but they probably need their own protocol, optimised for those cases (e.g. HTTP and the text/event-stream EventSource mechanism). WebSockets isn't trying to be everything for everyone, it's just trying to address the specific use case of trivially-implementable long-lived TCP-like connections for Web browsers. > Making it optional for both sides adds *zero* complexity for authors who > don't do it. I am not seeing how you can think it makes any difference > to them. Clients have to support it. This means implementation cost, testing cost, and bug-fixing cost. It then propagates to documentation, which means reference costs, tutorial costs, etc. This further means that authors will see the feature in documentation. This leads to cognition costs when learning the material, information retrieval costs when distinguishing whether something is relevant or not when debugging, and communication costs when discussing the feature with others, e.g. when determining whether the feature is relevant to the question someone is asking. Then there's the cost of maintaining code that someone else has written that _does_ use the feature, there's the cost of debugging browser bugs when the feature is misimplemented and interacts even with code that doesn't use the feature, and finally there's the cost of implementing the feature on the server side once it makes its way onto check-mark lists of features that every web developer customer wants to support. > Seriously, how do you imagine it affects them? Optional features are a lie. Nothing is really optional in a platform like the Web's -- the only way a feature can be "free" is if it doesn't exist. This is why we have to justify everything we add, and make sure it's on the right side of the 80/20 line. > > who would have no idea why their WebSocket servers were suddenly > > receiving random HTTP requests and vice versa. > > That's a function of connecting to the wrong type of server already, and > it's already dealt with by the spec'd negotation, which the wrong type > of server handles already by design. Nothing new there. If we supported connection reuse and there was misconfiguration, then the kinds of failure scenarios would be much more varied than they are now. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Wed Jul 21 00:01:17 2010 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 6C59C3A677C for ; Wed, 21 Jul 2010 00:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 S5tKWAX6SkeN for ; Wed, 21 Jul 2010 00:01:15 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 4AD313A697A for ; Wed, 21 Jul 2010 00:01:15 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 8385815D565; Wed, 21 Jul 2010 00:01:31 -0700 (PDT) Date: Wed, 21 Jul 2010 07:01:31 +0000 (UTC) From: Ian Hickson To: Wellington Fernando de Macedo In-Reply-To: Message-ID: References: Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hybi@ietf.org Subject: Re: [hybi] Authentication headers 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, 21 Jul 2010 07:01:17 -0000 On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote: > > I'm updating the Mozilla's implementation of the WS protocol to its > latest version (v.76). I know that handling the 401 http response was > already removed in the v75. But now I've noted that even the http > Authorization header has been removed. > > Well, I think that the 401 http status was removed in order to prevent > the browser to open unexpected auth dialogs to the user. Actually, I > know there is the cookie information, but I think it isn't always > enough. So, I would like to ask, why can't a "normal" request include > the Authorization header from its page origin? There's some commented-out text to that effect, but frankly it's not clear to me that it would be particularly useful in practice. For example, the only authentication scheme that would work and be secure is Basic auth over TLS to the same host as served the HTML page. In practice, only very few sites use that combination of technologies; the cost of supporting it seems higher than the benefit gained from it. It also seems unreliable; it relies on the browser remembering the credentials used when loading the Web page, for instance. There are also a number of situations where it would seem that it should work but where it won't, for example if a page on one path uses pushState() to go to another path and then opens a WebSocket connection to the same host with the second path, the UA would not know the realm of the second path and thus wouldn't know to include the authentication information. Basically, it seemed hacky. I couldn't really find a compelling argument to support this rather than having it at the application layer. (You can still leverage the basic auth feature that way, just have the server send back a unique token that identifies the user's session and then pass that back on the WebSocket connection.) Cookies are supported because they are _very_ widely used, so there's something to reuse. HTTP auth is used so rarely that I'd seriously consider dropping it from HTTP at this point; I really don't think it's worth adding to WebSockets. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Wed Jul 21 00:18:21 2010 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 C56983A69BC for ; Wed, 21 Jul 2010 00:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 XSOlsX3gIsr7 for ; Wed, 21 Jul 2010 00:18:20 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id B73E83A677C for ; Wed, 21 Jul 2010 00:18:20 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id BAE9D15D565; Wed, 21 Jul 2010 00:18:36 -0700 (PDT) Date: Wed, 21 Jul 2010 07:18:36 +0000 (UTC) From: Ian Hickson To: Salvatore Loreto In-Reply-To: <4C1F3F93.2020805@ericsson.com> Message-ID: References: <4C1F3F93.2020805@ericsson.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "hybi@ietf.org" Subject: Re: [hybi] HyBi WG update 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, 21 Jul 2010 07:18:21 -0000 On Mon, 21 Jun 2010, Salvatore Loreto wrote: > > The 00 version Ian Hickson has update contains in the Abstract section, > the following note: > > NOTE! THIS COPY OF THIS DOCUMENT IS OBSOLETE. > > For an up-to-date copy of this specification, please see: > > http://www.whatwg.org/specs/web-socket-protocol/ > > this note is against the IETF common practice, so we invite Ian to remove it. The note is there because Joe requested that I not update the IETF copy as often as the WHATWG copy. I need implementors looking at the latest version of the draft. I don't really mind if they look at the HTML copy on the WHATWG site (part of the Web Apps 1.0 draft), the text copy on the WHATWG site, or the text copy on the IETF site, so long as what they look at is up to date. Should I resume sending updates to the IETF draft as I make them? > If the authors that want to make available proposed changes that aren't > yet in a published ID then the canonical approach would be to keep the > "current edits" version on tools.ietf.org in the WG's Subversion > repository (both as xml source and txt) : > http://svn.tools.ietf.org/svn/wg/hybi/ Is there a reference anywhere that explains how to get an account there? I'd be happy to update my scripts to also upload a copy there. If we can host the latest copy of the spec there I'm more than happy to change the link in the note at the top to point to that draft instead, if that would make everyone at the IETF less nervous. > We also invite Ian to remove the following Author's note section [...] For why? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Wed Jul 21 00:19:22 2010 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 BCA2A3A677C for ; Wed, 21 Jul 2010 00:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 WgKwViGB+OTh for ; Wed, 21 Jul 2010 00:19:22 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 02F3C3A681F for ; Wed, 21 Jul 2010 00:19:22 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 4BCB215D565; Wed, 21 Jul 2010 00:19:38 -0700 (PDT) Date: Wed, 21 Jul 2010 07:19:38 +0000 (UTC) From: Ian Hickson To: =?iso-8859-15?Q?Erik_M=F6ller?= In-Reply-To: Message-ID: References: Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1555694626-1174950047-1279696778=:7242" Cc: Hybi Subject: Re: [hybi] 64-bit comment 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, 21 Jul 2010 07:19:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1555694626-1174950047-1279696778=:7242 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 24 Jun 2010, Erik M=F6ller wrote: > > [43. Let expected be the MD5 fingerprint of challenge as a big-endian 128= bit > string. [RFC1321]] >=20 > A comment on the 64-bit issue of that code could be helpful I think. If y= ou're > just trying WebSockets on for size and do a simple server you're likely j= ust > going to use the code from rfc1321 to calculate the Md5 and it's pretty e= asy > to miss the fact that it contains the following definition: >=20 > /* UINT4 defines a four byte word */ > typedef unsigned long int UINT4; >=20 > Works fine on 32-bit OS and LLP64 (i.e. Win64) but on any other 64-bit OS > that's going to typedef UINT4 to be 8 bytes which will happily compile wi= thout > errors but will produce an incorrect hash. I'm very happy to include a note here, what text would you suggest? --=20 Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ---1555694626-1174950047-1279696778=:7242-- From julian.reschke@gmx.de Wed Jul 21 00:35:26 2010 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 D354E3A69EC for ; Wed, 21 Jul 2010 00:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=-1.289, 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 tJiICxt+VH26 for ; Wed, 21 Jul 2010 00:35:25 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 675A33A68B3 for ; Wed, 21 Jul 2010 00:35:24 -0700 (PDT) Received: (qmail invoked by alias); 21 Jul 2010 07:35:38 -0000 Received: from p508FFB72.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.251.114] by mail.gmx.net (mp022) with SMTP; 21 Jul 2010 09:35:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18BjA9RMfMBMBNn83vGL+/XN9VMaGG1fj53WrAcs9 YdP4Fv/HyfYaX5 Message-ID: <4C46A344.1010600@gmx.de> Date: Wed, 21 Jul 2010 09:35:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Ian Hickson References: <4C1F3F93.2020805@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] HyBi WG update 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, 21 Jul 2010 07:35:26 -0000 On 21.07.2010 09:18, Ian Hickson wrote: > ... >> If the authors that want to make available proposed changes that aren't >> yet in a published ID then the canonical approach would be to keep the >> "current edits" version on tools.ietf.org in the WG's Subversion >> repository (both as xml source and txt) : >> http://svn.tools.ietf.org/svn/wg/hybi/ > > Is there a reference anywhere that explains how to get an account there? > I'd be happy to update my scripts to also upload a copy there. If we can > host the latest copy of the spec there I'm more than happy to change the > link in the note at the top to point to that draft instead, if that would > make everyone at the IETF less nervous. > ... I think you first need an account for tools.ietf.org, see and then talk to the owner of the repo (that is, the chairs) to get write access to subversion. Best regards, Julian From simone.bordet@gmail.com Wed Jul 21 00:55:51 2010 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 B60383A6802 for ; Wed, 21 Jul 2010 00:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 naLDYud6niV7 for ; Wed, 21 Jul 2010 00:55:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9B5F03A63D3 for ; Wed, 21 Jul 2010 00:55:50 -0700 (PDT) Received: by fxm1 with SMTP id 1so3668020fxm.31 for ; Wed, 21 Jul 2010 00:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=UmSBX3ExbxgQRi32VUnwg8UOSzBQk2rNosig0ULNFqo=; b=fJB5FqvQ6F8wkXAU4xtXPYjzJ7B7iSP3/MU/LIiyZwRp9eU2EjQC1wKhWPi8wb6rhg z7iqaS2crHQ38aZQBm8aVv3ebtLWP1nMsgp7rU7294DvN41cYRVTU9ROcq8WeaSd61fw gZwPYh3ayeXhpIkCNHG6hQOgoKEcbAVzlX6s0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=sVbP7Oe0Ja27NNu5LwW8Me59m/O72FXAEcBTGOnuFCv1IQK4cwm0IzK2/wC0jrNZuO JmLA7GMPVcalmmdlk7g+foP2bbe9/Li2On6tVSLcLwhDzM2zkbKsQMPea5YLEQoh/22D tEycr++C3T5tzmBCzGHpKtRFpW1M8RvVx8gro= MIME-Version: 1.0 Received: by 10.239.158.193 with SMTP id v1mr557140hbc.114.1279698966071; Wed, 21 Jul 2010 00:56:06 -0700 (PDT) Received: by 10.239.158.68 with HTTP; Wed, 21 Jul 2010 00:56:05 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> Date: Wed, 21 Jul 2010 09:56:05 +0200 Message-ID: From: Simone Bordet To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 07:55:51 -0000 On Wed, Jul 21, 2010 at 02:16, Roberto Peon wrote: > On Tue, Jul 20, 2010 at 5:11 PM, Greg Wilkins wrote: >> On 21 July 2010 09:22, Scott Ferguson wrote: >>> Mike Belshe wrote: >>>> >>>> For as adamantly as Ian states that it should be a requirement, I am >>>> just as adamant that it should not. >>>> >>>> Every protocol expert I've spoken with agrees that amateur protocol >>>> implementors should not be a requirement. >>>> >>>> Is there some way we can vote to either keep or nullify this requireme= nt >>>> now and never come back to it again? =C2=A0I'm tired of this obstacle = holding >>>> everything up. >>> +1 >> +1 > yes, please. +1. +1 as well. Simon --=20 http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless.=C2=A0=C2=A0 Victoria Livschi= tz From L.Wood@surrey.ac.uk Wed Jul 21 01:01:37 2010 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 2784B3A6965 for ; Wed, 21 Jul 2010 01:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 OB1CpIuyHW0G for ; Wed, 21 Jul 2010 01:01:35 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id A20E83A6B63 for ; Wed, 21 Jul 2010 01:01:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-78.messagelabs.com!1279699309!20762151!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 7664 invoked from network); 21 Jul 2010 08:01:49 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-5.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jul 2010 08:01:49 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 21 Jul 2010 09:01:49 +0100 From: To: , Date: Wed, 21 Jul 2010 09:01:47 +0100 Thread-Topic: [hybi] HyBi WG update Thread-Index: AcsopPLdl1/S3fMUQ7m5QOmPmJrTcwABXAZg Message-ID: References: <4C1F3F93.2020805@ericsson.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hybi@ietf.org Subject: Re: [hybi] HyBi WG update 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, 21 Jul 2010 08:01:37 -0000 You don't need implementers implementing from the latest revision of the dr= aft. You need implementers implementing from a _considered_ version of the draft= , and a fixed referencable point at that. On the author's note: We've already discussed not promoting discussion on W= HATWG. This is an IETF draft; all discussion needs to be on hybi. Are you n= ot following IETF list discussion except in sporadic bursts? -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Ian= Hickson Sent: 21 July 2010 08:19 To: Salvatore Loreto Cc: hybi@ietf.org Subject: Re: [hybi] HyBi WG update On Mon, 21 Jun 2010, Salvatore Loreto wrote: > > The 00 version Ian Hickson has update contains in the Abstract=20 > section, the following note: >=20 > NOTE! THIS COPY OF THIS DOCUMENT IS OBSOLETE. >=20 > For an up-to-date copy of this specification, please see: > > http://www.whatwg.org/specs/web-socket-protocol/ > =20 > this note is against the IETF common practice, so we invite Ian to remove= it. The note is there because Joe requested that I not update the IETF copy as = often as the WHATWG copy. I need implementors looking at the latest version= of the draft. I don't really mind if they look at the HTML copy on the WHA= TWG site (part of the Web Apps 1.0 draft), the text copy on the WHATWG site= , or the text copy on the IETF site, so long as what they look at is up to = date. Should I resume sending updates to the IETF draft as I make them? > If the authors that want to make available proposed changes that=20 > aren't yet in a published ID then the canonical approach would be to=20 > keep the "current edits" version on tools.ietf.org in the WG's=20 > Subversion repository (both as xml source and txt) : > http://svn.tools.ietf.org/svn/wg/hybi/ Is there a reference anywhere that explains how to get an account there?=20 I'd be happy to update my scripts to also upload a copy there. If we can ho= st the latest copy of the spec there I'm more than happy to change the link= in the note at the top to point to that draft instead, if that would make = everyone at the IETF less nervous. > We also invite Ian to remove the following Author's note section [...] For why? --=20 Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From simone.bordet@gmail.com Wed Jul 21 01:06:58 2010 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 CDEFF3A681E for ; Wed, 21 Jul 2010 01:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 e9sp5mJTqATa for ; Wed, 21 Jul 2010 01:06:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 55ECB3A6B66 for ; Wed, 21 Jul 2010 01:06:57 -0700 (PDT) Received: by fxm1 with SMTP id 1so3673750fxm.31 for ; Wed, 21 Jul 2010 01:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cSECXU6UQhpGAVRlpG+rslHgk4iVgnplJmXISDIwLqg=; b=jcWeJF+4t8iMjS/j3UuHxQmomNJk5WZitDF8IzmIOS5141xdm+Cpomp5KGc4tpBnAe ajzxQ7f7z6nUZ85jODiLgXD0laJ0JoHt1WL3VMESEAfFzGwi2/tdG0/n9TjyvC8mThvu du7u0gxRWcY2JTTZRjsdHCzWkSeBjEGMgUuRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iJL7gXFInQAaxwd8oBCujbTy1hyu+5GM7mALvetEWw21+1S9De9sXOjbHVax9J8Zyx b7kDqIJa6adW6af5gkhun59Ev++Q23dBw7u6l4j3/V8SOmOGR6WQGxJefzDEftOhHlfG qlaPV/jhlwNw/5Q1FAGxWkoZnGjcAtb8780z0= MIME-Version: 1.0 Received: by 10.239.144.140 with SMTP id o12mr531860hba.119.1279699632754; Wed, 21 Jul 2010 01:07:12 -0700 (PDT) Received: by 10.239.158.68 with HTTP; Wed, 21 Jul 2010 01:07:12 -0700 (PDT) In-Reply-To: References: <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <20100721005038.GA27243@shareable.org> Date: Wed, 21 Jul 2010 10:07:12 +0200 Message-ID: From: Simone Bordet To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 08:06:58 -0000 Hi, On Wed, Jul 21, 2010 at 07:37, Roberto Peon wrote: > I have some experience with dealing with broken HTTP client implementatio= ns > in nearly-impossible-to-update devices such as televisions, phones, etc. > We're starting from scratch, so hopefully we won't have the confusion of > poor implementations that HTTP does, but I'd end up really sad if I had t= o > make my server not use advanced features of a *new* protocol because some > clients identify their=C2=A0capabilities=C2=A0wrongly. > Yes, we've had to do this. It is really, really, painful. > To be clear: I'm not motivated to make it possible for amateurs to make > servers or clients. > I am motivated to ensure that the protocol *just* complex enough to do wh= at > we want, and otherwise as simple and unambiguous as possible. > If that enables "amateur programmers" to write clients or servers that sp= eak > a subset of the protocol... great! > If not, hopefully they can hack on a reference implementation! > I strongly hope that we'll end up with a 100% functional reference > implementation that we publish with the spec. > I also strongly hope that we'll end up with a conformance suite (as a res= ult > of creating the reference implementation). I could not have said it better. Why cannot "amateur programmers" be exposed to WebSocket via an API that is a higher level API than the socket API ? This is already the way it is done in JavaScript where "amateur programmers" do not need to care about HTTP headers during handshake, nor to add 0x00 and 0xFF at start and end of their string messages. The same can be offered on server side, making it easy for "amateur programmers", but allowing the protocol to gain all the features discussed. I would stretch my luck even further and bet that even if an API will not be designed for server-side, it will be eventually written, and that "amateur programmers" will use that API in their applications rather than dealing with sockets and having to read the protocol spec to understand what to read/write from the socket streams. Simon --=20 http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless.=C2=A0=C2=A0 Victoria Livschi= tz From mjs@apple.com Wed Jul 21 02:13:39 2010 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 D7C583A6A04 for ; Wed, 21 Jul 2010 02:13:39 -0700 (PDT) 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 GP71grjTZRjZ for ; Wed, 21 Jul 2010 02:13:39 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 17E663A6A6C for ; Wed, 21 Jul 2010 02:13:39 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 74CD99EB6AA1 for ; Wed, 21 Jul 2010 02:13:55 -0700 (PDT) X-AuditID: 1180711d-b7b98ae000002f4b-84-4c46ba536684 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 3B.4C.12107.35AB64C4; Wed, 21 Jul 2010 02:13:55 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Received: from [10.0.1.5] (c-69-181-42-237.hsd1.ca.comcast.net [69.181.42.237]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5W00JLWHN66V30@gertie.apple.com> for hybi@ietf.org; Wed, 21 Jul 2010 02:13:55 -0700 (PDT) From: Maciej Stachowiak In-reply-to: <4C468EAE.4050507@gmx.de> Date: Wed, 21 Jul 2010 02:13:54 -0700 Content-transfer-encoding: quoted-printable Message-id: <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 09:13:39 -0000 On Jul 20, 2010, at 11:07 PM, Julian Reschke wrote: > On 21.07.2010 02:01, Maciej Stachowiak wrote: >> ... >> Also, in practice it does not seem to be the case that intermediaries >> are updated faster than clients or servers. One of the challenges to >> deploying new protocols or protocol features is old intermediaries = that >> are not updated. >> ... >=20 > The same has been said about clients (IE6) and servers (Apache httpd = prior to implementing DefaultType None) just within a week :-) I can't say for sure which has the fastest rate of being updated, I just = reject the premise that intermediaries are in general updated faster to = a significant degree. HTTP pipelining is a clear example of a feature = that is largely blocked by intermediaries not being updated enough. When = a protocol feature requires client or serve updates, then often it can = be deployed incrementally when only a subset of clients or servers is = updated, since they can come up with a way to signal to each other. = However, if it is possible for intermediaries to get in the chain = completely transparently, without any way for the client or server to = know they exist, then it's quite difficult, perhaps impossible to come = up with a reliable signal. In my opinion, to the extent we support = intermediaries, the design should require at least one of the client or = server to be explicitly aware of the intermediary. We should not support = magical transparent intermediaries where neither the client nor server = has an obvious way to detect its existence; in fact we should design the = protocol to prevent such intermediaries from being created. Regards, Maciej From L.Wood@surrey.ac.uk Wed Jul 21 02:15:38 2010 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 808913A699C for ; Wed, 21 Jul 2010 02:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 dv0nfnpbkiDl for ; Wed, 21 Jul 2010 02:15:37 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id C61223A6907 for ; Wed, 21 Jul 2010 02:15:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-72.messagelabs.com!1279703749!4357272!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 26266 invoked from network); 21 Jul 2010 09:15:49 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-12.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jul 2010 09:15:49 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 21 Jul 2010 10:15:49 +0100 From: To: , Date: Wed, 21 Jul 2010 10:15:47 +0100 Thread-Topic: [hybi] New editors? Thread-Index: AcslQz6M2NPCu4eQR8CBZNEKLmFZHQDcgrig Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] New editors? 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, 21 Jul 2010 09:15:38 -0000 +1=20 -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gre= g Wilkins Sent: 17 July 2010 01:02 To: hybi@ietf.org Subject: [hybi] New editors? All, Have the editors of the requirements and protocol documents opted out of th= is working group? I believe the deadlines for drafts for the next meeting has already been pa= ssed, so that we will be going to the next meeting with exactly the same re= quirements and protocol specification that we took to the last meeting (exc= ept one has been renamed ietf-00 instead of hixie-76). So zero progress has been made. And we will continue to do so while we hav= e partisan and/or inactive editors. At the next meeting, under the topic: "Way of working, how to measure cons= ensus, drafts ownership" I strongly urge those that attend the meeting to = consider appointing new editors who will actually engage in this process. If anybody reading wants to contribute to the process and feels that they c= an speak in moderately neutral voice, then please consider volunteering to = be an editor of these drafts. regards _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From w@1wt.eu Wed Jul 21 05:20:52 2010 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 3F6B23A67ED for ; Wed, 21 Jul 2010 05:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.743 X-Spam-Level: X-Spam-Status: No, score=-3.743 tagged_above=-999 required=5 tests=[AWL=-1.700, 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 YL8PV7jeRj1z for ; Wed, 21 Jul 2010 05:20:51 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 0480C3A67B7 for ; Wed, 21 Jul 2010 05:20:50 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LCL1LK001375; Wed, 21 Jul 2010 14:21:01 +0200 Date: Wed, 21 Jul 2010 14:21:01 +0200 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20100721122101.GA1194@1wt.eu> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 12:20:52 -0000 On Wed, Jul 21, 2010 at 02:13:54AM -0700, Maciej Stachowiak wrote: > HTTP pipelining is a clear example of a feature that is largely blocked by intermediaries not being updated enough. It's not always a matter of not being "updated enough", but a matter of "not always being implementable at all at a reasonable cost". Supporting pipelining on intermediaries can require a very complex software architecture with complex resource management to support multiple requests in flight, sometimes for little added value. What is important though is that pipelined requests all get processed in the correct order just as if they were not pipelined. But are their still that many products that are incompatible with pipelining ? > When a protocol feature requires client or serve updates, then often it can be deployed incrementally when only a subset of clients or servers is updated, since they can come up with a way to signal to each other. This is what was done with early WS implementations and multiple client and server implementations have existed, BTW. > However, if it is possible for intermediaries to get in the chain completely transparently, without any way for the client or server to know they exist, then it's quite difficult, perhaps impossible to come up with a reliable signal. In my opinion, to the extent we support intermediaries, the design should require at least one of the client or server to be explicitly aware of the intermediary. Not necessarily, if we rely on standards and the intermediaries support those standards, there is no need for the ends to know about them. Neither your client nor your servers are aware of the number of routers and firewalls in the chain because the service they offer relies on well established standards and they act transparently. The same must be true with intermediaries here. By using a standard HTTP handshake, standard-compliant intermediaries can work without either of the client or server being aware of it. But if we use non-standard derivative of well-established standards, of course we're impacted a lot by standard-compliant intermediaries. > We should not support magical transparent intermediaries where neither the client nor server has > an obvious way to detect its existence; in fact we should design the protocol to prevent such intermediaries from being created. I disagree here. Intermediaries will be created whatever efforts you put to try to make them fail. They will exist because people who deploy them need them, and the quality of their implementation is no problem for them. The dirtier we proceed, the uglier they will look like and the poorest the resulting quality of service for the client. There must not be "magical transparent intermediaries", there must be some natural and implicit support for standard-compliant intermediaries so that any new requirement can happen within a standard, and involves no "magics". Regards, Willy From mjs@apple.com Wed Jul 21 05:33:35 2010 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 960EF3A69CA for ; Wed, 21 Jul 2010 05:33:35 -0700 (PDT) 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=[AWL=0.001, 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 w0zpZ3uCCwqv for ; Wed, 21 Jul 2010 05:33:34 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 454BA3A69A4 for ; Wed, 21 Jul 2010 05:33:34 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 9EC89A479EAF for ; Wed, 21 Jul 2010 05:33:50 -0700 (PDT) X-AuditID: 1180711d-b7b98ae000002f4b-70-4c46e92ed842 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id D3.58.12107.E29E64C4; Wed, 21 Jul 2010 05:33:50 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.151.79.117] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5W00J8XQWD6T40@gertie.apple.com> for hybi@ietf.org; Wed, 21 Jul 2010 05:33:50 -0700 (PDT) From: Maciej Stachowiak In-reply-to: <20100721122101.GA1194@1wt.eu> Date: Wed, 21 Jul 2010 05:33:49 -0700 Message-id: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> <20100721122101.GA1194@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 12:33:35 -0000 On Jul 21, 2010, at 5:21 AM, Willy Tarreau wrote: > > Not necessarily, if we rely on standards and the intermediaries support those > standards, there is no need for the ends to know about them. Neither your > client nor your servers are aware of the number of routers and firewalls > in the chain because the service they offer relies on well established > standards and they act transparently. Yes, but the core protocols of the Internet (IP, TCP, UDP, ICMP, etc) have update time scales on the order of decades. Even with exhaustion of the address space staring us down, rolling out IPv6 is a massive engineering undertaking. And indeed, if you try to use IPv6 on your home network today, it will matter to you whether the intermediaries between you and your other endpoint support it. The bottom line is this: if you allow intermediaries to participate without the explicit knowledge of either endpoint, it may take decades to roll out significant protocol changes. All communication will be reduced to the least common denominator of the worst-behaving intermediaries. That may be a cost worth bearing for low-level protocols, but it is completely unacceptable for an application-level protocol in an area of high innovation. > The same must be true with intermediaries > here. By using a standard HTTP handshake, standard-compliant intermediaries > can work without either of the client or server being aware of it. And likewise they can (and apparently often will) fail without either the client or the server being aware of it. This mistake has already been made with HTTP, let's learn from it instead of repeating it. > >> We should not support magical transparent intermediaries where neither the client nor server has >> an obvious way to detect its existence; in fact we should design the protocol to prevent such intermediaries from being created. > > I disagree here. Intermediaries will be created whatever efforts you put to > try to make them fail. They will exist because people who deploy them need > them, and the quality of their implementation is no problem for them. That's exactly the problem - low-quality intermediaries are not a problem for the people running them, but they create global negative externalities. Regards, Maciej From trac@tools.ietf.org Wed Jul 21 07:12:26 2010 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 2347F3A680E for ; Wed, 21 Jul 2010 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 CS6qxivWIM5r for ; Wed, 21 Jul 2010 07:12:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6C0963A6B06 for ; Wed, 21 Jul 2010 07:12:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oba2J-0005BM-RY; Wed, 21 Jul 2010 07:12:39 -0700 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: salvatore.loreto@ericsson.com X-Trac-Project: hybi Date: Wed, 21 Jul 2010 14:12:39 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/hybi/trac/ticket/11 Message-ID: <068.9a702b733fada764f0c9ab57e96004d9@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: salvatore.loreto@ericsson.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: [hybi] #11: Amateur Programmer requirement 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: Wed, 21 Jul 2010 14:12:26 -0000 #11: Amateur Programmer requirement -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: websocket-requirements | Version: Severity: - | Keywords: -------------------------------------------+-------------------------------- simplicity is a design goal (so that it should be possible and easy for "amateur programmers" to write clients or servers that speak a subset of the protocol), but it's not an overriding constraint. check the thread: http://www.ietf.org/mail- archive/web/hybi/current/msg02214.html -- 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 jat@google.com Wed Jul 21 07:15:49 2010 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 291A73A67D1 for ; Wed, 21 Jul 2010 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 0FRmGNKsc4tx for ; Wed, 21 Jul 2010 07:15:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CDC863A680E for ; Wed, 21 Jul 2010 07:15:47 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o6LEG3RF001875 for ; Wed, 21 Jul 2010 07:16:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279721763; bh=oZGSoYBKvPUy49MfpTh056489zI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ys4uvCrh6zcfoqwwdKi6k3wQbEEAblZurGyei/NB/UYEITEWOiMRapzyiRgHyqAje y9lRVPbWZVaNSp3TsuiXQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Ifv+EcC2H2dbF3aItJA492EBuIC/GC+JvhW/hm0PX3E4P6V5JsCkzFX3kNxN+bAuo 0IQC+6FayDxYLnpMbphiw== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by wpaz1.hot.corp.google.com with ESMTP id o6LEG2KP023656 for ; Wed, 21 Jul 2010 07:16:02 -0700 Received: by gxk7 with SMTP id 7so5676387gxk.35 for ; Wed, 21 Jul 2010 07:16:02 -0700 (PDT) Received: by 10.150.173.35 with SMTP id v35mr1939532ybe.364.1279721762314; Wed, 21 Jul 2010 07:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.60.3 with HTTP; Wed, 21 Jul 2010 07:15:42 -0700 (PDT) In-Reply-To: References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> From: John Tamplin Date: Wed, 21 Jul 2010 10:15:42 -0400 Message-ID: To: Maciej Stachowiak Content-Type: multipart/alternative; boundary=000e0cd571c40dda9e048be67163 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 14:15:49 -0000 --000e0cd571c40dda9e048be67163 Content-Type: text/plain; charset=UTF-8 On Mon, May 17, 2010 at 5:29 AM, Maciej Stachowiak wrote: > Ian has claimed that the extra bytes after the request help WebSocket fail > early in the face of unaware proxies, though we do not yet have data showing > this to be the case. We do know that without this, often the handshake will > appear to succeed but transmitting messages will fail, for the network > setups of many users. > > I don't think anyone has indicated a practical problem caused by the extra > bytes. > I believe we have already had a real-world practical case where they did cause a problem: - client sends WebSocket request that goes through a proxy, random bytes are not advertised in the Content-length - proxy doesn't know WebSocket, passes along connection to real server which does implement WebSocket - server waits reading random bytes which were not forwarded - server drops the connection after a timeout Thus the random bytes did succeed in preventing a WebSocket connection across a non-WS compliant proxy, but: 1. the proxy was actually capable of forwarding the connection if the server had completed the request 2. we had to wait for a timeout, so this was not a fast-fail situation 3. the same thing could have been more easily accomplished by having a WS control frame exchanged at startup with similar results without non-compliant random bytes on the wire -- John A. Tamplin Software Engineer (GWT), Google --000e0cd571c40dda9e048be67163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 17, 2010 at 5:29 AM, Maciej Stachowi= ak <mjs@apple.com= > wrote:
Ian has claimed that the extra bytes after the request he= lp WebSocket fail early in the face of unaware proxies, though we do not ye= t have data showing this to be the case. We do know that without this, ofte= n the handshake will appear to succeed but transmitting messages will fail,= for the network setups of many users.

I don't think anyone has indicated a practical problem caused by the ex= tra bytes.

I believe we have already ha= d a real-world practical case where they did cause a problem:
  • client sends WebSocket request that goes through a proxy, random by= tes are not advertised in the Content-length
  • proxy doesn't know= WebSocket, passes along connection to real server which does implement Web= Socket
  • server waits reading random bytes which were not forwarded
  • serv= er drops the connection after a timeout
Thus the random bytes= did succeed in preventing a WebSocket connection across a non-WS compliant= proxy, but:
  1. the proxy was actually capable of forwarding the connection if= the server had completed the request
  2. we had to wait for a timeout,= so this was not a fast-fail situation
  3. the same thing could have be= en more easily accomplished by having a WS control frame exchanged at start= up with similar results without non-compliant random bytes on the wire
--
John A. Tamplin
Software Engineer (GWT), G= oogle
--000e0cd571c40dda9e048be67163-- From jat@google.com Wed Jul 21 07:27:45 2010 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 BF5E43A6AF1 for ; Wed, 21 Jul 2010 07:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 fS80WJFVSkQB for ; Wed, 21 Jul 2010 07:27:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A5E383A6A25 for ; Wed, 21 Jul 2010 07:27:43 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o6LERxPd023592 for ; Wed, 21 Jul 2010 07:27:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279722479; bh=51EO82Ah7pwyRcigsIS0M09HGoM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Nrj/LVhTVL75DEgSEsAjmB9GP9BuVwLnUGErnf+lP7irf80tXxwg7GEp2jtU40ScD RHeXDv9+E67WTrdLVrD5g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=mH2q/KMyUZ0ht9i+1hi2iwyCL++8GCxkwjDex8NlD3uyYENJwx1aq7nsHUVcBlYKN 7b7jh1jQDzaXvuR41Lkeg== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq2.eem.corp.google.com with ESMTP id o6LERv09009488 for ; Wed, 21 Jul 2010 07:27:57 -0700 Received: by gwb11 with SMTP id 11so3698452gwb.15 for ; Wed, 21 Jul 2010 07:27:57 -0700 (PDT) Received: by 10.150.113.15 with SMTP id l15mr2092358ybc.290.1279722477175; Wed, 21 Jul 2010 07:27:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.60.3 with HTTP; Wed, 21 Jul 2010 07:27:37 -0700 (PDT) In-Reply-To: References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF11920.2080307@webtide.com> <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> From: John Tamplin Date: Wed, 21 Jul 2010 10:27:37 -0400 Message-ID: To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd5cfe2a9c3ee048be69b32 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 14:27:45 -0000 --000e0cd5cfe2a9c3ee048be69b32 Content-Type: text/plain; charset=UTF-8 On Tue, May 18, 2010 at 5:16 PM, Ian Hickson wrote: > On Tue, 18 May 2010, Greg Wilkins wrote: > > > > If the handshake is HTTP compliant, then the connection for a websocket > > handshake could be taken from the existing pool of idle connections to a > > host. That would save the time needed to establish the connection. > > The resemblence to HTTP is nothing more than a hack to alolow us to share > ports in certain advanced scenarios. Most Web Socket servers will know > nothing about HTTP. I disagree completely -- there is going to be a web server involved in delivering the web application, and I think the more usual scenario is that web server also implements the WebSocket server. Why would someone prefer to deploy two servers rather than one, except in the case where their web server doesn't yet support WebSocket? If this protocol is successful, over time that will drop to 0. > Reusing connections is a level of complexity that is > completely unwarranted and that would only be useful in the rarest of > cases. It's a proposal that lies on completely the wrong side of the 80/20 > line and would introduce _massive_ complexity for authors, who would have > no idea why their WebSocket servers were suddenly receiving random HTTP > requests and vice versa. I'm not sold on connection reuse, but I am not sure where these random HTTP requests would be coming from. If a connection was to ws://foo.org/socket, the connection was closed, and then another connection was needed for http://foo.org/image.gif, presumably the server at foo.org:80 is capable of answering either request since it would have had to handle either request on a new connection. If instead it was ws://socket.foo.org/socket, then obviously that connection would not be used to reach www.foo.org. I'm not sure that adding connection keep-alive and/or restarting the handshake is justified by the benefits, but I don't see where your argument comes from. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5cfe2a9c3ee048be69b32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 18, 2010 at 5:16 PM, Ian Hickson <ian@hixie.ch> wrote:
On Tue, 18 May 2010, Greg Wilkins wrote:
>
> If the handshake is HTTP compliant, then the connection for a websocke= t
> handshake could be taken from the existing pool of idle connections to= a
> host. =C2=A0That would save the time needed to establish the connectio= n.

The resemblence to HTTP is nothing more than a hack to alolow us to s= hare
ports in certain advanced scenarios. Most Web Socket servers will know
nothing about HTTP.

I disagree completely -= - there is going to be a web server involved in delivering the web applicat= ion, and I think the more usual scenario is that web server also implements= the WebSocket server. =C2=A0Why would someone prefer to deploy two servers= rather than one, except in the case where their web server doesn't yet= support WebSocket? =C2=A0If this protocol is successful, over time that wi= ll drop to 0.
=C2=A0
Reusing connections is a = level of complexity that is
completely unwarranted and that would only be useful in the rarest of
cases. It's a proposal that lies on completely the wrong side of the 80= /20
line and would introduce _massive_ complexity for authors, who would have no idea why their WebSocket servers were suddenly receiving random HTTP
requests and vice versa.

I'm not sold o= n connection reuse, but I am not sure where these random HTTP requests woul= d be coming from. =C2=A0If a connection was to ws://foo.org/socket, the connection was closed, and then another = connection was needed for http://foo.o= rg/image.gif, presumably the server at fo= o.org:80 is capable of answering either request since it would have had= to handle either request on a new connection. =C2=A0If instead it was ws:/= /socket.foo.org/socket, then o= bviously that connection would not be used to reach www.foo.org.

I'm not sure that adding connection keep-alive and/= or restarting the handshake is justified by the benefits, but I don't s= ee where your argument comes from.

--
John A.= Tamplin
Software Engineer (GWT), Google
--000e0cd5cfe2a9c3ee048be69b32-- From w@1wt.eu Wed Jul 21 07:34:40 2010 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 E9F2D3A67EB for ; Wed, 21 Jul 2010 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-1.723, 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 qqdZyYjsecyE for ; Wed, 21 Jul 2010 07:34:39 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DE1743A687A for ; Wed, 21 Jul 2010 07:34:36 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LEYiEh002626; Wed, 21 Jul 2010 16:34:44 +0200 Date: Wed, 21 Jul 2010 16:34:44 +0200 From: Willy Tarreau To: John Tamplin Message-ID: <20100721143444.GA2598@1wt.eu> References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> 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: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 14:34:40 -0000 On Wed, Jul 21, 2010 at 10:15:42AM -0400, John Tamplin wrote: > > I don't think anyone has indicated a practical problem caused by the extra > > bytes. > > > > I believe we have already had a real-world practical case where they did > cause a problem: > > - client sends WebSocket request that goes through a proxy, random bytes > are not advertised in the Content-length > - proxy doesn't know WebSocket, passes along connection to real server > which does implement WebSocket > - server waits reading random bytes which were not forwarded > - server drops the connection after a timeout Confirmed. And it will fail with any HTTP reverse-proxy. And if you manage to make an HTTP reverse-proxy work with the current scheme, then this rev-proxy can be tricked by the client into sending uncontrolled requests to the server (by just setting the "Upgrade" option that the server will ignore). > Thus the random bytes did succeed in preventing a WebSocket connection > across a non-WS compliant proxy, but: > > 1. the proxy was actually capable of forwarding the connection if the > server had completed the request > 2. we had to wait for a timeout, so this was not a fast-fail situation > 3. the same thing could have been more easily accomplished by having a WS > control frame exchanged at startup with similar results without > non-compliant random bytes on the wire And it would have worked without requiring any change to deployed components. Regards, Willy From fenix@google.com Wed Jul 21 07:42:52 2010 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 506FE3A6826 for ; Wed, 21 Jul 2010 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 l8OPrtHwJ8UG for ; Wed, 21 Jul 2010 07:42:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7BC693A67D1 for ; Wed, 21 Jul 2010 07:42:49 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o6LEh54a010978 for ; Wed, 21 Jul 2010 07:43:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279723385; bh=pw3h70ai98Qd5oL/os1ukyeVoxU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=uH+m4SdZqFwl2NBT6W1oR2X/ghfPZSKc99aRA9Ii6NNTsrG+u2/5se7tUoYkora5g b0ZbRBqMpXfLZ8U8e/9AA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=VH4GVfnAf7yw5qc88dmToU4Ro/gzQUdSAPVKRXNqqYF2YlpPhg+NiRGvZ/n6MrlQK SKWWC13Z6iRWvf2A6wlmg== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by wpaz33.hot.corp.google.com with ESMTP id o6LEh4kf011886 for ; Wed, 21 Jul 2010 07:43:05 -0700 Received: by gwaa12 with SMTP id a12so3430462gwa.22 for ; Wed, 21 Jul 2010 07:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.136.4 with SMTP id j4mr545610ybd.356.1279723384155; Wed, 21 Jul 2010 07:43:04 -0700 (PDT) Received: by 10.150.59.4 with HTTP; Wed, 21 Jul 2010 07:43:03 -0700 (PDT) In-Reply-To: References: <4BF11920.2080307@webtide.com> <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> Date: Wed, 21 Jul 2010 07:43:03 -0700 Message-ID: From: Roberto Peon To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd56a84b92f12048be6d183 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 14:42:52 -0000 --000e0cd56a84b92f12048be6d183 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 11:47 PM, Ian Hickson wrote: > On Wed, 19 May 2010, Jamie Lokier wrote: > > > > > > If we want to support multiple subprotocols at once, we can do so > > > quite easily by just making the subprotocol list be comma-separated. > > > Would this be a good idea? > > > > I think it is a good idea, although there is a risk of low-quality > > server but significant implementations matching a literal string, > > breaking when other values are added to the comma-separate list, and > > therefore making it impossible for clients to actually use the > > capability. > > Yeah, though since that bug would be specific to implementations of > particular subprotocols, it would be pretty localised to individual > communities. That's probably an acceptable problem. > > I've added this to the spec for now. > > http://html5.org/tools/web-apps-tracker?from=5172&to=5173 > > > > But assuming the comma-separated list did catch on, a consequence of > > that would be the "below the API" part of WebSocket would have a place > > to add its own distinct entries to the comma-separated list, for > > recognition by the other side as transport option requests (such as > > compression, etc.), safe in the knowledge it wouldn't break negotiation. > > > > (Separate headers would be much cleaner for that, though). > > I don't see why we wouldn't just use separate fields for that. No need to > overload the subprotocol field. > > > > > > - Trying a HTTP-based protocol if WebSocket is unavailable (ditto) > > > > > > That wouldn't work anyway because the WebSocket object isn't the same > > > object as the XMLHttpRequest object and they therefore create entirely > > > different connections. > > > > Just being different objects is not technical reason for different > > connections. Separate XMLHttpRequest objects have no problem sharing > > connections. There is no technical reason why a WebSocket object could > > not do the same, just as easily. Especially in browsers which routinely > > do this! > > I guess. I'm not convinced it's a good idea though. > > > > > In any case, why wouldn't you know that Web Socket is available? I > > > don't understand why you would guess that it is and then find it > > > isn't. You need a URL to connect to a Web Socket, why would you make > > > up a URL without knowing whether it'll work? > > > > Earlier in this thread, in a reply to you, we already gave an example. > > It was the social networking client that talks to numerous de facto > > standardised but different WebSocket protocols that the user shouldn't > > have to know about. > > > > Basically because autonegotiation is more user-friendly, both in terms > > of users having to be given and enter fewer details, and in terms of > > telling the user what went wrong if things didn't work out. > > > > As you noted, people don't always pass around URLs - they often pass > > around just a domain name, or a truncated URL that doesn't include the > > "http:" prefix. > > > > I would agree if it were _complicated_ to do, but we are talking about > > really trivial stuff here. Trying one thing, then trying another, is > > already handled by the handshake, and it is utterly trivial to do from a > > script. It's so easy that it's hard to see why any random web developer > > wouldn't use it whenever it seemed like a good idea. > > > > It seems obvious to me that countless Javascripts will do exactly that. > > I could see trying multiple WebSocket protocols over one connection, but > trying to try both HTTP or WebSocket connections, not to mention any other > protocols the servers might provide, seems like massive complexity for > negligible gain overall. > > I fully expect that we'll end up with multiple websocket "sockets" per tab, and we typically end up with many tabs. This is true even if going to only one large site. For instance, it is fairly normal to have both corporate and personal email and calendering open at all times. If each websocket is its own TCP socket, we'll face a drastic increase in the number of connections from everyone. Worse, these connections won't go away, they'll send junk bytes all the time (keep alives), they'll be unable to go to the same server if one is using loadbalancing, they'll have more than an order of magnitude greater chance to overload NAT tables, they'll make DST caches in the kernel less effective due to dilution (for smaller servers), etc. Each and every of these is a good reason that the complexity is warranted. I have some "small" experience with ensuring that things can serve at-scale. There are very good reasons that I'm concerned about websocket scalability. As for complexity! At worst, you have flow control and multiplexing. Multiplexing involves a unique ID per channel. Flow control involves sending periodic updates telling the other side how much it can send safely. Of course you also need to have a table in which you do a lookup to see that there is already a connection for that domain, including a reference to that connection. None of this is difficult, even in concert. -=R > > > > This can be supported entirely in Web Socket if we want to do that. > > > Currently, it's not clear that supporting this is even desireable, due > > > to the UI issues with doing so. > > > > (On that topic, how do you propose to get through a proxy on port 443 > > that needs proxy authentication before it passes a CONNECT request?) > > I guess the UA would have to use the existing (suboptimal) UI for proxy > auth. It's not a good situation to be in; I wouldn't recommend it. > > > > > WebSocket and HTTP are different protocols. Reusing the connection > > > makes as much sense as reusing the connection of an FTP connection > > > attempt to do an HTTP connection attempt. > > > > This is different. Both WebSockets and HTTP requests are transient in > > many cases. > > FTP is more transient than WebSockets. WebSockets is intended for > connections that just stay open. It's not intended for transient use. It's > not at all designed for transient use. It will do poorly when used for > transient use. > > > > If FTP was also transient, and it shared the same port with > > HTTP, and many servers especially those designed for high performance > > implemented both together, and many clients implemented both, then of > > course it would make sense to _permit_ connection reuse between them, > > without _requiring_ any implementation to do so. > > I think it would be pretty silly even in those cases, personally. Reusing > connections amongst multiple protocols is simply asking for bugs. The > benefits are minimal and the costs are high. If you want to do multiple > things on a connection, use a protocol that supports all those things, > don't try to switch back and forth between protocols. > > (By extension, I think the Upgrade mechanism in HTTP isn't a particularly > good idea. The number of times the mechanism has been used to great > success on the Web somewhat supports my position on this, I think.) > > > > There is a much stronger case for reusing a WebSocket connection after a > > gracefully close that puts it into some kind of idle state. That's > > because users follow links every few seconds - and therefore WebSocket > > scripts in ordinary pages will connect and disconnect from the same > > server and port every few seconds in the current model. > > What use cases are you imagining that have Web Sockets used in such > scenarios? None of the intended use cases even remotely resemble this. Web > Sockets is intended for use on pages that are long-lived. It's quite > possible that there are use cases on short-lived pages also, but they > probably need their own protocol, optimised for those cases (e.g. HTTP and > the text/event-stream EventSource mechanism). WebSockets isn't trying to > be everything for everyone, it's just trying to address the specific use > case of trivially-implementable long-lived TCP-like connections for Web > browsers. > > > > Making it optional for both sides adds *zero* complexity for authors who > > don't do it. I am not seeing how you can think it makes any difference > > to them. > > Clients have to support it. This means implementation cost, testing cost, > and bug-fixing cost. It then propagates to documentation, which means > reference costs, tutorial costs, etc. This further means that authors will > see the feature in documentation. This leads to cognition costs when > learning the material, information retrieval costs when distinguishing > whether something is relevant or not when debugging, and communication > costs when discussing the feature with others, e.g. when determining > whether the feature is relevant to the question someone is asking. Then > there's the cost of maintaining code that someone else has written that > _does_ use the feature, there's the cost of debugging browser bugs when > the feature is misimplemented and interacts even with code that doesn't > use the feature, and finally there's the cost of implementing the feature > on the server side once it makes its way onto check-mark lists of features > that every web developer customer wants to support. > > > > Seriously, how do you imagine it affects them? > > Optional features are a lie. Nothing is really optional in a platform like > the Web's -- the only way a feature can be "free" is if it doesn't exist. > This is why we have to justify everything we add, and make sure it's on > the right side of the 80/20 line. > > > > > who would have no idea why their WebSocket servers were suddenly > > > receiving random HTTP requests and vice versa. > > > > That's a function of connecting to the wrong type of server already, and > > it's already dealt with by the spec'd negotation, which the wrong type > > of server handles already by design. Nothing new there. > > If we supported connection reuse and there was misconfiguration, then the > kinds of failure scenarios would be much more varied than they are now. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd56a84b92f12048be6d183 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 11:47 PM, Ian Hi= ckson <ian@hixie.ch> wrote:
On Wed, 19 May 2010, Jamie Lokier wrote:
> >
> > If we want to support multiple subprotocols at once, we can do so=
> > quite easily by just making the subprotocol list be comma-separat= ed.
> > Would this be a good idea?
>
> I think it is a good idea, although there is a risk of low-quality
> server but significant implementations matching a literal string,
> breaking when other values are added to the comma-separate list, and > therefore making it impossible for clients to actually use the
> capability.

Yeah, though since that bug would be specific to implementations of particular subprotocols, it would be pretty localised to individual
communities. That's probably an acceptable problem.

I've added this to the spec for now.

=A0
http://html5.org/tools/web-apps-tracker?from=3D5= 172&to=3D5173


> But assuming the comma-separated list did catch on, a consequence of > that would be the "below the API" part of WebSocket would ha= ve a place
> to add its own distinct entries to the comma-separated list, for
> recognition by the other side as transport option requests (such as > compression, etc.), safe in the knowledge it wouldn't break negoti= ation.
>
> (Separate headers would be much cleaner for that, though).

I don't see why we wouldn't just use separate fields for that= . No need to
overload the subprotocol field.


> > > =A0 =A0- Trying a HTTP-based protocol if WebSocket is unavai= lable (ditto)
> >
> > That wouldn't work anyway because the WebSocket object isn= 9;t the same
> > object as the XMLHttpRequest object and they therefore create ent= irely
> > different connections.
>
> Just being different objects is not technical reason for different
> connections. Separate XMLHttpRequest objects have no problem sharing > connections. There is no technical reason why a WebSocket object could=
> not do the same, just as easily. =A0Especially in browsers which routi= nely
> do this!

I guess. I'm not convinced it's a good idea though.


> > In any case, why wouldn't you know that Web Socket is availab= le? I
> > don't understand why you would guess that it is and then find= it
> > isn't. You need a URL to connect to a Web Socket, why would y= ou make
> > up a URL without knowing whether it'll work?
>
> Earlier in this thread, in a reply to you, we already gave an example.=
> It was the social networking client that talks to numerous de facto > standardised but different WebSocket protocols that the user shouldn&#= 39;t
> have to know about.
>
> Basically because autonegotiation is more user-friendly, both in terms=
> of users having to be given and enter fewer details, and in terms of > telling the user what went wrong if things didn't work out.
>
> As you noted, people don't always pass around URLs - they often pa= ss
> around just a domain name, or a truncated URL that doesn't include= the
> "http:" prefix.
>
> I would agree if it were _complicated_ to do, but we are talking about=
> really trivial stuff here. =A0Trying one thing, then trying another, i= s
> already handled by the handshake, and it is utterly trivial to do from= a
> script. =A0It's so easy that it's hard to see why any random w= eb developer
> wouldn't use it whenever it seemed like a good idea.
>
> It seems obvious to me that countless Javascripts will do exactly that= .

I could see trying multiple WebSocket protocols over one connection, = but
trying to try both HTTP or WebSocket connections, not to mention any other<= br> protocols the servers might provide, seems like massive complexity for
negligible gain overall.


I fully expect= that we'll end up with multiple websocket "sockets" per tab,= and we typically end up with many tabs.
This is true even if goi= ng to only one large site. For instance, it is fairly normal to have both c= orporate and personal email and calendering open at all times.
If each websocket is its own TCP socket, we'll face a drastic incr= ease in the number of connections from everyone.
Worse, these con= nections won't go away, they'll send junk bytes all the time (keep = alives), they'll be unable to go to the same server if one is using loa= dbalancing, they'll have more than an order of magnitude greater chance= to overload NAT tables, they'll make DST caches in the kernel less eff= ective due to dilution (for smaller servers), etc.

Each and every of these is a good reason that the compl= exity is warranted.
I have some "small" experience with= ensuring that things can serve at-scale. There are very good reasons that = I'm concerned about websocket scalability.

As for complexity! At worst, you have flow control and = multiplexing. =A0Multiplexing involves a unique ID per channel. Flow contro= l involves sending periodic updates telling the other side how much it can = send safely. Of course you also need to have a table in which you do a look= up to see that there is already a connection for that domain, including a r= eference to that=A0connection. None of this is difficult, even in concert.<= /div>

-=3DR=A0

> > This can be supported entirely in Web Socket if we want to do tha= t.
> > Currently, it's not clear that supporting this is even desire= able, due
> > to the UI issues with doing so.
>
> (On that topic, how do you propose to get through a proxy on port 443<= br> > that needs proxy authentication before it passes a CONNECT request?)
I guess the UA would have to use the existing (suboptimal) UI for pro= xy
auth. It's not a good situation to be in; I wouldn't recommend it.<= br>


> > WebSocket and HTTP are different protocols. Reusing the connectio= n
> > makes as much sense as reusing the connection of an FTP connectio= n
> > attempt to do an HTTP connection attempt.
>
> This is different. =A0Both WebSockets and HTTP requests are transient = in
> many cases.

FTP is more transient than WebSockets. WebSockets is intended for
connections that just stay open. It's not intended for transient use. I= t's
not at all designed for transient use. It will do poorly when used for
transient use.


> If FTP was also transient, and it shared the same port with
> HTTP, and many servers especially those designed for high performance<= br> > implemented both together, and many clients implemented both, then of<= br> > course it would make sense to _permit_ connection reuse between them,<= br> > without _requiring_ any implementation to do so.

I think it would be pretty silly even in those cases, personally. Reu= sing
connections amongst multiple protocols is simply asking for bugs. The
benefits are minimal and the costs are high. If you want to do multiple
things on a connection, use a protocol that supports all those things,
don't try to switch back and forth between protocols.

(By extension, I think the Upgrade mechanism in HTTP isn't a particular= ly
good idea. The number of times the mechanism has been used to great
success on the Web somewhat supports my position on this, I think.)


> There is a much stronger case for reusing a WebSocket connection after= a
> gracefully close that puts it into some kind of idle state. =A0That= 9;s
> because users follow links every few seconds - and therefore WebSocket=
> scripts in ordinary pages will connect and disconnect from the same > server and port every few seconds in the current model.

What use cases are you imagining that have Web Sockets used in such scenarios? None of the intended use cases even remotely resemble this. Web<= br> Sockets is intended for use on pages that are long-lived. It's quite possible that there are use cases on short-lived pages also, but they
probably need their own protocol, optimised for those cases (e.g. HTTP and<= br> the text/event-stream EventSource mechanism). WebSockets isn't trying t= o
be everything for everyone, it's just trying to address the specific us= e
case of trivially-implementable long-lived TCP-like connections for Web
browsers.


> Making it optional for both sides adds *zero* complexity for authors w= ho
> don't do it. I am not seeing how you can think it makes any differ= ence
> to them.

Clients have to support it. This means implementation cost, testing c= ost,
and bug-fixing cost. It then propagates to documentation, which means
reference costs, tutorial costs, etc. This further means that authors will<= br> see the feature in documentation. This leads to cognition costs when
learning the material, information retrieval costs when distinguishing
whether something is relevant or not when debugging, and communication
costs when discussing the feature with others, e.g. when determining
whether the feature is relevant to the question someone is asking. Then
there's the cost of maintaining code that someone else has written that=
_does_ use the feature, there's the cost of debugging browser bugs when=
the feature is misimplemented and interacts even with code that doesn't=
use the feature, and finally there's the cost of implementing the featu= re
on the server side once it makes its way onto check-mark lists of features<= br> that every web developer customer wants to support.


> Seriously, how do you imagine it affects them?

Optional features are a lie. Nothing is really optional in a platform= like
the Web's -- the only way a feature can be "free" is if it do= esn't exist.
This is why we have to justify everything we add, and make sure it's on=
the right side of the 80/20 line.


> > who would have no idea why their WebSocket servers were suddenly<= br> > > receiving random HTTP requests and vice versa.
>
> That's a function of connecting to the wrong type of server alread= y, and
> it's already dealt with by the spec'd negotation, which the wr= ong type
> of server handles already by design. =A0Nothing new there.

If we supported connection reuse and there was misconfiguration, then= the
kinds of failure scenarios would be much more varied than they are now.

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'
_______________________________________________

--000e0cd56a84b92f12048be6d183-- From jat@google.com Wed Jul 21 07:47:45 2010 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 40EE23A6BCD for ; Wed, 21 Jul 2010 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 39IKtv0g3NVD for ; Wed, 21 Jul 2010 07:47:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id CBBB43A6BB7 for ; Wed, 21 Jul 2010 07:47:43 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o6LElx6A020172 for ; Wed, 21 Jul 2010 07:47:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279723679; bh=RyKu4HNFVK7Dflge93cpZYwCoFE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xbfiV3iNog86PURTQ8ysY8E3MaFCZisvzNs0Kl4rVYmpv52M/x3Z6rHnXIkUe404d /Ahj819h0BSAiR40i2zBA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=uj1q4Atm+UhqKg3Mg4BMBh16bQ8nU1HzjCNs1PxgjM0zGx8AotcladQXdncvXVtdX pQ0Gge+H2w3eFPxk+XOOA== Received: from gxk25 (gxk25.prod.google.com [10.202.11.25]) by hpaq1.eem.corp.google.com with ESMTP id o6LElwvJ011984 for ; Wed, 21 Jul 2010 07:47:58 -0700 Received: by gxk25 with SMTP id 25so4212725gxk.29 for ; Wed, 21 Jul 2010 07:47:58 -0700 (PDT) Received: by 10.151.29.11 with SMTP id g11mr2056363ybj.407.1279723677917; Wed, 21 Jul 2010 07:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.60.3 with HTTP; Wed, 21 Jul 2010 07:47:37 -0700 (PDT) In-Reply-To: References: <4BF11920.2080307@webtide.com> <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> From: John Tamplin Date: Wed, 21 Jul 2010 10:47:37 -0400 Message-ID: To: Roberto Peon Content-Type: multipart/alternative; boundary=000e0cd2a1843ba306048be6e3ba X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 14:47:45 -0000 --000e0cd2a1843ba306048be6e3ba Content-Type: text/plain; charset=UTF-8 On Wed, Jul 21, 2010 at 10:43 AM, Roberto Peon wrote: > I fully expect that we'll end up with multiple websocket "sockets" per tab, > and we typically end up with many tabs. > This is true even if going to only one large site. For instance, it is > fairly normal to have both corporate and personal email and calendering open > at all times. > If each websocket is its own TCP socket, we'll face a drastic increase in > the number of connections from everyone. > Worse, these connections won't go away, they'll send junk bytes all the > time (keep alives), they'll be unable to go to the same server if one is > using loadbalancing, they'll have more than an order of magnitude greater > chance to overload NAT tables, they'll make DST caches in the kernel less > effective due to dilution (for smaller servers), etc. > > Each and every of these is a good reason that the complexity is warranted. > I have some "small" experience with ensuring that things can serve > at-scale. There are very good reasons that I'm concerned about websocket > scalability. > > As for complexity! At worst, you have flow control and multiplexing. > Multiplexing involves a unique ID per channel. Flow control involves > sending periodic updates telling the other side how much it can send safely. > Of course you also need to have a table in which you do a lookup to see that > there is already a connection for that domain, including a reference to > that connection. None of this is difficult, even in concert. > Another benefit of muxing multiple WS connections over a single TCP connection is you can have only one keep-alive for all of them. And I think WS really needs to have some keep-alive frame -- if not, then you are just pushing the requirement off to the client code using the WS, and then it won't be done consistently or in a way that can be aggregated. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd2a1843ba306048be6e3ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 21, 2010 at 10:43 AM, Roberto Peon <= span dir=3D"ltr"><fenix@google.com> wrote:
I fully expect that we'll end up with m= ultiple websocket "sockets" per tab, and we typically end up with= many tabs.
This is true even if going to only one large site. Fo= r instance, it is fairly normal to have both corporate and personal email a= nd calendering open at all times.
If each websocket is its own TCP socket, we'll face a drastic incr= ease in the number of connections from everyone.
Worse, these con= nections won't go away, they'll send junk bytes all the time (keep = alives), they'll be unable to go to the same server if one is using loa= dbalancing, they'll have more than an order of magnitude greater chance= to overload NAT tables, they'll make DST caches in the kernel less eff= ective due to dilution (for smaller servers), etc.

Each and every of these is a good reason that the compl= exity is warranted.
I have some "small" experience with= ensuring that things can serve at-scale. There are very good reasons that = I'm concerned about websocket scalability.

As for complexity! At worst, you have flow control and = multiplexing. =C2=A0Multiplexing involves a unique ID per channel. Flow con= trol involves sending periodic updates telling the other side how much it c= an send safely. Of course you also need to have a table in which you do a l= ookup to see that there is already a connection for that domain, including = a reference to that=C2=A0connection. None of this is difficult, even in con= cert.

Another benefit of muxing multiple = WS connections over a single TCP connection is you can have only one keep-a= live for all of them. =C2=A0And I think WS really needs to have some keep-a= live frame -- if not, then you are just pushing the requirement off to the = client code using the WS, and then it won't be done consistently or in = a way that can be aggregated.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd2a1843ba306048be6e3ba-- From fenix@google.com Wed Jul 21 07:54:03 2010 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 5E6303A6BD3 for ; Wed, 21 Jul 2010 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 EGJKhip3PEBY for ; Wed, 21 Jul 2010 07:54:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7C5AD3A6774 for ; Wed, 21 Jul 2010 07:54:00 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o6LEsG7d019499 for ; Wed, 21 Jul 2010 07:54:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279724056; bh=ZMWZa+toyNYFAoF94KHvk2O/aB8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rOkSoQll2Umx0EnElDNZ6YMYZyWfUTELxjdLXi7gYmvLljl0AmzDrnm0JAUIX3wni L/5k9jUU+Ivs3EzAD6FMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=aYyNDbJa/qKHSogPz62LuJYwig6boTaVyR+BHg6JkYaeLMP4MfS0gJM432C7ge1vT PG5jYbdsv0uIjLz6vMJMA== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz37.hot.corp.google.com with ESMTP id o6LErOSD017036 for ; Wed, 21 Jul 2010 07:54:15 -0700 Received: by gwj20 with SMTP id 20so3942384gwj.7 for ; Wed, 21 Jul 2010 07:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.32.2 with SMTP id f2mr2115760ybf.281.1279724054332; Wed, 21 Jul 2010 07:54:14 -0700 (PDT) Received: by 10.150.59.4 with HTTP; Wed, 21 Jul 2010 07:54:14 -0700 (PDT) In-Reply-To: References: <4BF11920.2080307@webtide.com> <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> Date: Wed, 21 Jul 2010 07:54:14 -0700 Message-ID: From: Roberto Peon To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd23ad2ab9c78048be6f9d6 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 14:54:03 -0000 --000e0cd23ad2ab9c78048be6f9d6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 20, 2010 at 11:47 PM, Ian Hickson wrote: > On Wed, 19 May 2010, Jamie Lokier wrote: > > > > > > If we want to support multiple subprotocols at once, we can do so > > > quite easily by just making the subprotocol list be comma-separated. > > > Would this be a good idea? > > > > I think it is a good idea, although there is a risk of low-quality > > server but significant implementations matching a literal string, > > breaking when other values are added to the comma-separate list, and > > therefore making it impossible for clients to actually use the > > capability. > > Yeah, though since that bug would be specific to implementations of > particular subprotocols, it would be pretty localised to individual > communities. That's probably an acceptable problem. > > I've added this to the spec for now. > > http://html5.org/tools/web-apps-tracker?from=5172&to=5173 > > > > But assuming the comma-separated list did catch on, a consequence of > > that would be the "below the API" part of WebSocket would have a place > > to add its own distinct entries to the comma-separated list, for > > recognition by the other side as transport option requests (such as > > compression, etc.), safe in the knowledge it wouldn't break negotiation. > > > > (Separate headers would be much cleaner for that, though). > > I don't see why we wouldn't just use separate fields for that. No need to > overload the subprotocol field. > > > > > > - Trying a HTTP-based protocol if WebSocket is unavailable (ditto) > > > > > > That wouldn't work anyway because the WebSocket object isn't the same > > > object as the XMLHttpRequest object and they therefore create entirely > > > different connections. > > > > Just being different objects is not technical reason for different > > connections. Separate XMLHttpRequest objects have no problem sharing > > connections. There is no technical reason why a WebSocket object could > > not do the same, just as easily. Especially in browsers which routinely > > do this! > > I guess. I'm not convinced it's a good idea though. > > > > > In any case, why wouldn't you know that Web Socket is available? I > > > don't understand why you would guess that it is and then find it > > > isn't. You need a URL to connect to a Web Socket, why would you make > > > up a URL without knowing whether it'll work? > > > > Earlier in this thread, in a reply to you, we already gave an example. > > It was the social networking client that talks to numerous de facto > > standardised but different WebSocket protocols that the user shouldn't > > have to know about. > > > > Basically because autonegotiation is more user-friendly, both in terms > > of users having to be given and enter fewer details, and in terms of > > telling the user what went wrong if things didn't work out. > > > > As you noted, people don't always pass around URLs - they often pass > > around just a domain name, or a truncated URL that doesn't include the > > "http:" prefix. > > > > I would agree if it were _complicated_ to do, but we are talking about > > really trivial stuff here. Trying one thing, then trying another, is > > already handled by the handshake, and it is utterly trivial to do from a > > script. It's so easy that it's hard to see why any random web developer > > wouldn't use it whenever it seemed like a good idea. > > > > It seems obvious to me that countless Javascripts will do exactly that. > > I could see trying multiple WebSocket protocols over one connection, but > trying to try both HTTP or WebSocket connections, not to mention any other > protocols the servers might provide, seems like massive complexity for > negligible gain overall. > > > > > This can be supported entirely in Web Socket if we want to do that. > > > Currently, it's not clear that supporting this is even desireable, due > > > to the UI issues with doing so. > > > > (On that topic, how do you propose to get through a proxy on port 443 > > that needs proxy authentication before it passes a CONNECT request?) > > I guess the UA would have to use the existing (suboptimal) UI for proxy > auth. It's not a good situation to be in; I wouldn't recommend it. > > > > > WebSocket and HTTP are different protocols. Reusing the connection > > > makes as much sense as reusing the connection of an FTP connection > > > attempt to do an HTTP connection attempt. > > > > This is different. Both WebSockets and HTTP requests are transient in > > many cases. > > FTP is more transient than WebSockets. WebSockets is intended for > connections that just stay open. It's not intended for transient use. It's > not at all designed for transient use. It will do poorly when used for > transient use. > > > > If FTP was also transient, and it shared the same port with > > HTTP, and many servers especially those designed for high performance > > implemented both together, and many clients implemented both, then of > > course it would make sense to _permit_ connection reuse between them, > > without _requiring_ any implementation to do so. > > I think it would be pretty silly even in those cases, personally. Reusing > connections amongst multiple protocols is simply asking for bugs. The > benefits are minimal and the costs are high. If you want to do multiple > things on a connection, use a protocol that supports all those things, > don't try to switch back and forth between protocols. > > (By extension, I think the Upgrade mechanism in HTTP isn't a particularly > good idea. The number of times the mechanism has been used to great > success on the Web somewhat supports my position on this, I think.) > The UPGRADE mechanism was a fine idea. Poor transparent proxy implementations have killed its effectiveness. -=R > > > > There is a much stronger case for reusing a WebSocket connection after a > > gracefully close that puts it into some kind of idle state. That's > > because users follow links every few seconds - and therefore WebSocket > > scripts in ordinary pages will connect and disconnect from the same > > server and port every few seconds in the current model. > > What use cases are you imagining that have Web Sockets used in such > scenarios? None of the intended use cases even remotely resemble this. Web > Sockets is intended for use on pages that are long-lived. It's quite > possible that there are use cases on short-lived pages also, but they > probably need their own protocol, optimised for those cases (e.g. HTTP and > the text/event-stream EventSource mechanism). WebSockets isn't trying to > be everything for everyone, it's just trying to address the specific use > case of trivially-implementable long-lived TCP-like connections for Web > browsers. > > > > Making it optional for both sides adds *zero* complexity for authors who > > don't do it. I am not seeing how you can think it makes any difference > > to them. > > Clients have to support it. This means implementation cost, testing cost, > and bug-fixing cost. It then propagates to documentation, which means > reference costs, tutorial costs, etc. This further means that authors will > see the feature in documentation. This leads to cognition costs when > learning the material, information retrieval costs when distinguishing > whether something is relevant or not when debugging, and communication > costs when discussing the feature with others, e.g. when determining > whether the feature is relevant to the question someone is asking. Then > there's the cost of maintaining code that someone else has written that > _does_ use the feature, there's the cost of debugging browser bugs when > the feature is misimplemented and interacts even with code that doesn't > use the feature, and finally there's the cost of implementing the feature > on the server side once it makes its way onto check-mark lists of features > that every web developer customer wants to support. > > > > Seriously, how do you imagine it affects them? > > Optional features are a lie. Nothing is really optional in a platform like > the Web's -- the only way a feature can be "free" is if it doesn't exist. > This is why we have to justify everything we add, and make sure it's on > the right side of the 80/20 line. > > > > > who would have no idea why their WebSocket servers were suddenly > > > receiving random HTTP requests and vice versa. > > > > That's a function of connecting to the wrong type of server already, and > > it's already dealt with by the spec'd negotation, which the wrong type > > of server handles already by design. Nothing new there. > > If we supported connection reuse and there was misconfiguration, then the > kinds of failure scenarios would be much more varied than they are now. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd23ad2ab9c78048be6f9d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2010 at 11:47 PM, Ian Hi= ckson <ian@hixie.ch> wrote:
On Wed, 19 May 2010, Jamie Lokier wrote:
> >
> > If we want to support multiple subprotocols at once, we can do so=
> > quite easily by just making the subprotocol list be comma-separat= ed.
> > Would this be a good idea?
>
> I think it is a good idea, although there is a risk of low-quality
> server but significant implementations matching a literal string,
> breaking when other values are added to the comma-separate list, and > therefore making it impossible for clients to actually use the
> capability.

Yeah, though since that bug would be specific to implementations of particular subprotocols, it would be pretty localised to individual
communities. That's probably an acceptable problem.

I've added this to the spec for now.

=A0
http://html5.org/tools/web-apps-tracker?from=3D5= 172&to=3D5173


> But assuming the comma-separated list did catch on, a consequence of > that would be the "below the API" part of WebSocket would ha= ve a place
> to add its own distinct entries to the comma-separated list, for
> recognition by the other side as transport option requests (such as > compression, etc.), safe in the knowledge it wouldn't break negoti= ation.
>
> (Separate headers would be much cleaner for that, though).

I don't see why we wouldn't just use separate fields for that= . No need to
overload the subprotocol field.


> > > =A0 =A0- Trying a HTTP-based protocol if WebSocket is unavai= lable (ditto)
> >
> > That wouldn't work anyway because the WebSocket object isn= 9;t the same
> > object as the XMLHttpRequest object and they therefore create ent= irely
> > different connections.
>
> Just being different objects is not technical reason for different
> connections. Separate XMLHttpRequest objects have no problem sharing > connections. There is no technical reason why a WebSocket object could=
> not do the same, just as easily. =A0Especially in browsers which routi= nely
> do this!

I guess. I'm not convinced it's a good idea though.


> > In any case, why wouldn't you know that Web Socket is availab= le? I
> > don't understand why you would guess that it is and then find= it
> > isn't. You need a URL to connect to a Web Socket, why would y= ou make
> > up a URL without knowing whether it'll work?
>
> Earlier in this thread, in a reply to you, we already gave an example.=
> It was the social networking client that talks to numerous de facto > standardised but different WebSocket protocols that the user shouldn&#= 39;t
> have to know about.
>
> Basically because autonegotiation is more user-friendly, both in terms=
> of users having to be given and enter fewer details, and in terms of > telling the user what went wrong if things didn't work out.
>
> As you noted, people don't always pass around URLs - they often pa= ss
> around just a domain name, or a truncated URL that doesn't include= the
> "http:" prefix.
>
> I would agree if it were _complicated_ to do, but we are talking about=
> really trivial stuff here. =A0Trying one thing, then trying another, i= s
> already handled by the handshake, and it is utterly trivial to do from= a
> script. =A0It's so easy that it's hard to see why any random w= eb developer
> wouldn't use it whenever it seemed like a good idea.
>
> It seems obvious to me that countless Javascripts will do exactly that= .

I could see trying multiple WebSocket protocols over one connection, = but
trying to try both HTTP or WebSocket connections, not to mention any other<= br> protocols the servers might provide, seems like massive complexity for
negligible gain overall.


> > This can be supported entirely in Web Socket if we want to do tha= t.
> > Currently, it's not clear that supporting this is even desire= able, due
> > to the UI issues with doing so.
>
> (On that topic, how do you propose to get through a proxy on port 443<= br> > that needs proxy authentication before it passes a CONNECT request?)
I guess the UA would have to use the existing (suboptimal) UI for pro= xy
auth. It's not a good situation to be in; I wouldn't recommend it.<= br>


> > WebSocket and HTTP are different protocols. Reusing the connectio= n
> > makes as much sense as reusing the connection of an FTP connectio= n
> > attempt to do an HTTP connection attempt.
>
> This is different. =A0Both WebSockets and HTTP requests are transient = in
> many cases.

FTP is more transient than WebSockets. WebSockets is intended for
connections that just stay open. It's not intended for transient use. I= t's
not at all designed for transient use. It will do poorly when used for
transient use.


> If FTP was also transient, and it shared the same port with
> HTTP, and many servers especially those designed for high performance<= br> > implemented both together, and many clients implemented both, then of<= br> > course it would make sense to _permit_ connection reuse between them,<= br> > without _requiring_ any implementation to do so.

I think it would be pretty silly even in those cases, personally. Reu= sing
connections amongst multiple protocols is simply asking for bugs. The
benefits are minimal and the costs are high. If you want to do multiple
things on a connection, use a protocol that supports all those things,
don't try to switch back and forth between protocols.

(By extension, I think the Upgrade mechanism in HTTP isn't a particular= ly
good idea. The number of times the mechanism has been used to great
success on the Web somewhat supports my position on this, I think.)

The UPGRADE mechanism was a fine idea. Poor tr= ansparent proxy implementations have killed its effectiveness.
-=3DR
=A0


> There is a much stronger case for reusing a WebSocket connection after= a
> gracefully close that puts it into some kind of idle state. =A0That= 9;s
> because users follow links every few seconds - and therefore WebSocket=
> scripts in ordinary pages will connect and disconnect from the same > server and port every few seconds in the current model.

What use cases are you imagining that have Web Sockets used in such scenarios? None of the intended use cases even remotely resemble this. Web<= br> Sockets is intended for use on pages that are long-lived. It's quite possible that there are use cases on short-lived pages also, but they
probably need their own protocol, optimised for those cases (e.g. HTTP and<= br> the text/event-stream EventSource mechanism). WebSockets isn't trying t= o
be everything for everyone, it's just trying to address the specific us= e
case of trivially-implementable long-lived TCP-like connections for Web
browsers.


> Making it optional for both sides adds *zero* complexity for authors w= ho
> don't do it. I am not seeing how you can think it makes any differ= ence
> to them.

Clients have to support it. This means implementation cost, testing c= ost,
and bug-fixing cost. It then propagates to documentation, which means
reference costs, tutorial costs, etc. This further means that authors will<= br> see the feature in documentation. This leads to cognition costs when
learning the material, information retrieval costs when distinguishing
whether something is relevant or not when debugging, and communication
costs when discussing the feature with others, e.g. when determining
whether the feature is relevant to the question someone is asking. Then
there's the cost of maintaining code that someone else has written that=
_does_ use the feature, there's the cost of debugging browser bugs when=
the feature is misimplemented and interacts even with code that doesn't=
use the feature, and finally there's the cost of implementing the featu= re
on the server side once it makes its way onto check-mark lists of features<= br> that every web developer customer wants to support.


> Seriously, how do you imagine it affects them?

Optional features are a lie. Nothing is really optional in a platform= like
the Web's -- the only way a feature can be "free" is if it do= esn't exist.
This is why we have to justify everything we add, and make sure it's on=
the right side of the 80/20 line.


> > who would have no idea why their WebSocket servers were suddenly<= br> > > receiving random HTTP requests and vice versa.
>
> That's a function of connecting to the wrong type of server alread= y, and
> it's already dealt with by the spec'd negotation, which the wr= ong type
> of server handles already by design. =A0Nothing new there.

If we supported connection reuse and there was misconfiguration, then= the
kinds of failure scenarios would be much more varied than they are now.

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'
_______________________________________________

--000e0cd23ad2ab9c78048be6f9d6-- From w@1wt.eu Wed Jul 21 08:15:28 2010 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 A35C33A6359 for ; Wed, 21 Jul 2010 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=-1.680, 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 FrfbqVMNKQrS for ; Wed, 21 Jul 2010 08:15:27 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 9BF173A684B for ; Wed, 21 Jul 2010 08:15:25 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LFFV14003028; Wed, 21 Jul 2010 17:15:31 +0200 Date: Wed, 21 Jul 2010 17:15:31 +0200 From: Willy Tarreau To: Roberto Peon Message-ID: <20100721151531.GA2990@1wt.eu> References: <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> 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: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 15:15:28 -0000 On Wed, Jul 21, 2010 at 07:54:14AM -0700, Roberto Peon wrote: > > (By extension, I think the Upgrade mechanism in HTTP isn't a particularly > > good idea. The number of times the mechanism has been used to great > > success on the Web somewhat supports my position on this, I think.) > > > > The UPGRADE mechanism was a fine idea. Poor transparent proxy > implementations have killed its effectiveness. Do we have reports of failures due to transparent proxies ? As of now, the only failure I'm aware of is due to the unadvertised bytes which is not compatible with HTTP. Willy From fenix@google.com Wed Jul 21 08:22:00 2010 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 5BDB03A6359 for ; Wed, 21 Jul 2010 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 hIFfh8Qz49cE for ; Wed, 21 Jul 2010 08:21:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 308A03A6814 for ; Wed, 21 Jul 2010 08:21:59 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o6LFMENI029259 for ; Wed, 21 Jul 2010 08:22:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279725734; bh=R+LSQiZ+OVWG9kxoSVMdnl/MRj8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=lzONuf1kOxP2gGhAbTx2wE7apeAiQ74Iuqbr24eyUi7b4K+8bIYL6hliIW9i+yKUN 2zD3H/RqmYKyt3/PfrGsg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=xSwAyCLYW+ftZTD6xtrwaRI+/kfxRoNX0GoeCxS58IZKC3SfkKGz8cTaEG1ElmqlY Ch6xgKXxJm69PSjQLOHUA== Received: from yxn35 (yxn35.prod.google.com [10.190.4.99]) by hpaq5.eem.corp.google.com with ESMTP id o6LFLtu5011757 for ; Wed, 21 Jul 2010 08:22:13 -0700 Received: by yxn35 with SMTP id 35so2082108yxn.23 for ; Wed, 21 Jul 2010 08:22:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.175.17 with SMTP id x17mr1910510ybe.300.1279725731275; Wed, 21 Jul 2010 08:22:11 -0700 (PDT) Received: by 10.150.59.4 with HTTP; Wed, 21 Jul 2010 08:22:11 -0700 (PDT) In-Reply-To: <20100721151531.GA2990@1wt.eu> References: <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> <20100721151531.GA2990@1wt.eu> Date: Wed, 21 Jul 2010 08:22:11 -0700 Message-ID: From: Roberto Peon To: Willy Tarreau Content-Type: multipart/alternative; boundary=00151748dc8e9f83f0048be75d82 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 15:22:00 -0000 --00151748dc8e9f83f0048be75d82 Content-Type: text/plain; charset=ISO-8859-1 I believe Mike quoted numbers in an earlier thread. Just to be sure we're talking about the same thing, I'm talking about the UPGRADE feature of HTTP generically, and not as it applies to the current draft Websocket spec. -=R On Wed, Jul 21, 2010 at 8:15 AM, Willy Tarreau wrote: > On Wed, Jul 21, 2010 at 07:54:14AM -0700, Roberto Peon wrote: > > > (By extension, I think the Upgrade mechanism in HTTP isn't a > particularly > > > good idea. The number of times the mechanism has been used to great > > > success on the Web somewhat supports my position on this, I think.) > > > > > > > The UPGRADE mechanism was a fine idea. Poor transparent proxy > > implementations have killed its effectiveness. > > Do we have reports of failures due to transparent proxies ? As of now, > the only failure I'm aware of is due to the unadvertised bytes which > is not compatible with HTTP. > > Willy > > --00151748dc8e9f83f0048be75d82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe Mike quoted numbers in an earlier thread.

Just= to be sure we're talking about the same thing, I'm talking about t= he UPGRADE feature of HTTP generically, and not as it applies to the curren= t draft Websocket spec.
-=3DR

On Wed, Jul 21, 2010 at 8:15 A= M, Willy Tarreau <w@1wt.eu= > wrote:
On Wed, Jul 21, 2010 at 07:54:14AM -0700, Roberto Peon wr= ote:
> > (By extension, I think the Upgrade mechanism in HTTP isn't a = particularly
> > good idea. The number of times the mechanism has been used to gre= at
> > success on the Web somewhat supports my position on this, I think= .)
> >
>
> The UPGRADE mechanism was a fine idea. Poor transparent proxy
> implementations have killed its effectiveness.

Do we have reports of failures due to transparent proxies ? As of now= ,
the only failure I'm aware of is due to the unadvertised bytes which is not compatible with HTTP.

Willy


--00151748dc8e9f83f0048be75d82-- From w@1wt.eu Wed Jul 21 08:45:18 2010 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 B0D863A69F6 for ; Wed, 21 Jul 2010 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-1.639, 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 KTsKxtJMm+c1 for ; Wed, 21 Jul 2010 08:45:16 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 896CF3A6981 for ; Wed, 21 Jul 2010 08:45:13 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LFjJpN003262; Wed, 21 Jul 2010 17:45:19 +0200 Date: Wed, 21 Jul 2010 17:45:19 +0200 From: Willy Tarreau To: Roberto Peon Message-ID: <20100721154519.GA3243@1wt.eu> References: <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> <20100721151531.GA2990@1wt.eu> 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: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 15:45:18 -0000 On Wed, Jul 21, 2010 at 08:22:11AM -0700, Roberto Peon wrote: > I believe Mike quoted numbers in an earlier thread. > > Just to be sure we're talking about the same thing, I'm talking about the > UPGRADE feature of HTTP generically, and not as it applies to the current > draft Websocket spec. I thought they were related to the current version since it also uses Upgrade. Anyway, even if some don't support it yet, it will be easy to detect bypass them based on simple rules. Willy From alexey.melnikov@isode.com Wed Jul 21 08:51:10 2010 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 47B2C3A6856 for ; Wed, 21 Jul 2010 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 Gu2EpTiWYA-X for ; Wed, 21 Jul 2010 08:51:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 142C83A67F4 for ; Wed, 21 Jul 2010 08:51:07 -0700 (PDT) Received: from [172.16.2.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Jul 2010 16:51:22 +0100 Message-ID: <4C471762.4090405@isode.com> Date: Wed, 21 Jul 2010 16:50:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ian Hickson References: <4C1F3F93.2020805@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] HyBi WG update 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, 21 Jul 2010 15:51:10 -0000 Hi Ian, Ian Hickson wrote: >On Mon, 21 Jun 2010, Salvatore Loreto wrote: > >>The 00 version Ian Hickson has update contains in the Abstract section, >>the following note: >> >> NOTE! THIS COPY OF THIS DOCUMENT IS OBSOLETE. >> >> For an up-to-date copy of this specification, please see: >> >> http://www.whatwg.org/specs/web-socket-protocol/ >> >>this note is against the IETF common practice, so we invite Ian to remove it. >> >> >The note is there because Joe requested that I not update the IETF copy as >often as the WHATWG copy. I need implementors looking at the latest >version of the draft. I don't really mind if they look at the HTML copy on >the WHATWG site (part of the Web Apps 1.0 draft), the text copy on the >WHATWG site, or the text copy on the IETF site, so long as what they look >at is up to date. Should I resume sending updates to the IETF draft as I >make them? > > No. You should post a new version not frequently than once a week, unless you have some massive changes, or urgent fixes. And I would like to remind you that all non-editorial changes (and if in doubt about whether a particular change is editorial or not, please treat it as non-editorial) should be tracked using the issue tracker as described earlier by the HyBi WG chairs. At minimum, I would expect that you post summary of any non-editorial change to the mailing list, before you publish a new version of the draft that incorporates such change. Best Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From daniel@haxx.se Wed Jul 21 11:38:45 2010 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 B093E3A6AF3 for ; Wed, 21 Jul 2010 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-4.100, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 1Wx5qWl4ubVB for ; Wed, 21 Jul 2010 11:38:42 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by core3.amsl.com (Postfix) with ESMTP id 073D03A6A73 for ; Wed, 21 Jul 2010 11:38:41 -0700 (PDT) Received: from giant.haxx.se (dast@giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with ESMTP id o6LIcpgu001005; Wed, 21 Jul 2010 20:38:51 +0200 Date: Wed, 21 Jul 2010 20:38:51 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Ian Hickson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Wed, 21 Jul 2010 20:38:52 +0200 (CEST) Cc: hybi@ietf.org Subject: Re: [hybi] Authentication headers 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, 21 Jul 2010 18:38:45 -0000 On Wed, 21 Jul 2010, Ian Hickson wrote: > HTTP auth is used so rarely that I'd seriously consider dropping it from > HTTP at this point; I really don't think it's worth adding to WebSockets. Sorry, but this is just a guess from you and I don't see how you have any numbers to back this up. In my view as a non-browser client author, HTTP auth is very frequently used. It might not be as common as cookies for web based authentication, but HTTP is way larger than just browser based operations. (I realize this is only on the border of being on-topic for this list, but I couldn't resist responding to such a bold claim.) -- / daniel.haxx.se From ian@hixie.ch Wed Jul 21 14:24:01 2010 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 736743A6B66 for ; Wed, 21 Jul 2010 14:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 6CKj9oIux9u3 for ; Wed, 21 Jul 2010 14:24:00 -0700 (PDT) Received: from looneymail-a2.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 3F8F63A6BBD for ; Wed, 21 Jul 2010 14:24:00 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a2.g.dreamhost.com (Postfix) with ESMTP id 2E97D16D427 for ; Wed, 21 Jul 2010 14:24:17 -0700 (PDT) Date: Wed, 21 Jul 2010 21:24:16 +0000 (UTC) From: Ian Hickson To: "hybi@ietf.org" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCCAD4@SISPE7MB1.commscope.com> Message-ID: References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCAD4@SISPE7MB1.commscope.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 21 Jul 2010 21:24:01 -0000 On Tue, 6 Jul 2010, Willy Tarreau wrote: > > Last week, it was reported to me that a site that was running fine on > draft 75 could not get the draft 76 handshake to complete via a HAProxy > load balancer, which runs as an HTTP reverse proxy. The connection would > remain open between the client and haproxy, and between haproxy and the > server, with the server never responding. The same client (Chromium > 6.0.414.0) directly connected to the server worked fine. > > The guy was kind enough to send me some network captures which show an > obvious problem : the 8-bytes nonce from the client is not advertised as > a content-length, so it is not forwarded by the reverse proxy as it is > either part of a next request or pending data for when the handshake > completes. Right, you need to update all the server-side components to support WebSocket. WebSocket is a new protocol. Similar updates would be needed to support other new protocols. > I can't agree with that because until the handshake completes, the proxy > does not know whether the server will handle the request as a WS > handshake or anything else, and it must absolutely not accept to blindly > trust any random client who sets an Upgrade header that any server is > free to ignore. Obviously all server-side components have to be configured to know the setup that they are in. This includes telling load balancers and other front-end intermediaries which hosts are ready to handle WebSocket connections and which are not. Just like a reverse proxy would not be configured to forward a connection to an SMTP server behind the firewall, it wouldn't be configured to send WebSocket traffic to HTTP servers. > Conversely, having no Content-Length header in the request means that we > don't know what a reverse proxy will do if it receives a valid one. For > instance, we could very well imagine that some reverse proxies which > will assume that Content-Length == 8 for any request containing > "Upgrade: WebSocket" will have trouble when receiving a different > Content-Length header. This could be used to pass larger amounts of data > than what is allowed by the protocol to a second reverse-proxy, which, > if it is able to parallelize pipelined requests, will forward the first > one to the server and the second one (embedded in the apparent data) to > another server. The spec is very clear about how a server side is to parse the handshake. I don't think there's any ambiguity here. There's no need for the reverse proxy to "assume a Content-Length" or anything like that; if it decides that the request is a WebSocket request (e.g. based on the presence of an "Upgrade: WebSocket" field, or based on the target IP or the given resource name), then it should follow the Web Socket spec. > The first obvious solution that comes to mind is to comply with the HTTP > protocol which will be implemented along the whole chain and to simply > add a "Content-Length: 8" header in the request. As far as I can tell there is nothing here that contradicts the HTTP spec. If there is a specific requirment in the HTTP spec that is being contradicted, please cite it. We could add Content-Length: 0, but as far as I can tell that's implied for GET anyway, so it wouldn't change anything in conforming software. (This isn't very clear in the HTTP spec though.) We can't add Content-Length: 8, since that would mean the data would be sent through with the first request even in non-WebSocket-aware man-in- the-middle proxies, which defeats the point. > But this raises a second point : shouldn't we switch to POST instead of > GET then? We could use another method, but there doesn't seem to be much reason to do so. GET turns out to be the simplest to deal with in a variety of situations. > Anyway, we have to do something now because we've reached the point Ian > tried to ensure we would avoid a long time ago : the deadlock which is > undetectable by the client. A deadlock isn't a big deal. The problem was a false-positive situation, where the handshake works but frames don't go through. On Wed, 7 Jul 2010, Thomson, Martin wrote: > > > > Content-length: 0 also makes sense but it means that the nonce will be > > sent *after* the handshake, which means we'd have a second round-trip. > > The round-trip thing is a fallacy. Just as you can pipeline requests, > so can you send extra handshakey parts after the headers. > > Solution: The handshake includes a complete HTTP message, PLUS extra > stuff. All of this is sent at once, but the HTTP stuff stops half way. That's exactly what the spec does. On Thu, 8 Jul 2010, Greg Wilkins wrote: > > You are correct that it is not an extra round trip. But I do not think > it is a good solution to send a complete HTTP message PLUS extra stuff > in the request. > > If the handshake is legal HTTP, the server should be able to rejects the > websocket upgrade without closing the connection. This would allow the > connection to remain in the browsers pool of connections and avoid an > extra round trip to establish another connection if the application > falls back to non-websocket transports. The browser can't know if the server is really an HTTP server, so it can't possibly reuse the connection. It could in fact be a huge security hole, depending on how we did this. It is, in either case, far more complexity than is in any way justified here. All of these problems come from thinking of Web Sockets as a subprotocol of HTTP. It isn't. Web Sockets is its own high-level protocol built on top of TCP. It just happens to look enough like HTTP that you can reuse the port, but that doesn't mean it's an HTTP-based protocol. Thinking of Web Sockets as having anything to do with HTTP is a mistake. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From trac@tools.ietf.org Wed Jul 21 14:49:09 2010 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 7EAE83A6863 for ; Wed, 21 Jul 2010 14:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 IE1HYwBUKjhE for ; Wed, 21 Jul 2010 14:49:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 71D253A67F3 for ; Wed, 21 Jul 2010 14:49:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ObhAK-0003Px-IQ; Wed, 21 Jul 2010 14:49:24 -0700 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: ian@hixie.ch X-Trac-Project: hybi Date: Wed, 21 Jul 2010 21:49:24 -0000 X-URL: http://tools.ietf.org/hybi/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/hybi/trac/ticket/4#comment:1 Message-ID: <077.8c89e0c4fc22a4bc7360a50ff588a299@tools.ietf.org> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: ian@hixie.ch, 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] #4: handshake does not work properly with HTTP reverse proxy. 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: Wed, 21 Jul 2010 21:49:09 -0000 #4: handshake does not work properly with HTTP reverse proxy. -------------------------------------------+-------------------------------- Reporter: salvatore.loreto@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: thewebsocketprotocol | Version: Severity: Active WG Document | Keywords: -------------------------------------------+-------------------------------- Changes (by ian@…): * cc: ian@… (added) Comment: This is a new protocol, so network infrastructure naturally needs to be updated to handle it, as discussed in this reply: http://www.ietf.org/mail-archive/web/hybi/current/msg02274.html No change to the protocol is proposed to resolve this; it is easily resolved by implementing Web Socket support in the proxy. -- 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 w@1wt.eu Wed Jul 21 15:10:21 2010 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 14EBD3A6A51 for ; Wed, 21 Jul 2010 15:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_24=0.6] 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 qyH4qA8w5xcY for ; Wed, 21 Jul 2010 15:10:19 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id AAD503A68A3 for ; Wed, 21 Jul 2010 15:10:18 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LMAVgV006860; Thu, 22 Jul 2010 00:10:31 +0200 Date: Thu, 22 Jul 2010 00:10:31 +0200 From: Willy Tarreau To: Ian Hickson Message-ID: <20100721221031.GA6475@1wt.eu> References: <20100706210039.GA12167@1wt.eu> <20100707044129.GH12126@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03E9DCCA29@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCAD4@SISPE7MB1.commscope.com> 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: "hybi@ietf.org" Subject: Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies 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, 21 Jul 2010 22:10:21 -0000 On Wed, Jul 21, 2010 at 09:24:16PM +0000, Ian Hickson wrote: > On Tue, 6 Jul 2010, Willy Tarreau wrote: > > > > Last week, it was reported to me that a site that was running fine on > > draft 75 could not get the draft 76 handshake to complete via a HAProxy > > load balancer, which runs as an HTTP reverse proxy. The connection would > > remain open between the client and haproxy, and between haproxy and the > > server, with the server never responding. The same client (Chromium > > 6.0.414.0) directly connected to the server worked fine. > > > > The guy was kind enough to send me some network captures which show an > > obvious problem : the 8-bytes nonce from the client is not advertised as > > a content-length, so it is not forwarded by the reverse proxy as it is > > either part of a next request or pending data for when the handshake > > completes. > > Right, you need to update all the server-side components to support > WebSocket. WebSocket is a new protocol. Similar updates would be needed to > support other new protocols. Ian, I don't know how to explain it to you now. I've exhausted every bit of possibility a normal human is able to understand, so I think that you are deliberately acting to refuse to understand the facts :-( I've told you *several* times that it's not a matter of "updating" server- side components, but that your cross-dressed protocol will not be mergeable with HTTP on reverse-proxies. So even if the reverse-proxies are "updated" to use your terms, then they will have to be either configured to support WebSocket *OR* configured to support HTTP, but not both on the same IP:port couple. What you are suggesting is that a shared component which would have to support both protocols would have to trust any request that contains an Upgrade header without even knowing if the server will see it. That's simply not acceptable. Anyone will be able to play with HTTP servers behind HTTP reverse-proxies pretending to be talking WebSocket. That's silly and undesired. HTTP spec is clear : the protocol resulting from an Upgrade is switched *AFTER* the "101" response, not *BEFORE*. So the reverse-proxy MUST see the 101 to accept to pass non-HTTP bytes to the other side if they are not advertised in the request. > > I can't agree with that because until the handshake completes, the proxy > > does not know whether the server will handle the request as a WS > > handshake or anything else, and it must absolutely not accept to blindly > > trust any random client who sets an Upgrade header that any server is > > free to ignore. > > Obviously all server-side components have to be configured to know the > setup that they are in. This includes telling load balancers and other > front-end intermediaries which hosts are ready to handle WebSocket > connections and which are not. Just like a reverse proxy would not be > configured to forward a connection to an SMTP server behind the firewall, > it wouldn't be configured to send WebSocket traffic to HTTP servers. No, this is totally different here, because requests are routed through multiple layers of reverse-proxies on server-side which fortunately don't all have to know every single bit of URLs. The outer ones just know how to process global confs and *some* inner components may specifically be tuned to know that *some* URLs will be working differently. But that's clearly not even remotely thinkable for hosting providers. They offer you a host name, everyone behind the same IP and they don't want to know how you will be managing your URLs, they just forward you the traffic for that Host: header and you do whatever you want with it. And if you want to change your WS URL twice a day, it's your problem and they don't have to reconfigure all of their components just because of you. > > Conversely, having no Content-Length header in the request means that we > > don't know what a reverse proxy will do if it receives a valid one. For > > instance, we could very well imagine that some reverse proxies which > > will assume that Content-Length == 8 for any request containing > > "Upgrade: WebSocket" will have trouble when receiving a different > > Content-Length header. This could be used to pass larger amounts of data > > than what is allowed by the protocol to a second reverse-proxy, which, > > if it is able to parallelize pipelined requests, will forward the first > > one to the server and the second one (embedded in the apparent data) to > > another server. > > The spec is very clear about how a server side is to parse the handshake. > I don't think there's any ambiguity here. There's no need for the reverse > proxy to "assume a Content-Length" or anything like that; if it decides > that the request is a WebSocket request (e.g. based on the presence of an > "Upgrade: WebSocket" field, or based on the target IP or the given > resource name), then it should follow the Web Socket spec. Please see above for the nth time why it cannot "decide" that it is a WS request. All the problem comes from that. It can only decide based on what the client decides to tell it, and when the server responds, it's too late. > > The first obvious solution that comes to mind is to comply with the HTTP > > protocol which will be implemented along the whole chain and to simply > > add a "Content-Length: 8" header in the request. > > As far as I can tell there is nothing here that contradicts the HTTP spec. > If there is a specific requirment in the HTTP spec that is being > contradicted, please cite it. I really think you're trying to make all of us waste our time while we're trying to help you release something which works instead of it becoming a major failure that will be attempted to be used for 6 months then abandonned due to massive failures everywhere. That's a real pity. So here it comes, from RFC2616 (and this part remained unchanged in http-bis-p1-10) : 4.4 Message Length ... HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length. All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored. When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected. In short, there is a message body, so either you advertise it using Content-Length or you advertise it using Transfer-Encoding: chunked, though the later requires that you're certain that the server supports HTTP/1.1 which is not necessarily the case. > We could add Content-Length: 0, but as far as I can tell that's implied > for GET anyway, so it wouldn't change anything in conforming software. > (This isn't very clear in the HTTP spec though.) Indeed, it would change nothing, it would just clarify the fact that you want to send nothing, which is already implicit when there's no content-length nor transfer-encoding in the request. > We can't add Content-Length: 8, since that would mean the data would be > sent through with the first request even in non-WebSocket-aware man-in- > the-middle proxies, which defeats the point. No, this is *what you need*. You need any HTTP-compliant component to reliably deliver this request because HTTP is the medium over which WebSocket will be used, like it or not. What you're currently doing is ensuring that HTTP-compliant software that are already working correctly everywhere will not be able to pass WebSocket requests to their peers, which will result in the protocol never being used beyond what it's always been since the beginning : tests between your local browser and your local hand-written server. > > Anyway, we have to do something now because we've reached the point Ian > > tried to ensure we would avoid a long time ago : the deadlock which is > > undetectable by the client. > > A deadlock isn't a big deal. The problem was a false-positive situation, > where the handshake works but frames don't go through. No, the handshake does not work because the server does never get the first 8 bytes so it does not respond. I would have no problem if those 8 bytes were not required before the 101 response, but it happens the server needs them before responding, which is causing the chicken-and-egg problem : client : hey, I'm sending you my handshake, and don't care about my extra bytes rev-proxy: hey server, I'm sending you a handshake, and if you reply with 101, I will send you the extra bytes server : I won't complete my handshake until you send me those bytes. > On Thu, 8 Jul 2010, Greg Wilkins wrote: > > > > You are correct that it is not an extra round trip. But I do not think > > it is a good solution to send a complete HTTP message PLUS extra stuff > > in the request. > > > > If the handshake is legal HTTP, the server should be able to rejects the > > websocket upgrade without closing the connection. This would allow the > > connection to remain in the browsers pool of connections and avoid an > > extra round trip to establish another connection if the application > > falls back to non-websocket transports. > > The browser can't know if the server is really an HTTP server, so it can't > possibly reuse the connection. It could in fact be a huge security hole, > depending on how we did this. It is, in either case, far more complexity > than is in any way justified here. I don't agree. As long as the server has not responded with 101, it *IS* HTTP. So you can do whatever you want on the connection before the 101, including authenticating with a challenge if you like. > All of these problems come from thinking of Web Sockets as a subprotocol > of HTTP. It isn't. Web Sockets is its own high-level protocol built on top > of TCP. It just happens to look enough like HTTP that you can reuse the > port, but that doesn't mean it's an HTTP-based protocol. Thinking of Web > Sockets as having anything to do with HTTP is a mistake. Please stop denying the initial goals, you know it won't be used it you can't share the port, and it's even still written in draft-76 : When a connection is to be made to a port that is shared by an HTTP server (a situation that is quite likely to occur with traffic to ports 80 and 443), the connection will appear to the HTTP server to be a regular GET request with an Upgrade offer. In relatively simple setups with just one IP address and a single server for all traffic to a single hostname, this might allow a practical way for systems based on the WebSocket protocol to be deployed. Willy From ian@hixie.ch Wed Jul 21 15:16:50 2010 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 4F5933A6944 for ; Wed, 21 Jul 2010 15:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 SH4wxf-ZTDWT for ; Wed, 21 Jul 2010 15:16:48 -0700 (PDT) Received: from looneymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 634E03A6899 for ; Wed, 21 Jul 2010 15:16:46 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a4.g.dreamhost.com (Postfix) with ESMTP id E793B85AD for ; Wed, 21 Jul 2010 15:17:02 -0700 (PDT) Date: Wed, 21 Jul 2010 22:17:02 +0000 (UTC) From: Ian Hickson To: Hybi In-Reply-To: <4C462F9E.9030207@caucho.com> Message-ID: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 22:16:50 -0000 On Tue, 20 Jul 2010, John Tamplin wrote: > On Tue, Jul 20, 2010 at 6:14 PM, Ian Hickson wrote: > > > > What I'm interested in personally is writing a protocol that amateur > > programmers can implement easily. If we say they have to use someone > > else's code to do this, then that's a failure, IMHO. (Though as I've > > mentioned before, if people have different goals or priorities, I have > > no problem with separate protocols also being designed to address > > those -- Web Sockets doesn't have to be everything for everybody.) > > I still don't see the argument for servers written by amateurs. I have > used far more quick-and-dirty web clients (telnet, socket/connect/write > in C, wget/curl, etc) than I have quick-and-dirty servers. That's largely because most protocols are such that you can't make a compliant server quickly. The one exception (which isn't a network protocol but is relatively similar for the purposes of this discussion) is CGI. That's a simple protocol, and there are many implementations of the server side of the protocol (that is, CGI scripts; the HTTP server is the client of the CGI protocol). Now, most people use libraries, of course, and that's fine. But the protocol is simple enough that you don't _have_ to use a library, and some people don't. > If some amateur needs to write a server anyway, they aren't going to > write it from scratch even if it were possible for them to do so -- they > will find some library. Yes, for most existing protocols that is the sad reality. I think that's a failure on our part (the part of protocol designers). We can enable much greater experimentation, innovation, learning, and so forth, if we make lower the bar to the level of CGI scripts rather than keeping it at the level of HTTP servers. > Contrast this with embedded clients, which might well have tighter > constraints than most clients, and could benefit from having optional > features they could leave out that would be useful for more powerful > clients. Meanwhile, the servers are going to almost certainly be on > more powerful machines, though granted they have more connections to > support. In the case of Web Sockets, most clients (by usage) are going to be Web browsers, so if we are forced to put complexity into the protocol, we should move it to the browser side. But in general we should keep that side simple too, so that custom clients can also be written. On Wed, 21 Jul 2010, Jamie Lokier wrote: > > All that's needed, for amateur programmer compatibility, is for the > "complex" performance-enhancing features to be optional negotiated > features on top of an extremely simple base protocol. And for the > negotiation to be really simple too. Once the protocol is proven, I think it would make sense to add optional features. The protocol is designed to make that easy for us. On Tue, 20 Jul 2010, Roberto Peon wrote: > > We need browser-owned connections with a security model that allows multiple > tabs to share the connection safely. > This is probably the most important requirement for scalability as far as > I'm concerned. This requires fewer keep-alives (both because of fewer TCP > connections and because the TCP connection is more likely to have real > content sent on it instead of near-zero value'd keep-alives), it requires > fewer file descriptors, it requires fewer handshakes. This is pretty easily implemented at the application layer using shared workers. On Tue, 20 Jul 2010, Mike Belshe wrote: > > For as adamantly as Ian states that it should be a requirement, I am > just as adamant that it should not. It's quite possible that this working group should be working on two (or more) protocols, rather than trying to solve all our problems with Web Sockets. Or it could be that Web Sockets isn't the right solution for the problems that most people in this working group are trying to solve. Web Sockets is a trivially-implementable TCP-for-browsers protocol for long-lived connections. If that doesn't sound like the protocol you need, then you need a different protocol. If that isn't the protocol this working group wants, then this working group wants another protocol. I don't think there's anything wrong with that, but then we should work on that protocol, not Web Sockets. > But more importantly, this single issue has been holding protocol > progress hostage. Naturally, any feature has some amount of complexity. > But this requirement creates an invisible, and subjective barrier to > each feature. Is the feature too complex for an amateur programmer? > Nobody knows, and everyone disagrees, because it is a subjective > criteria. So we spin and can't agree. I disagree that the protocol's development has been in any way held up by this. I agree that we've talked about it a lot in the working group, but the spec itself hasn't been affected by this as far as I can tell. > Every protocol expert I've spoken with agrees that amateur protocol > implementors should not be a requirement. And what did the protocol amateurs you spoke to say? It seems unsurprising that people whose careers are based on being able to solve complicated protocol problems should want protocols to be complicated. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jamie@shareable.org Wed Jul 21 15:22:01 2010 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 28D793A6899 for ; Wed, 21 Jul 2010 15:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 Rz-mRJpfKPHD for ; Wed, 21 Jul 2010 15:22:00 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 52AFB3A67D9 for ; Wed, 21 Jul 2010 15:22:00 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Obhg2-0000Vs-6f; Wed, 21 Jul 2010 23:22:10 +0100 Date: Wed, 21 Jul 2010 23:22:10 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20100721222210.GA14589@shareable.org> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> <20100720044352.GE14242@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100720044352.GE14242@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Wed, 21 Jul 2010 22:22:01 -0000 Willy Tarreau wrote: > Also, I would really insist that we add a "Connection: close" in the > initial HTTP handshake, whatever it looks like in the end, so that we > protect the servers against any form of request injection after the > first one. I agree, that's good advice. -- Jamie From ian@hixie.ch Wed Jul 21 15:28:20 2010 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 C8E723A659C for ; Wed, 21 Jul 2010 15:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 j1Gt93qrt4+X for ; Wed, 21 Jul 2010 15:28:17 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id AC3233A68A3 for ; Wed, 21 Jul 2010 15:28:17 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 5DB3315D577; Wed, 21 Jul 2010 15:28:34 -0700 (PDT) Date: Wed, 21 Jul 2010 22:28:34 +0000 (UTC) From: Ian Hickson To: John Tamplin In-Reply-To: Message-ID: References: <4BCF4932.8040303@gmail.com> <4BD09A2C.6060506@gmail.com> <8B0A9FCBB9832F43971E38010638454F03E7D06DF7@SISPE7MB1.commscope.com> <20100422225448.GG13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E00@SISPE7MB1.commscope.com> <20100422230957.GI13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E06@SISPE7MB1.commscope.com> <20100423001858.GA22326@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E28@SISPE7MB1.commscope.com> <20100423103715.GB32366@shareable.org> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiple connections serialization and proxies 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, 21 Jul 2010 22:28:20 -0000 On Tue, 20 Jul 2010, John Tamplin wrote: > On Tue, Jul 20, 2010 at 7:14 PM, Ian Hickson wrote: > > > > > > I favour the server being able to send back a number saying how many > > > more connections are permitted now. Negotiated flow control, rather > > > than spec'd fixed values (except the first). There could still be a > > > default, for simple implementations. > > > > That seems like something we should add in a future version, if it > > really is needed. Baby steps, keep things simple, etc. > > Given the lack of extensibility and negotiation, how would it be added > in the future without breaking backwards compatibility? There's no lack of extensibility and negotiation, both are built into the protocol. Future versions of the protocol can simply define new option fields that the client can include to announce support and that the server can include to announce opt-in. For example, the client could say: Sec-WebSocket-Compression: gzip bzip2 ...and the server might then respond with: Sec-WebSocket-Compression: gzip ...indicating that the client and server will both compress frames using gzip. Pretty much anything can be defined; if both the client and the server opt in to a feature, nothing constrains what the protocol has to look like from then on. We could define an option that, once selected by both parties, switches the protocol to an entirely different framing mechanism, if we find that the simple framing currently in the spec isn't good enough. So long as we define all the interactions of the options, we're pretty much open to doing anything in future versions short of changing the basic shape of the handshake. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From w@1wt.eu Wed Jul 21 15:28:38 2010 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 6CF6F3A69FB for ; Wed, 21 Jul 2010 15:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.556, 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 MezZVPM64fCS for ; Wed, 21 Jul 2010 15:28:37 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id D73243A696E for ; Wed, 21 Jul 2010 15:28:36 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LMSpYJ006961; Thu, 22 Jul 2010 00:28:51 +0200 Date: Thu, 22 Jul 2010 00:28:51 +0200 From: Willy Tarreau To: hybi issue tracker Message-ID: <20100721222851.GC6475@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <077.8c89e0c4fc22a4bc7360a50ff588a299@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <077.8c89e0c4fc22a4bc7360a50ff588a299@tools.ietf.org> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Wed, 21 Jul 2010 22:28:38 -0000 On Wed, Jul 21, 2010 at 09:49:24PM -0000, hybi issue tracker wrote: > #4: handshake does not work properly with HTTP reverse proxy. > -------------------------------------------+-------------------------------- > Reporter: salvatore.loreto@??? | Owner: > Type: defect | Status: new > Priority: critical | Milestone: > Component: thewebsocketprotocol | Version: > Severity: Active WG Document | Keywords: > -------------------------------------------+-------------------------------- > Changes (by ian@???): > > * cc: ian@??? (added) > > > Comment: > > This is a new protocol, so network infrastructure naturally needs to be > updated to handle it, as discussed in this reply: > http://www.ietf.org/mail-archive/web/hybi/current/msg02274.html No, as explained in many other messages, it CANNOT be updated and remain HTTP-compatible at the same time. The protocol needs be fixed. Willy From jamie@shareable.org Wed Jul 21 15:30:17 2010 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 42EB43A6899 for ; Wed, 21 Jul 2010 15:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 VxVfiMM9OAmd for ; Wed, 21 Jul 2010 15:29:56 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 0AF1A3A684F for ; Wed, 21 Jul 2010 15:29:55 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Obhnm-0000YT-Iz; Wed, 21 Jul 2010 23:30:10 +0100 Date: Wed, 21 Jul 2010 23:30:10 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20100721223010.GB14589@shareable.org> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> 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, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Wed, 21 Jul 2010 22:30:23 -0000 Greg Wilkins wrote: > On 17 July 2010 12:37, Jamie Lokier wrote: > > hybi issue tracker wrote: > > From discussions on the hybi list several months ago, several times, I > > got the impression that failure to work through any kind of HTTP proxy > > was *intentional* in the handshake design. > > > > I don't personally agree with that as a design goal, but if it is the > > design goal than this issue #4 isn't a bug. > > >From those same discussion, I concluded that the intent of this > "feature" was to fast fail in the presence of any kind of HTTP proxy. > Given that this "feature" is now resulting in a hang if there is such > a proxy, then I think it is still a bug whatever way you look at it. I agree with something implied here: fast failing is more desirable than slow failing, where it's realistically feasible to trigger fast failing without causing problems. It can't be guaranteed, and there's no point overcomplicating it, but it's useful to try. > More importantly, the best way to test if a connection will support > websocket packets, is to just send websocket packets. Sending 8/16 > random bytes immediately after the HTTP handshake may succeed for a > huge variety of implementation reasons that still do not mean that > websocket packets will succeed. More importantly, to detect the > non-success of sending of the 8/16 random bytes will still involve the > same timeout handling that would be required to check the transmission > of websocket packets. The argument against just sending WebSocket packets is that some WebSocket packets may be valid HTTP and therefore more likely to be misinterpreted or be used as another attack vector, or simply fail to fail fast. That's not possible with the current WebSocket frame types, but it could happen with frame types from the currently reserved range. That's also an argument against making the bytes uniformly random; instead they should also be constrained to avoid looking like HTTP. -- Jamie From ian@hixie.ch Wed Jul 21 15:38:25 2010 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 CBFCD3A680F for ; Wed, 21 Jul 2010 15:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 O7ZORCeA7c-2 for ; Wed, 21 Jul 2010 15:38:23 -0700 (PDT) Received: from looneymail-a3.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id BCB3B3A67E7 for ; Wed, 21 Jul 2010 15:38:22 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a3.g.dreamhost.com (Postfix) with ESMTP id A176C7CCF6; Wed, 21 Jul 2010 15:38:39 -0700 (PDT) Date: Wed, 21 Jul 2010 22:38:39 +0000 (UTC) From: Ian Hickson To: Jamie Lokier In-Reply-To: <20100721011221.GC27243@shareable.org> Message-ID: References: <4BE5994E.4010701@webtide.com> <20100721011221.GC27243@shareable.org> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hybi@ietf.org Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 22:38:26 -0000 On Wed, 21 Jul 2010, Jamie Lokier wrote: > > The use case for User-Agent, normally determined by the client > implementation (not the application running on top of the WebSocket > API), is to provide servers with unreliable but pragmatically useful > information about what client implementations are using the server. > > It is used for profiling, for general interest, for tracking what > clients may need to be supported if there are particular issues to be > avoided with some clients (such as a particular message that breaks one > of them), for tracking when clients with particular workarounds on the > server have fallen into sufficient misuse that the workarounds can be > removed, and for implementing specific workarounds for particular > recognised clients. > > Hopefully workarounds at the WebSocket framing level are unlikely to be > commonly needed (although that might not be true if some clients have a > small message size limit and particular server applications have to > format their messages to accomodate this); but User-Agent turned out to > be quite pragmatic in HTTP for dealing with client-specific issues that > nobody had foreseen until they were too widely deployed to ignore or > fix. This seems reasonable, but it also seems like something that we should just push to the application layer, and that we can push to the application layer with minimal incremental cost -- and indeed with some side-benefits, like making the handshake simpler for people who don't need this information, like preventing the problems that occured with HTTP's User-Agent header (such as everything saying they're Mozilla), and like giving authors more control over exactly what they want to check for (e.g. some might only care about the rendering engine, others might care only about the user's screen size, and by pushing it into the application layer we allow the subprotocol designers to decide what is important to them). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From w@1wt.eu Wed Jul 21 15:39:33 2010 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 3551F3A680F for ; Wed, 21 Jul 2010 15:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=-1.520, 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 u9FKOZmJlWxt for ; Wed, 21 Jul 2010 15:39:32 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id EDBB63A67E7 for ; Wed, 21 Jul 2010 15:39:31 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LMdlWb007036; Thu, 22 Jul 2010 00:39:47 +0200 Date: Thu, 22 Jul 2010 00:39:47 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100721223947.GD6475@1wt.eu> References: <068.da8db0c773647cb0ed73d576f39e93ee@tools.ietf.org> <20100717023749.GA2426@shareable.org> <20100721223010.GB14589@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721223010.GB14589@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org, hybi issue tracker Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse 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: Wed, 21 Jul 2010 22:39:33 -0000 On Wed, Jul 21, 2010 at 11:30:10PM +0100, Jamie Lokier wrote: > Greg Wilkins wrote: > > More importantly, the best way to test if a connection will support > > websocket packets, is to just send websocket packets. Sending 8/16 > > random bytes immediately after the HTTP handshake may succeed for a > > huge variety of implementation reasons that still do not mean that > > websocket packets will succeed. More importantly, to detect the > > non-success of sending of the 8/16 random bytes will still involve the > > same timeout handling that would be required to check the transmission > > of websocket packets. > > The argument against just sending WebSocket packets is that some > WebSocket packets may be valid HTTP and therefore more likely to be > misinterpreted or be used as another attack vector, or simply fail to > fail fast. Indeed, but even the first 8 random bytes can currently be used as a valid HTTP request or beginning of such, as some servers still accept HTTP/0.9 requests after a keep-alive request, and basically anything terminated with a line feed may constitude an HTTP/0.9 request. Also, the line feed is not even required, you can just send 8 normal bytes which will prefix the method of the next request. So in fact, relying on the server's 101 response to the Upgrade request is the most reliable thing to do, as it translates the server's intent to switch and to respect the negociated protocol. Someone suggested that regularly sending keep-alives in the connection would be nice. I second this, especially with long-lived connections that will regularly get dropped on firewalls after too long idleness. This would also make it possible to ensure that the connection is OK. Regards, Willy From ian@hixie.ch Wed Jul 21 15:44:36 2010 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 4A7C53A659C for ; Wed, 21 Jul 2010 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 XV1ksqIZfk9j for ; Wed, 21 Jul 2010 15:44:34 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id E26D03A67D9 for ; Wed, 21 Jul 2010 15:44:33 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id B9C6215D577; Wed, 21 Jul 2010 15:44:50 -0700 (PDT) Date: Wed, 21 Jul 2010 22:44:50 +0000 (UTC) From: Ian Hickson To: L.Wood@surrey.ac.uk In-Reply-To: Message-ID: References: <4C1F3F93.2020805@ericsson.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hybi@ietf.org Subject: Re: [hybi] HyBi WG update 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, 21 Jul 2010 22:44:36 -0000 On Wed, 21 Jul 2010, L.Wood@surrey.ac.uk wrote: > > You don't need implementers implementing from the latest revision of the > draft. > > You need implementers implementing from a _considered_ version of the > draft, and a fixed referencable point at that. Sure, but given that implementers are going to implement the spec regardless, I'd much rather they implemented the latest version, with all the bugs removed, rather than a version that we _know_ is buggy. > On the author's note: We've already discussed not promoting discussion > on WHATWG. This is an IETF draft; all discussion needs to be on hybi. Discussion will be where discussion is, not much we can do about that. I'm happy to adjust the note to point out that the IETF would rather own all discussion and not have discussion elsewhere, but that wasn't the request, the request was just to remove the note altogether, which doesn't seem constructive (after all, we want to encourage feedback, and to do so we need to say where the feedback should go). Clarification from the chairs as to the reason behind the request would be helpful here. > Are you not following IETF list discussion except in sporadic bursts? I only reply sporadically, because I work on a number of other parts of the WHATWG specification, and tend to work on each part for a few days before moving on to the next. This allows me to respond to feedback in bulk, so that many related points of view can be addressed at once rather than responding to each one individually, which would result in much more e-mail overall. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Wed Jul 21 15:46:56 2010 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 6F6833A6902 for ; Wed, 21 Jul 2010 15:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 Z4N0wpf68Ba9 for ; Wed, 21 Jul 2010 15:46:55 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 8C9323A680F for ; Wed, 21 Jul 2010 15:46:55 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 7761715D577; Wed, 21 Jul 2010 15:47:12 -0700 (PDT) Date: Wed, 21 Jul 2010 22:47:12 +0000 (UTC) From: Ian Hickson To: Maciej Stachowiak In-Reply-To: <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> Message-ID: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 22:46:56 -0000 On Wed, 21 Jul 2010, Maciej Stachowiak wrote: > > In my opinion, to the extent we support intermediaries, the design > should require at least one of the client or server to be explicitly > aware of the intermediary. Agreed. I think we should add this to the requirements. > We should not support magical transparent intermediaries where neither > the client nor server has an obvious way to detect its existence; in > fact we should design the protocol to prevent such intermediaries from > being created. The only way I can see to do this would be to require TLS (or some equivalent asymmetric encryption scheme), which I think is too high a cost. Otherwise, in principle, I agree with this too. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From gregw@webtide.com Wed Jul 21 15:51:15 2010 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 3EF103A68A3 for ; Wed, 21 Jul 2010 15:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 1wuQVZ9l25o5 for ; Wed, 21 Jul 2010 15:51:13 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 57AD63A659C for ; Wed, 21 Jul 2010 15:51:13 -0700 (PDT) Received: by fxm1 with SMTP id 1so4338526fxm.31 for ; Wed, 21 Jul 2010 15:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.110.134 with SMTP id n6mr1001097fap.79.1279752688475; Wed, 21 Jul 2010 15:51:28 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 15:51:28 -0700 (PDT) In-Reply-To: References: <4BCF4932.8040303@gmail.com> <4BD09A2C.6060506@gmail.com> <8B0A9FCBB9832F43971E38010638454F03E7D06DF7@SISPE7MB1.commscope.com> <20100422225448.GG13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E00@SISPE7MB1.commscope.com> <20100422230957.GI13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E06@SISPE7MB1.commscope.com> <20100423001858.GA22326@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E28@SISPE7MB1.commscope.com> <20100423103715.GB32366@shareable.org> Date: Thu, 22 Jul 2010 08:51:28 +1000 Message-ID: From: Greg Wilkins To: Ian Hickson Content-Type: multipart/alternative; boundary=001636c5bbe2659ce5048beda4ae Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiple connections serialization and proxies 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, 21 Jul 2010 22:51:15 -0000 --001636c5bbe2659ce5048beda4ae Content-Type: text/plain; charset=UTF-8 On 22 July 2010 08:28, Ian Hickson wrote: There's no lack of extensibility and negotiation, both are built into the > protocol. Future versions of the protocol can simply define new option > fields that the client can include to announce support and that the server > can include to announce opt-in. For example, the client could say: > > Sec-WebSocket-Compression: gzip bzip2 > > ...and the server might then respond with: > > Sec-WebSocket-Compression: gzip > > Ian, That will not work, because old versions of websocket are constrained by the current standard to reject connections with unknown headers. So if a future version introduced such a header, it would immediately make new client unable to interoperate with old servers. If we do not allow arbitrary headers, then we will severely limit our options for upgrading the protocol in the future. --001636c5bbe2659ce5048beda4ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 July 2010 08:28, Ian Hickson <ian@hixie.ch> wrote:

There's= no lack of extensibility and negotiation, both are built into the
protocol. Future versions of the protocol can simply define new option
fields that the client can include to announce support and that the server<= br> can include to announce opt-in. For example, the client could say:

=C2=A0 Sec-WebSocket-Compression: gzip bzip2

...and the server might then respond with:

=C2=A0 Sec-WebSocket-Compression: gzip


Ian,

That will not work, because old versions of websocket are constrained by th= e current standard to reject connections with unknown headers.=C2=A0=C2=A0= =C2=A0=C2=A0 So if a future version introduced such a header, it would imme= diately make new client unable to interoperate with old servers.

If we do not allow arbitrary headers, then we will severely limit our o= ptions for upgrading the protocol in the future.

=C2=A0
--001636c5bbe2659ce5048beda4ae-- From w@1wt.eu Wed Jul 21 15:51:56 2010 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 B8F573A680F for ; Wed, 21 Jul 2010 15:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=-1.486, 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 9s5JPdjCou1o for ; Wed, 21 Jul 2010 15:51:56 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 7E0493A659C for ; Wed, 21 Jul 2010 15:51:55 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LMqAIX007093 for hybi@ietf.org; Thu, 22 Jul 2010 00:52:10 +0200 Date: Thu, 22 Jul 2010 00:52:10 +0200 From: Willy Tarreau To: hybi@ietf.org Message-ID: <20100721225210.GE6475@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [hybi] Proposal for a clean way to detect non-HTTP compliant transparent proxies 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, 21 Jul 2010 22:51:56 -0000 I've just thought about a way to fix the initial handshake so that it works with proper HTTP-compliant implementations but still fails through non-compliant transparent proxies. Let's have the client send the initial handshake request to the server. This handshake is only made of HTTP headers. The client completes the request with "Connection: close" so that a transparent intermediate does not wait for a possible second request in case it does not understand the upgrade response : GET /xxxx HTTP/1.1 Upgrade: WebSocket Connection: close ... ws headers ... ... \r\n The server will send : HTTP/1.1 101 Swithing protocols Upgrade: WebSocket Content-length: 0 Connection: close ... ws headers ... ... \r\n any-form-of-hello-message (eg: the server's protocol version) That way, if a transparent proxy does not have explicit support for 101, it will only forward the headers with an empty body (CL: 0) and close the connection towards the client. The client then gets an empty response without the in-protocol HELLO message and knows that an intermediate is in the way and is not compatible. The only way for such a response to pass unmolested to the client is for intermediates to have a proper understanding of the 101/Upgrade mechanism which implies that any data after the empty line is to be tunnelled, despite Content-length: 0. It also has the nice advantage of being compatible with HTTP, which means that ISPs making use of transparent proxies will have no problem adding reliable cache-bypass rule which relies on the Upgrade: header. Any thoughts ? Willy From ian@hixie.ch Wed Jul 21 15:54:32 2010 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 16BA53A6863 for ; Wed, 21 Jul 2010 15:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 hhSBjyYBT6qG for ; Wed, 21 Jul 2010 15:54:31 -0700 (PDT) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 09A9B3A6857 for ; Wed, 21 Jul 2010 15:54:31 -0700 (PDT) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id DFC1315D577; Wed, 21 Jul 2010 15:54:47 -0700 (PDT) Date: Wed, 21 Jul 2010 22:54:47 +0000 (UTC) From: Ian Hickson To: John Tamplin In-Reply-To: Message-ID: References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 22:54:32 -0000 On Wed, 21 Jul 2010, John Tamplin wrote: > On Mon, May 17, 2010 at 5:29 AM, Maciej Stachowiak wrote: > > > > Ian has claimed that the extra bytes after the request help WebSocket > > fail early in the face of unaware proxies, though we do not yet have > > data showing this to be the case. We do know that without this, often > > the handshake will appear to succeed but transmitting messages will > > fail, for the network setups of many users. > > > > I don't think anyone has indicated a practical problem caused by the > > extra bytes. > > I believe we have already had a real-world practical case where they did > cause a problem: > > - client sends WebSocket request that goes through a proxy, random bytes > are not advertised in the Content-length > - proxy doesn't know WebSocket, passes along connection to real server > which does implement WebSocket > - server waits reading random bytes which were not forwarded > - server drops the connection after a timeout Success! :-) > Thus the random bytes did succeed in preventing a WebSocket connection > across a non-WS compliant proxy, but: > > 1. the proxy was actually capable of forwarding the connection if the > server had completed the request That's easy to resolve. The simplest solution that comes to mind is having the server send back the 101 straight away, and having the proxy send the bytes on as soon as it sees the 101. (Note: from a conformance standpoint, the "server" includes the proxy.) > 2. we had to wait for a timeout, so this was not a fast-fail situation Fast-fail is ideal, but not really necessary (there's plenty of other situations that fail very slowly). We just don't want false positives. If there's a way of tweaking the protocol so we don't get false positives, and still fulfills our other requirements, but that fails faster, that would be great. > 3. the same thing could have been more easily accomplished by having a WS > control frame exchanged at startup with similar results without > non-compliant random bytes on the wire Wouldn't that increase the startup latency by another round-trip? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From w@1wt.eu Wed Jul 21 16:03:41 2010 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 6A12E3A659C for ; Wed, 21 Jul 2010 16:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-1.454, 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 yEmD4K50DeG2 for ; Wed, 21 Jul 2010 16:03:40 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id E6DC93A6809 for ; Wed, 21 Jul 2010 16:03:39 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LN3oLB007127; Thu, 22 Jul 2010 01:03:50 +0200 Date: Thu, 22 Jul 2010 01:03:50 +0200 From: Willy Tarreau To: Ian Hickson Message-ID: <20100721230350.GF6475@1wt.eu> References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF106AD.6020506@webtide.com> 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: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 23:03:41 -0000 On Wed, Jul 21, 2010 at 10:54:47PM +0000, Ian Hickson wrote: > On Wed, 21 Jul 2010, John Tamplin wrote: > > On Mon, May 17, 2010 at 5:29 AM, Maciej Stachowiak wrote: > > > > > > Ian has claimed that the extra bytes after the request help WebSocket > > > fail early in the face of unaware proxies, though we do not yet have > > > data showing this to be the case. We do know that without this, often > > > the handshake will appear to succeed but transmitting messages will > > > fail, for the network setups of many users. > > > > > > I don't think anyone has indicated a practical problem caused by the > > > extra bytes. > > > > I believe we have already had a real-world practical case where they did > > cause a problem: > > > > - client sends WebSocket request that goes through a proxy, random bytes > > are not advertised in the Content-length > > - proxy doesn't know WebSocket, passes along connection to real server > > which does implement WebSocket > > - server waits reading random bytes which were not forwarded > > - server drops the connection after a timeout > > Success! :-) I fail to see how failing through perfectly valid components can be qualified as a success. It really seems that your goal is to ensure a general failure :-( > > Thus the random bytes did succeed in preventing a WebSocket connection > > across a non-WS compliant proxy, but: > > > > 1. the proxy was actually capable of forwarding the connection if the > > server had completed the request > > That's easy to resolve. The simplest solution that comes to mind is having > the server send back the 101 straight away, and having the proxy send the > bytes on as soon as it sees the 101. Ah goodness, it sounds like you finally got that one ! > (Note: from a conformance standpoint, the "server" includes the proxy.) as seen from the client, yes. As seen from the proxy or the server or any intermediate between them, no :-) > > 2. we had to wait for a timeout, so this was not a fast-fail situation > > Fast-fail is ideal, but not really necessary (there's plenty of other > situations that fail very slowly). We just don't want false positives. If > there's a way of tweaking the protocol so we don't get false positives, > and still fulfills our other requirements, but that fails faster, that > would be great. Please check my proposal in a separate mail. I should detect more unreliable components, work through more reliable ones and avoid one round-trip. Willy From jamie@shareable.org Wed Jul 21 16:04:31 2010 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 756FB3A6857 for ; Wed, 21 Jul 2010 16:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 TVn9BBXOhHC0 for ; Wed, 21 Jul 2010 16:04:14 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id AB4433A68F0 for ; Wed, 21 Jul 2010 16:04:08 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObiKu-0000ix-9R; Thu, 22 Jul 2010 00:04:24 +0100 Date: Thu, 22 Jul 2010 00:04:24 +0100 From: Jamie Lokier To: Ian Hickson Message-ID: <20100721230424.GC14589@shareable.org> References: <4BE5994E.4010701@webtide.com> <20100721011221.GC27243@shareable.org> 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 Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 23:04:31 -0000 Ian Hickson wrote: > On Wed, 21 Jul 2010, Jamie Lokier wrote: > > > > The use case for User-Agent, normally determined by the client > > implementation (not the application running on top of the WebSocket > > API), is to provide servers with unreliable but pragmatically useful > > information about what client implementations are using the server. > > > > It is used for profiling, for general interest, for tracking what > > clients may need to be supported if there are particular issues to be > > avoided with some clients (such as a particular message that breaks one > > of them), for tracking when clients with particular workarounds on the > > server have fallen into sufficient misuse that the workarounds can be > > removed, and for implementing specific workarounds for particular > > recognised clients. > > > > Hopefully workarounds at the WebSocket framing level are unlikely to be > > commonly needed (although that might not be true if some clients have a > > small message size limit and particular server applications have to > > format their messages to accomodate this); but User-Agent turned out to > > be quite pragmatic in HTTP for dealing with client-specific issues that > > nobody had foreseen until they were too widely deployed to ignore or > > fix. > > This seems reasonable, but it also seems like something that we should > just push to the application layer, and that we can push to the > application layer with minimal incremental cost -- and indeed with some > side-benefits, like making the handshake simpler for people who don't need > this information, like preventing the problems that occured with HTTP's > User-Agent header (such as everything saying they're Mozilla), and like > giving authors more control over exactly what they want to check for (e.g. > some might only care about the rendering engine, others might care only > about the user's screen size, and by pushing it into the application layer > we allow the subprotocol designers to decide what is important to them). I'm thinking of when the people writing the server have no relationship with the people writing applications (so they can't fix applications), and need to handle client implemention issues (not application issues). For example suppose Yahoo provided a WebSocket-based access to their public YQL query system, and suppose ten thousand authors wrote client applications to run in the major browsers, and most of those applications were cut-and-pasted by other authors who used them without understanding how they work. Then suppose it was discovered that certain rare byte sequences or other low-level thing triggered a fault in Firefox 4.2.1, due to a Firefox implementation bug, fixed in 4.2.2. (That's the sort of ugly thing which HTTP User-Agent is used to work around). And suppose 4.2.1 was widely distributed and despite 4.2.2's availability, millions of users continued to use 4.2.1 for some years. If that happened, it would be in Yahoo's interest to avoid the problematic byte sequences somehow, as transparently as possible. They couldn't alter the client applications to send the browser version; issuing advice to authors would be slow to have effect, and anyway many deployed clients would have been cut-and-pasted, so even authors updating their code would be slow to have an effect. So in the absence of anything like User-Agent, Yahoo would have to implement some kind of dirty low-level workaround affecting all clients, despite only being needed for Firefox 4.2.1. I agree there's plenty of issues with User-Agent in the HTTP world; it's no panacea. But it has been pragmatically useful for working around HTTP low-level issues, such as breaking at certain response lengths, or when claiming to support a negotiated feature but actually being broken so the offer has to be ignored. I've no correct answer for this, only the observation that User-Agent has been pragmatically helpful in HTTP, despite the "everything pretends to be Mozzilla" . However I think it's more relevant if the handshake acquires feature negotiation, specifically to ignore feature offers from WebSocket implementations that are found to have buggy implementations of features. -- Jamie From gregw@webtide.com Wed Jul 21 16:09:30 2010 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 8F0EC3A6809 for ; Wed, 21 Jul 2010 16:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 EEd4owNI7VEa for ; Wed, 21 Jul 2010 16:09:29 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 738233A6857 for ; Wed, 21 Jul 2010 16:09:29 -0700 (PDT) Received: by fxm1 with SMTP id 1so4344178fxm.31 for ; Wed, 21 Jul 2010 16:09:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.59.12 with SMTP id h12mr939146fga.67.1279753785280; Wed, 21 Jul 2010 16:09:45 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 16:09:45 -0700 (PDT) In-Reply-To: References: <068.d07026741c6694cd80652d2a7d34f236@tools.ietf.org> <4BF11920.2080307@webtide.com> <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> Date: Thu, 22 Jul 2010 09:09:45 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=000e0cd2983ac58b1d048bede5c5 Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 23:09:30 -0000 --000e0cd2983ac58b1d048bede5c5 Content-Type: text/plain; charset=UTF-8 On 22 July 2010 00:27, John Tamplin wrote: > > I'm not sold on connection reuse > Just to clearly (re)state a good use-case for connection reuse. Currently the WS handshake can only be rejected by closing the connection and discarding any potential HTTP response. Thus a webapp that wishes to fall back to a non-ws transport will have to establish a new connection, maybe negotiate TLS, then handshake the new transport. Thus there will be an extra 2 or 3 round trips to establish the fall-back transport. This is already a problem for cometd-2, as it will try WS and then fallback to long polling. I can visibly tell when establishing a chat room if I have the WS transport enabled in the client or not, because I can see the extra delays as WS is tried and fails. This will be a barrier to frameworks like cometd-2 including WS in their transport negotiations. --000e0cd2983ac58b1d048bede5c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 July 2010 00:27, John Tamplin <jat@google.com><= /span> wrote:

I'm not sold on connection reuse

Just to clearly (re)state a good use-case fo= r connection reuse.
=C2=A0
Currently the WS handshake can only be re= jected by closing the connection and discarding any potential HTTP response= .=C2=A0 Thus a webapp that wishes to fall back to a non-ws transport will h= ave to establish a new connection, maybe negotiate TLS, then handshake the = new transport.=C2=A0=C2=A0 Thus there will be an extra 2 or 3 round trips t= o establish the fall-back transport.

This is already a problem for cometd-2, as it will try WS and then fall= back to long polling.=C2=A0 I can visibly tell when establishing a chat roo= m if I have the WS transport enabled=C2=A0 in the client or not, because I = can see the extra delays as WS is tried and fails.=C2=A0=C2=A0

This will be a barrier to frameworks like cometd-2 including WS in thei= r transport negotiations.



--000e0cd2983ac58b1d048bede5c5-- From jamie@shareable.org Wed Jul 21 16:12:58 2010 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 046BC3A68A4 for ; Wed, 21 Jul 2010 16:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 mPdbwBPN1D53 for ; Wed, 21 Jul 2010 16:12:54 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id C97B03A6902 for ; Wed, 21 Jul 2010 16:12:53 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObiTM-0000lM-SG; Thu, 22 Jul 2010 00:13:08 +0100 Date: Thu, 22 Jul 2010 00:13:08 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20100721231308.GD14589@shareable.org> References: <4BE5994E.4010701@webtide.com> <20100721011221.GC27243@shareable.org> <20100721051910.GH26999@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721051910.GH26999@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org Subject: Re: [hybi] Additional HTTP headers on upgrade request? 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, 21 Jul 2010 23:12:58 -0000 Willy Tarreau wrote: > On Wed, Jul 21, 2010 at 02:12:21AM +0100, Jamie Lokier wrote: > > Ian Hickson wrote: > > > On Fri, 7 May 2010, Doug Simpkinson wrote: > > > > > > > > In draft 76, the upgrade request is said to include cookies that may be > > > > relevant, but no mention of other HTTP headers is made. > > > > > > > > What about other relevant HTTP headers such as User-Agent and > > > > Accept-Language? Shouldn't these also be sent? > > > > > > What's the use case? > > > > > > If there are clear and important use cases that are best handled by adding > > > new fields to the handshake, then we should add them. > > > > The use case for User-Agent, normally determined by the client > > implementation (not the application running on top of the WebSocket > > API), is to provide servers with unreliable but pragmatically useful > > information about what client implementations are using the server. > > > > It is used for profiling, for general interest, for tracking what > > clients may need to be supported if there are particular issues to be > > avoided with some clients (such as a particular message that breaks > > one of them), for tracking when clients with particular workarounds on > > the server have fallen into sufficient misuse that the workarounds can > > be removed, and for implementing specific workarounds for particular > > recognised clients. > > And it's used a lot to act differently with smartphones. Maybe that > could be used on the server side to try to group outgoing data into > fewer packets in order to improve user experience or reduce communication > costs. It would be nicer if the server is told what kind of communication channel is being used, rather than what kind of device it's communicating with. It's not easy, e.g. if your laptop is going via your phone's 3g, then its a 3g channel but the laptop probably doesn't know it. In the scheme of things it would be nice if proxies, such as at mobile base stations, were permitted to annotate the handshake. They _can_ do that with HTTP, using Via. It's informal but that doesn't stop it being useful - in principle. I don't know if anyone mobile system actually does that, or if any server uses the data. We really don't want to overdesign WebSocket, but ought to be room for certain particularly simple, maybe optional, things that have proven pragmatically useful before. I suspect User-Agent and Via fit into that category, even though they are messy and unreliable. But I'm not really sure. -- Jamie From jamie@shareable.org Wed Jul 21 16:23:13 2010 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 DD6893A6B0E for ; Wed, 21 Jul 2010 16:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 JCkAgn5E0TuN for ; Wed, 21 Jul 2010 16:23:13 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id F03593A6A7C for ; Wed, 21 Jul 2010 16:23:12 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObidM-0000pA-N9; Thu, 22 Jul 2010 00:23:28 +0100 Date: Thu, 22 Jul 2010 00:23:28 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20100721232328.GE14589@shareable.org> References: <8B0A9FCBB9832F43971E38010638454F03E7D06E00@SISPE7MB1.commscope.com> <20100422230957.GI13951@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E06@SISPE7MB1.commscope.com> <20100423001858.GA22326@shareable.org> <8B0A9FCBB9832F43971E38010638454F03E7D06E28@SISPE7MB1.commscope.com> <20100423103715.GB32366@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" Subject: Re: [hybi] Multiple connections serialization and proxies 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, 21 Jul 2010 23:23:14 -0000 Greg Wilkins wrote: > > On 22 July 2010 08:28, Ian Hickson <[1]ian@hixie.ch> wrote: > > There's no lack of extensibility and negotiation, both are built > into the > protocol. Future versions of the protocol can simply define new > option > fields that the client can include to announce support and that the > server > can include to announce opt-in. For example, the client could say: > Sec-WebSocket-Compression: gzip bzip2 > ...and the server might then respond with: > Sec-WebSocket-Compression: gzip > > Ian, > That will not work, because old versions of websocket are constrained > by the current standard to reject connections with unknown > headers. So if a future version introduced such a header, it > would immediately make new client unable to interoperate with old > servers. > If we do not allow arbitrary headers, then we will severely limit our > options for upgrading the protocol in the future. Ian, +1 to What Greg said. It sounds like maybe the current spec doesn't behave as you intended? The handshake must permit future clients to interop with the first widely deployed websocket servers (whatever version of the standard). That's why "wiggle room" for negotation has to be clearly present in the first version that gets significant deployment. It doesn't have to be completely arbitrary headers; it just needs to be *something* that all compliant servers ignore and future servers can recognise. -- Jamie From gregw@webtide.com Wed Jul 21 16:23:22 2010 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 40D763A6863 for ; Wed, 21 Jul 2010 16:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 KimCmPP0tetG for ; Wed, 21 Jul 2010 16:23:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 838083A6824 for ; Wed, 21 Jul 2010 16:23:20 -0700 (PDT) Received: by fxm1 with SMTP id 1so4348593fxm.31 for ; Wed, 21 Jul 2010 16:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.59.12 with SMTP id h12mr945800fga.67.1279754616703; Wed, 21 Jul 2010 16:23:36 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 16:23:36 -0700 (PDT) In-Reply-To: <20100721225210.GE6475@1wt.eu> References: <20100721225210.GE6475@1wt.eu> Date: Thu, 22 Jul 2010 09:23:36 +1000 Message-ID: From: Greg Wilkins To: Willy Tarreau Content-Type: multipart/alternative; boundary=000e0cd2983a540d6d048bee17c0 Cc: hybi@ietf.org Subject: Re: [hybi] Proposal for a clean way to detect non-HTTP compliant transparent proxies 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, 21 Jul 2010 23:23:22 -0000 --000e0cd2983a540d6d048bee17c0 Content-Type: text/plain; charset=UTF-8 Willy, if we insist on trying to fail on infrastructure that might work (even if it doesn't understand websocket), then I think this is indeed an good proposal. But I fundamentally do not agree with the premise that we should try to fail simply because our infrastructure is working, but not the way we want it to work. I don't see what this buys us - say we do establish that every bit of infrastructure between UA and server has been replaced with something shiny and new that understands websocket - does this mean that we no longer need to monitor the health of the connection and just assume that everything will magically work? No! Networks can and do fail - even shiny new ones that understand websocket. And they can fail in all sorts of nasty ways - black holes, repeated frames, horrible latencies etc etc. No matter what, any reasonable websocket based application is going to need something to monitor the health of the connection and to make a continual assessment of "it's working" vs "it's not working". Even if we could knowing that all intermediaries are websocket aware does not help this in any way, shape or form. And we can't know if all intermediaries are websocket aware: your suggestion will indeed detect a class of non-ws intermediaries, but there will also be other ones that are semi-HTTP away but don't respect Connection:close or that operate at TCP/IP level etc. Currently the protocol is designed to try to fail and only work if everything is perfect. I think we should instead make it try to work and fail only if there is a problem. regards On 22 July 2010 08:52, Willy Tarreau wrote: > > I've just thought about a way to fix the initial handshake so that it > works with proper HTTP-compliant implementations but still fails through > non-compliant transparent proxies. > > Let's have the client send the initial handshake request to the server. > This handshake is only made of HTTP headers. The client completes the > request with "Connection: close" so that a transparent intermediate > does not wait for a possible second request in case it does not understand > the upgrade response : > > GET /xxxx HTTP/1.1 > Upgrade: WebSocket > Connection: close > ... ws headers ... > ... > \r\n > > The server will send : > > HTTP/1.1 101 Swithing protocols > Upgrade: WebSocket > Content-length: 0 > Connection: close > ... ws headers ... > ... > \r\n > any-form-of-hello-message (eg: the server's protocol version) > > That way, if a transparent proxy does not have explicit support for 101, > it will only forward the headers with an empty body (CL: 0) and close the > connection towards the client. > > The client then gets an empty response without the in-protocol HELLO > message and knows that an intermediate is in the way and is not compatible. > > The only way for such a response to pass unmolested to the client is > for intermediates to have a proper understanding of the 101/Upgrade > mechanism which implies that any data after the empty line is to be > tunnelled, despite Content-length: 0. > > It also has the nice advantage of being compatible with HTTP, which > means that ISPs making use of transparent proxies will have no problem > adding reliable cache-bypass rule which relies on the Upgrade: header. > > Any thoughts ? > > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd2983a540d6d048bee17c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Willy,

if we insist on trying to fail on infrastructure that mig= ht work (even if it doesn't understand
websocket), then I think this= is indeed an good proposal.

But I fundamentally do not agree with t= he premise that we should try to fail simply
because our infrastructure is working, but not the way we want it to work.<= br>
I don't see what this buys us - say we do establish that every b= it of infrastructure between UA and server has been replaced with something= shiny and new that understands websocket - does this mean that we no longe= r need to monitor the health of the connection and just assume that everyth= ing will magically work?=C2=A0=C2=A0=C2=A0

No!

Networks can and do fail - even shiny new ones that understa= nd websocket.=C2=A0 And they can fail in all sorts of nasty ways - black ho= les, repeated frames, horrible latencies etc etc.

No matter what, an= y reasonable websocket based application is going to need something to moni= tor the health of the connection and to make a continual assessment of &quo= t;it's working" vs "it's not working".=C2=A0=C2=A0= =C2=A0=C2=A0 Even if we could knowing that all intermediaries are websocket= aware does not help this in any way, shape or form.=C2=A0 And we can't= know if all intermediaries are websocket aware: your suggestion will indee= d detect a class of non-ws intermediaries, but there will also be other one= s that are semi-HTTP away but don't respect Connection:close or that op= erate at TCP/IP level etc.

Currently the protocol is designed to try to fail and only work if ever= ything is perfect.
I think we should instead make it try to work and fai= l only if there is a problem.

regards











On 22 July 2010 08:52, Willy= Tarreau <w@1wt.eu>= wrote:

I've just thought about a way to fix the initial handshake so that it works with proper HTTP-compliant implementations but still fails through non-compliant transparent proxies.

Let's have the client send the initial handshake request to the server.=
This handshake is only made of HTTP headers. The client completes the
request with "Connection: close" so that a transparent intermedia= te
does not wait for a possible second request in case it does not understand<= br> the upgrade response :

=C2=A0 GET /xxxx HTTP/1.1
=C2=A0 Upgrade: WebSocket
=C2=A0 Connection: close
=C2=A0 ... ws headers ...
=C2=A0 ...
=C2=A0 \r\n

The server will send :

=C2=A0 HTTP/1.1 101 Swithing protocols
=C2=A0 Upgrade: WebSocket
=C2=A0 Content-length: 0
=C2=A0 Connection: close
=C2=A0 ... ws headers ...
=C2=A0 ...
=C2=A0 \r\n
=C2=A0 any-form-of-hello-message (eg: the server's protocol version)
That way, if a transparent proxy does not have explicit support for 101, it will only forward the headers with an empty body (CL: 0) and close the connection towards the client.

The client then gets an empty response without the in-protocol HELLO
message and knows that an intermediate is in the way and is not compatible.=

The only way for such a response to pass unmolested to the client is
for intermediates to have a proper understanding of the 101/Upgrade
mechanism which implies that any data after the empty line is to be
tunnelled, despite Content-length: 0.

It also has the nice advantage of being compatible with HTTP, which
means that ISPs making use of transparent proxies will have no problem
adding reliable cache-bypass rule which relies on the Upgrade: header.

Any thoughts ?

Willy

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

--000e0cd2983a540d6d048bee17c0-- From mike@belshe.com Wed Jul 21 16:28:23 2010 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 5D3113A6863 for ; Wed, 21 Jul 2010 16:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 t8s1Jo+wk0YN for ; Wed, 21 Jul 2010 16:28:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id B285B3A695F for ; Wed, 21 Jul 2010 16:28:21 -0700 (PDT) Received: by pzk6 with SMTP id 6so3481063pzk.31 for ; Wed, 21 Jul 2010 16:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.12 with SMTP id f12mr1178638wfh.19.1279754918195; Wed, 21 Jul 2010 16:28:38 -0700 (PDT) Received: by 10.142.75.9 with HTTP; Wed, 21 Jul 2010 16:28:38 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> Date: Wed, 21 Jul 2010 16:28:38 -0700 Message-ID: From: Mike Belshe To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd244104c73c1048bee2910 Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 23:28:23 -0000 --000e0cd244104c73c1048bee2910 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 21, 2010 at 3:17 PM, Ian Hickson wrote: > On Tue, 20 Jul 2010, John Tamplin wrote: > > On Tue, Jul 20, 2010 at 6:14 PM, Ian Hickson wrote: > > > > > > What I'm interested in personally is writing a protocol that amateur > > > programmers can implement easily. If we say they have to use someone > > > else's code to do this, then that's a failure, IMHO. (Though as I've > > > mentioned before, if people have different goals or priorities, I have > > > no problem with separate protocols also being designed to address > > > those -- Web Sockets doesn't have to be everything for everybody.) > > > > I still don't see the argument for servers written by amateurs. I have > > used far more quick-and-dirty web clients (telnet, socket/connect/write > > in C, wget/curl, etc) than I have quick-and-dirty servers. > > That's largely because most protocols are such that you can't make a > compliant server quickly. The one exception (which isn't a network > protocol but is relatively similar for the purposes of this discussion) is > CGI. That's a simple protocol, and there are many implementations of the > server side of the protocol (that is, CGI scripts; the HTTP server is the > client of the CGI protocol). Now, most people use libraries, of course, > and that's fine. But the protocol is simple enough that you don't _have_ > to use a library, and some people don't. > > > > If some amateur needs to write a server anyway, they aren't going to > > write it from scratch even if it were possible for them to do so -- they > > will find some library. > > Yes, for most existing protocols that is the sad reality. I think that's a > failure on our part (the part of protocol designers). We can enable much > greater experimentation, innovation, learning, and so forth, if we make > lower the bar to the level of CGI scripts rather than keeping it at the > level of HTTP servers. > > > > Contrast this with embedded clients, which might well have tighter > > constraints than most clients, and could benefit from having optional > > features they could leave out that would be useful for more powerful > > clients. Meanwhile, the servers are going to almost certainly be on > > more powerful machines, though granted they have more connections to > > support. > > In the case of Web Sockets, most clients (by usage) are going to be Web > browsers, so if we are forced to put complexity into the protocol, we > should move it to the browser side. But in general we should keep that > side simple too, so that custom clients can also be written. > > > On Wed, 21 Jul 2010, Jamie Lokier wrote: > > > > All that's needed, for amateur programmer compatibility, is for the > > "complex" performance-enhancing features to be optional negotiated > > features on top of an extremely simple base protocol. And for the > > negotiation to be really simple too. > > Once the protocol is proven, I think it would make sense to add optional > features. The protocol is designed to make that easy for us. > > > On Tue, 20 Jul 2010, Roberto Peon wrote: > > > > We need browser-owned connections with a security model that allows > multiple > > tabs to share the connection safely. > > This is probably the most important requirement for scalability as far as > > I'm concerned. This requires fewer keep-alives (both because of fewer TCP > > connections and because the TCP connection is more likely to have real > > content sent on it instead of near-zero value'd keep-alives), it requires > > fewer file descriptors, it requires fewer handshakes. > > This is pretty easily implemented at the application layer using shared > workers. > > > On Tue, 20 Jul 2010, Mike Belshe wrote: > > > > For as adamantly as Ian states that it should be a requirement, I am > > just as adamant that it should not. > > It's quite possible that this working group should be working on two (or > more) protocols, rather than trying to solve all our problems with Web > Sockets. Or it could be that Web Sockets isn't the right solution for the > problems that most people in this working group are trying to solve. > > Web Sockets is a trivially-implementable TCP-for-browsers protocol for > long-lived connections. If that doesn't sound like the protocol you need, > then you need a different protocol. If that isn't the protocol this > working group wants, then this working group wants another protocol. I > don't think there's anything wrong with that, but then we should work on > that protocol, not Web Sockets. > > > > But more importantly, this single issue has been holding protocol > > progress hostage. Naturally, any feature has some amount of complexity. > > But this requirement creates an invisible, and subjective barrier to > > each feature. Is the feature too complex for an amateur programmer? > > Nobody knows, and everyone disagrees, because it is a subjective > > criteria. So we spin and can't agree. > > I disagree that the protocol's development has been in any way held up by > this. I agree that we've talked about it a lot in the working group, but > the spec itself hasn't been affected by this as far as I can tell. > To be specific, our earlier discussions about error handling, large frames, and binary frames were all cut short under the "too hard for amateur programmers". Based on the +1s in this thread, I think many agree that this has occurred. I don't yet know if we mostly agree that amateur programmers is not an overriding criteria, so how do we decide? Can we get a group decision on that now? Once we have a decision on that, we can finish looking at the other issues on the table. If we agree that "amateur programmer support" is not a feature, then it cannot be held up as an argument for or against any proposed solution once we've decided upon it. Or, if it is a priority, then we should weigh all proposed changes against it to ensure that the requirement is met. Can we call a vote on this issue alone and settle it? Chair-people, can you offer guidance? Without a decision on the importance of this issue, I know we'll go circular again when deciding on other issues. > > > Every protocol expert I've spoken with agrees that amateur protocol > > implementors should not be a requirement. > > And what did the protocol amateurs you spoke to say? It seems unsurprising > that people whose careers are based on being able to solve complicated > protocol problems should want protocols to be complicated. > I have yet to meet anyone that wants the protocol to be complicated, so please don't say that I asked for that. What I asked for is that the protocol not be constrained by the need to be implemented by "amateur programmers". Mike > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd244104c73c1048bee2910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 21, 2010 at 3:17 PM, Ian Hic= kson <ian@hixie.ch= > wrote:
On Tue, 20 Jul 2010, John Tamplin wrote:
> On Tue, Jul 20, 2010 at 6:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > What I'm interested in personally is = writing a protocol that amateur
> > programmers can implement easily. If we say they have to use some= one
> > else's code to do this, then that's a failure, IMHO. (Tho= ugh as I've
> > mentioned before, if people have different goals or priorities, I= have
> > no problem with separate protocols also being designed to address=
> > those -- Web Sockets doesn't have to be everything for everyb= ody.)
>
> I still don't see the argument for servers= written by amateurs. =A0I have
> used far more quick-and-dirty web clients (telnet, socket/connect/writ= e
> in C, wget/curl, etc) than I have quick-and-dirty servers.

That's largely because most protocols are such that you can't= make a
compliant server quickly. The one exception (which isn't a network
protocol but is relatively similar for the purposes of this discussion) is<= br> CGI. That's a simple protocol, and there are many implementations of th= e
server side of the protocol (that is, CGI scripts; the HTTP server is the client of the CGI protocol). Now, most people use libraries, of course,
and that's fine. But the protocol is simple enough that you don't _= have_
to use a library, and some people don't.


> If some amateur needs to write a server anyway, they aren't going = to
> write it from scratch even if it were possible for them to do so -- th= ey
> will find some library.

Yes, for most existing protocols that is the sad reality. I think tha= t's a
failure on our part (the part of protocol designers). We can enable much greater experimentation, innovation, learning, and so forth, if we make
lower the bar to the level of CGI scripts rather than keeping it at the
level of HTTP servers.



> Contrast this with embedded clients, which might well have tighter
> constraints than most clients, and could benefit from having optional<= br> > features they could leave out that would be useful for more powerful > clients. =A0Meanwhile, the servers are going to almost certainly be on=
> more powerful machines, though granted they have more connections to > support.

In the case of Web Sockets, most clients (by usage) are going to be W= eb
browsers, so if we are forced to put complexity into the protocol, we
should move it to the browser side. But in general we should keep that
side simple too, so that custom clients can also be written.



On Wed, 21 Jul 2010, Jamie Lokier wrote:
>
> All that's needed, for amateur programmer compatibility, is for th= e
> "complex" performance-enhancing features to be optional nego= tiated
> features on top of an extremely simple base protocol. =A0And for the > negotiation to be really simple too.

Once the protocol is proven, I think it would make sense to add optio= nal
features. The protocol is designed to make that easy for us.


On Tue, 20 Jul 2010, Roberto Peon wrote:
>
> We need browser-owned connections with a security model that allows mu= ltiple
> tabs to share the connection safely.
> This is probably the most important requirement for scalability as far= as
> I'm concerned. This requires fewer keep-alives (both because of fe= wer TCP
> connections and because the TCP connection is more likely to have real=
> content sent on it instead of near-zero value'd keep-alives), it r= equires
> fewer file descriptors, it requires fewer handshakes.

This is pretty easily implemented at the application layer using shar= ed
workers.


On Tue, 20 Jul 2010, Mike Belshe wrote:
>
> For as adamantly as Ian states that it should be a requirement, I am > just as adamant that it should not.

It's quite possible that this working group should be working on = two (or
more) protocols, rather than trying to solve all our problems with Web
Sockets. Or it could be that Web Sockets isn't the right solution for t= he
problems that most people in this working group are trying to solve.

Web Sockets is a trivially-implementable TCP-for-browsers protocol for
long-lived connections. If that doesn't sound like the protocol you nee= d,
then you need a different protocol. If that isn't the protocol this
working group wants, then this working group wants another protocol. I
don't think there's anything wrong with that, but then we should wo= rk on
that protocol, not Web Sockets.


> But more importantly, this single issue has been holding protocol
> progress hostage. =A0Naturally, any feature has some amount of complex= ity.
> But this requirement creates an invisible, and subjective barrier to > each feature. Is the feature too complex for an amateur programmer? > Nobody knows, and everyone disagrees, because it is a subjective
> criteria. =A0So we spin and can't agree.


I disagree that the protocol's development has been in any way he= ld up by
this. I agree that we've talked about it a lot in the working group, bu= t
the spec itself hasn't been affected by this as far as I can tell.
<= /blockquote>

To be specific, our earlier discussions abo= ut error handling, large frames, and binary frames were all cut short under= the "too hard for amateur programmers".

Based on the +1s in this thread, I think many agree tha= t this has occurred. =A0I don't yet know if we mostly agree that amateu= r programmers is not an overriding criteria, so how do we decide? =A0Can we= get a group decision on that now?

Once we have a decision on that, we can finish looking = at the other issues on the table. =A0If we agree that "amateur program= mer support" is not a feature, then it cannot be held up as an argumen= t for or against any proposed solution once we've decided upon it. =A0O= r, if it is a priority, then we should weigh all proposed changes against i= t to ensure that the requirement is met.

Can we call a vote on this issue alone and settle it? = =A0Chair-people, can you offer guidance? =A0Without a decision on the impor= tance of this issue, I know we'll go circular again when deciding on ot= her issues.





> Every protocol expert I've spoken with agrees that amateur protoco= l
> implementors should not be a requirement.

And what did the protocol amateurs you spoke to say? It seems unsurpr= ising
that people whose careers are based on being able to solve complicated
protocol problems should want protocols to be complicated.
=

I have yet to meet anyone that wants the protocol to be= complicated, so please don't say that I asked for that. =A0What I aske= d for is that the protocol not be constrained by the need to be implemented= by "amateur programmers".

Mike
=A0

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 = =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0)\._.,--....,'``. =A0 = =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--000e0cd244104c73c1048bee2910-- From gregw@webtide.com Wed Jul 21 16:32:07 2010 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 0C3C43A6B0E for ; Wed, 21 Jul 2010 16:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 jUFCjMVwX2IN for ; Wed, 21 Jul 2010 16:32:05 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 19DF93A68F0 for ; Wed, 21 Jul 2010 16:32:04 -0700 (PDT) Received: by fxm1 with SMTP id 1so4351332fxm.31 for ; Wed, 21 Jul 2010 16:32:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.110.67 with SMTP id m3mr1090985fap.24.1279755141302; Wed, 21 Jul 2010 16:32:21 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 16:32:21 -0700 (PDT) In-Reply-To: References: <4C1F3F93.2020805@ericsson.com> Date: Thu, 22 Jul 2010 09:32:21 +1000 Message-ID: From: Greg Wilkins To: Ian Hickson Content-Type: multipart/alternative; boundary=001636c9246e98c9c8048bee361a Cc: hybi@ietf.org Subject: Re: [hybi] HyBi WG update 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, 21 Jul 2010 23:32:07 -0000 --001636c9246e98c9c8048bee361a Content-Type: text/plain; charset=UTF-8 On 22 July 2010 08:44, Ian Hickson wrote: > On Wed, 21 Jul 2010, L.Wood@surrey.ac.uk wrote: > > > > You don't need implementers implementing from the latest revision of the > > draft. > > > > You need implementers implementing from a _considered_ version of the > > draft, and a fixed referencable point at that. > > Sure, but given that implementers are going to implement the spec > regardless, I'd much rather they implemented the latest version, with all > the bugs removed, rather than a version that we _know_ is buggy. > How can anybody implement a constantly moving target into which discussed speculative ideas are added? Regardless - I think you are confusing two concerns. Discussions about how to design the websocket protocol are free to occur anywhere in any forum what so ever. However, discussions about the IETF draft protocol specification document should either occur on the IETF list or be summarized on the list. Changes to the draft should be discussed on list and peer reviewed before they are put into the next version of the draft. When acting as an IETF editor, you should be acting as a tech writer and not as a tech designer. --001636c9246e98c9c8048bee361a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 July 2010 08:44, Ian Hickson <ian@hixie.ch> wrote:
On Wed, 21 Jul 2010, L.Wood@surrey.ac.uk wrote:
>
> You don't need implementers implementing from the latest revision = of the
> draft.
>
> You need implementers implementing from a _considered_ version of the<= br> > draft, and a fixed referencable point at that.

Sure, but given that implementers are going to implement the spec
regardless, I'd much rather they implemented the latest version, with a= ll
the bugs removed, rather than a version that we _know_ is buggy.

How can anybody implement a constant= ly moving target into which discussed speculative ideas are added?

Regardless - I think you are confusing two concerns.=C2=A0=C2=A0=C2=A0 Disc= ussions about how to design the websocket protocol are free to occur anywhe= re in any forum what so ever.

However, discussions about the IETF dr= aft protocol specification document should either occur on the IETF list or= be summarized on the list.=C2=A0=C2=A0=C2=A0 Changes to the draft should b= e discussed on list and peer reviewed before they are put into the next ver= sion of the draft.=C2=A0=C2=A0 When acting as an IETF editor, you should be= acting as a tech writer and not as a tech designer.






--001636c9246e98c9c8048bee361a-- From jamie@shareable.org Wed Jul 21 16:36:52 2010 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 909643A6824 for ; Wed, 21 Jul 2010 16:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 aE3LGa2L6kYt for ; Wed, 21 Jul 2010 16:36:51 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 6F91F3A6809 for ; Wed, 21 Jul 2010 16:36:51 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObiqY-0000tr-2A; Thu, 22 Jul 2010 00:37:06 +0100 Date: Thu, 22 Jul 2010 00:37:06 +0100 From: Jamie Lokier To: Roberto Peon Message-ID: <20100721233706.GF14589@shareable.org> References: <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> 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" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 23:36:52 -0000 Roberto Peon wrote: > > On Tue, Jul 20, 2010 at 11:47 PM, Ian Hickson <[1]ian@hixie.ch> wrote: > > On Wed, 19 May 2010, Jamie Lokier wrote: > > > > > > If we want to support multiple subprotocols at once, we can do so > > > quite easily by just making the subprotocol list be > comma-separated. > > > Would this be a good idea? > > > > I think it is a good idea, although there is a risk of low-quality > > server but significant implementations matching a literal string, > > breaking when other values are added to the comma-separate list, and > > therefore making it impossible for clients to actually use the > > capability. > > Yeah, though since that bug would be specific to implementations of > particular subprotocols, it would be pretty localised to individual > communities. That's probably an acceptable problem. Fwiw, this has happened before in generic HTTP clients, including some major browsers, so it wasn't localised to particular communities. I guess requiring "Connection: close" to be literally that without anything else on the line has gone away now :-) But I'm still not sure if there are HTTP clients/servers in use which would match ",somekeyword," inside a quoted string in a HTTP header where such things aren't meant to be matched... > > But assuming the comma-separated list did catch on, a consequence of > > that would be the "below the API" part of WebSocket would have a > place > > to add its own distinct entries to the comma-separated list, for > > recognition by the other side as transport option requests (such as > > compression, etc.), safe in the knowledge it wouldn't break > negotiation. > > > > (Separate headers would be much cleaner for that, though). > > I don't see why we wouldn't just use separate fields for that. No > need to overload the subprotocol field. It cannot use the subprotocol field if the *current* spec gets significantly deployed, because the client Javascript sets the subprotocol field, and the server is entitled to expect to get *exactly* what the client Javascript sets. That means WebSocket client implementations cannot transparently append comma-separated keywords to the subprotocol field without breaking expectations. I really hope we sort out feature negotation before there's any significant deployment. We should also keep in mind that "below the API" isn't always going to be a clear line. Some protocol features may be implementable above or below the Javascript API, according to client capabilities, and some might be implemented in a WS-aware proxy away from the browser (for example keepalive modifications when crossing between different network types). -- Jamie From gregw@webtide.com Wed Jul 21 16:38:16 2010 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 5BE0D3A6809 for ; Wed, 21 Jul 2010 16:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 TQvb4m5In9OG for ; Wed, 21 Jul 2010 16:38:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3CF603A6824 for ; Wed, 21 Jul 2010 16:38:15 -0700 (PDT) Received: by fxm1 with SMTP id 1so4353369fxm.31 for ; Wed, 21 Jul 2010 16:38:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.124.9 with SMTP id s9mr1018192far.91.1279755511380; Wed, 21 Jul 2010 16:38:31 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 16:38:31 -0700 (PDT) In-Reply-To: References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> Date: Thu, 22 Jul 2010 09:38:31 +1000 Message-ID: From: Greg Wilkins To: Mike Belshe Content-Type: multipart/alternative; boundary=001636c5b55ca7b9f9048bee4ca8 Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 21 Jul 2010 23:38:16 -0000 --001636c5b55ca7b9f9048bee4ca8 Content-Type: text/plain; charset=UTF-8 On 22 July 2010 09:28, Mike Belshe wrote: > To be specific, our earlier discussions about error handling, large frames, > and binary frames were all cut short under the "too hard for amateur > programmers". > > ... and it was not just that. This list woke up again and was just starting to make some good technical discussions..... Then all of a sudden the whole conversation is back to talking about amateur programmers, HTTP-like handshakes, no extensions unapproved by central control, what do you mean I can't edit the draft 37 times a day? do we really need to talk about changes first when it is so obvious to me that I'm right... welcome to Hybi ground hog day! --001636c5b55ca7b9f9048bee4ca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 22 July 2010 09:28, Mike Belshe <mike@belshe.com>= wrote:
To be specific, our earlier discussions abo= ut error handling, large frames, and binary frames were all cut short under= the "too hard for amateur programmers".


... and it was not just that.=C2=A0 This list woke u= p again and was just starting to make some good technical discussions.....= =C2=A0 Then all of a sudden the whole conversation is back to talking about= amateur programmers, HTTP-like handshakes, no extensions unapproved by cen= tral control, what do you mean I can't edit the draft 37 times a day? d= o we really need to talk about changes first when it is so obvious to me th= at I'm right...

welcome to Hybi ground hog day!


--001636c5b55ca7b9f9048bee4ca8-- From jamie@shareable.org Wed Jul 21 16:38:26 2010 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 D89B33A6902 for ; Wed, 21 Jul 2010 16:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 sbk1dP7o2DmW for ; Wed, 21 Jul 2010 16:38:25 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 5994A3A6809 for ; Wed, 21 Jul 2010 16:38:25 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Obiry-0000uQ-At; Thu, 22 Jul 2010 00:38:34 +0100 Date: Thu, 22 Jul 2010 00:38:34 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20100721233834.GG14589@shareable.org> References: <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> <20100721151531.GA2990@1wt.eu> <20100721154519.GA3243@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721154519.GA3243@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 21 Jul 2010 23:38:27 -0000 Willy Tarreau wrote: > On Wed, Jul 21, 2010 at 08:22:11AM -0700, Roberto Peon wrote: > > I believe Mike quoted numbers in an earlier thread. > > > > Just to be sure we're talking about the same thing, I'm talking about the > > UPGRADE feature of HTTP generically, and not as it applies to the current > > draft Websocket spec. > > I thought they were related to the current version since it also uses > Upgrade. Anyway, even if some don't support it yet, it will be easy > to detect bypass them based on simple rules. Um, will it? How would that work? -- Jamie From mike@belshe.com Wed Jul 21 16:42:34 2010 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 D98383A687C for ; Wed, 21 Jul 2010 16:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 GLrhoxH71BTc for ; Wed, 21 Jul 2010 16:42:33 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B5DB93A685B for ; Wed, 21 Jul 2010 16:42:31 -0700 (PDT) Received: by pxi20 with SMTP id 20so4196747pxi.31 for ; Wed, 21 Jul 2010 16:42:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.211.5 with SMTP id j5mr1168718wfg.155.1279755768043; Wed, 21 Jul 2010 16:42:48 -0700 (PDT) Received: by 10.142.75.9 with HTTP; Wed, 21 Jul 2010 16:42:47 -0700 (PDT) In-Reply-To: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> Date: Wed, 21 Jul 2010 16:42:47 -0700 Message-ID: From: Mike Belshe To: Ian Hickson Content-Type: multipart/alternative; boundary=000e0cd22e2af4197b048bee5b97 Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 23:42:35 -0000 --000e0cd22e2af4197b048bee5b97 Content-Type: text/plain; charset=ISO-8859-1 On the TLS issue, we're going in circles. Both sides are correct on the facts about the pros and cons of TLS (more or less). I don't think the spec should require TLS. But, would it be possible to define alternate handshakes based on whether TLS is used? If we use the currently defined handshake, TLS will be at a performance disadvantage to insecure WebSockets, because TLS will require more round-trips. Could we define, as part of the WebSocket protocol, that when WebSocket is negotiated over TLS it uses the TLS/NPN extension to effectively fold the WebSocket Upgrade handshake into the TLS handshake? This removes a round trip from the WebSocket startup time. The next-protocol-negotiation extension is defined here: http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00 If we don't do this, websites in the future will be discouraged from using secure websockets because secure websockets will be slower than insecure ones. By contrast, with the improvements in TLS (if they come to fruition), if WebSockets defines a mechanism for hanshaking over TLS/NPN, WebSockets over TLS will negotiate with fewer round trips than WebSockets over HTTP. Hopefully this will encourage more use of the secure facility, without making it a requirement for those that really don't want it. Mike On Wed, Jul 21, 2010 at 3:47 PM, Ian Hickson wrote: > On Wed, 21 Jul 2010, Maciej Stachowiak wrote: > > > > In my opinion, to the extent we support intermediaries, the design > > should require at least one of the client or server to be explicitly > > aware of the intermediary. > > Agreed. I think we should add this to the requirements. > > > > We should not support magical transparent intermediaries where neither > > the client nor server has an obvious way to detect its existence; in > > fact we should design the protocol to prevent such intermediaries from > > being created. > > The only way I can see to do this would be to require TLS (or some > equivalent asymmetric encryption scheme), which I think is too high a > cost. Otherwise, in principle, I agree with this too. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd22e2af4197b048bee5b97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On the TLS issue, we're going in circles. =A0Both sides are correct on = the facts about the pros and cons of TLS (more or less). =A0I don't thi= nk the spec should require TLS. =A0But, would it be possible to define alte= rnate handshakes based on whether TLS is used?

If we use the currently defined handshake, TLS will be at a = performance disadvantage to insecure WebSockets, because TLS will require m= ore round-trips.

Could we define, as part of the WebSocket pr= otocol, that when WebSocket is negotiated over TLS it uses the TLS/NPN exte= nsion to effectively fold the WebSocket Upgrade handshake into the TLS hand= shake? =A0This removes a round trip from the WebSocket startup time. =A0The= next-protocol-negotiation extension is defined here: =A0http://tools.ietf.org/ht= ml/draft-agl-tls-nextprotoneg-00

If we don't do this, websites in the future will be= discouraged from using secure websockets because secure websockets will be= slower than insecure ones. =A0By contrast, with the improvements in TLS (i= f they come to fruition), if WebSockets defines a mechanism for hanshaking = over TLS/NPN, WebSockets over TLS will negotiate with fewer round trips tha= n WebSockets over HTTP. =A0Hopefully this will encourage more use of the se= cure facility, without making it a requirement for those that really don= 9;t want it.
<= /a>
Mike

On Wed, Jul 21, 2010 at 3:47= PM, Ian Hickson <ian@= hixie.ch> wrote:
On Wed, 21 Jul 2010, Maci= ej Stachowiak wrote:
>
> In my opinion, to the extent we support intermediaries, the design
> should require at least one of the client or server to be explicitly > aware of the intermediary.

Agreed. I think we should add this to the requirements.


> We should not support magical transparent intermediaries where neither=
> the client nor server has an obvious way to detect its existence; in > fact we should design the protocol to prevent such intermediaries from=
> being created.

The only way I can see to do this would be to require TLS (or some equivalent asymmetric encryption scheme), which I think is too high a
cost. Otherwise, in principle, I agree with this too.

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'
_______________________________________________

--000e0cd22e2af4197b048bee5b97-- From gregw@webtide.com Wed Jul 21 16:46:37 2010 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 7B5C23A68A4 for ; Wed, 21 Jul 2010 16:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 AIDzjjrh+c+6 for ; Wed, 21 Jul 2010 16:46:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 76C143A687C for ; Wed, 21 Jul 2010 16:46:36 -0700 (PDT) Received: by fxm1 with SMTP id 1so4356161fxm.31 for ; Wed, 21 Jul 2010 16:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.104.7 with SMTP id m7mr1128510fao.8.1279756012578; Wed, 21 Jul 2010 16:46:52 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 16:46:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Jul 2010 09:46:52 +1000 Message-ID: From: Greg Wilkins To: Ian Hickson Content-Type: multipart/alternative; boundary=001636c5966c876963048bee6a16 Cc: hybi@ietf.org Subject: Re: [hybi] Authentication headers 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, 21 Jul 2010 23:46:37 -0000 --001636c5966c876963048bee6a16 Content-Type: text/plain; charset=UTF-8 On 21 July 2010 17:01, Ian Hickson wrote: > Cookies are supported because they are > _very_ widely used, so there's something to reuse. HTTP auth is used so > rarely that I'd seriously consider dropping it from HTTP at this point; I > really don't think it's worth adding to WebSockets. > HTTP headers are frequently used for authentication mechanisms that are neither the standard HTTP ones, nor plain simple cookies. For example many OAUTH implementations allow tokens to be negotiated using HTTP headers. Sure there are other ways than using headers, but the fact remains that many implementations do use headers and I see no reason to break those implementation nor prevent their usage with websocket. --001636c5966c876963048bee6a16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 21 July 2010 17:01, Ian Hickson <ian@hixie.ch> wrote:
=C2=A0Cookies are supported because they are
_very_ widely used, so there's something to reuse. HTTP auth is used so=
rarely that I'd seriously consider dropping it from HTTP at this point;= I
really don't think it's worth adding to WebSockets.


HTTP headers are frequently used for authentication mechanism= s that are neither the standard HTTP ones, nor plain simple cookies. For ex= ample many OAUTH implementations allow tokens to be negotiated using HTTP h= eaders.

Sure there are other ways than using headers, but the fact remains that= many implementations do use headers and I see no reason to break those imp= lementation nor prevent their usage with websocket.



=C2=A0
--001636c5966c876963048bee6a16-- From w@1wt.eu Wed Jul 21 16:46:41 2010 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 C39BC3A695E for ; Wed, 21 Jul 2010 16:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-1.423, 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 DelPfSbatRFM for ; Wed, 21 Jul 2010 16:46:40 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 2CE933A687C for ; Wed, 21 Jul 2010 16:46:40 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6LNksxO007361; Thu, 22 Jul 2010 01:46:54 +0200 Date: Thu, 22 Jul 2010 01:46:54 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100721234654.GA7174@1wt.eu> References: <20100721225210.GE6475@1wt.eu> 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: hybi@ietf.org Subject: Re: [hybi] Proposal for a clean way to detect non-HTTP compliant transparent proxies 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, 21 Jul 2010 23:46:41 -0000 Hi Greg, On Thu, Jul 22, 2010 at 09:23:36AM +1000, Greg Wilkins wrote: > Willy, > > if we insist on trying to fail on infrastructure that might work (even if it > doesn't understand websocket), then I think this is indeed an good proposal. Please note that I'm deliberately checking if the connection is HTTP-compliant enough so that we can use it for WS, I'm not trying to see if there are WS-specific crap implemented half-way. Assuming that we finally fix the handshake to be HTTP-compliant, we just need from the intermediates to support Upgrade+101, nothing else. > But I fundamentally do not agree with the premise that we should try to fail > simply > because our infrastructure is working, but not the way we want it to work. Indeed, I don't either and that's what I hate in the current handshake : standard-compliant components fail while the most crappy and insecure devices will still work. > I don't see what this buys us - say we do establish that every bit of > infrastructure between UA and server has been replaced with something shiny > and new that understands websocket - does this mean that we no longer need > to monitor the health of the connection and just assume that everything will > magically work? > > No! No, that's not what I'm saying at all. I'm making a big distinction between detecting compatibility during handshake and detecting end-to-end link reliability during communications, which should involve regular keep-alives. > Networks can and do fail - even shiny new ones that understand websocket. > And they can fail in all sorts of nasty ways - black holes, repeated frames, > horrible latencies etc etc. ... and silent timeouts ! 100% agreed, and that's my every day job to spot such issues too. That's why I'm a lot in favor of supporting some keep-alives or "ping" messages. In fact all my SSH clients and servers have such keep-alives enabled for a reason ;-) > No matter what, any reasonable websocket based application is going to need > something to monitor the health of the connection and to make a continual > assessment of "it's working" vs "it's not working". Agreed too. > Even if we could > knowing that all intermediaries are websocket aware does not help this in > any way, shape or form. And we can't know if all intermediaries are > websocket aware: your suggestion will indeed detect a class of non-ws > intermediaries, but there will also be other ones that are semi-HTTP away > but don't respect Connection:close or that operate at TCP/IP level etc. In fact, the ones that act at TCP/IP level are currently the most likely to work despite their incomplete support for HTTP, because they either have support for content-length (for the high-end ones) or simply switch to tunneled mode after the request where both sides can freely exchange. That was how the first versions of haproxy did work, that was how Alteon did work for a lot of time, this is the most naive approach but it freely supports POST and CONNECT methods, so that makes it implicitly compatible with upgrade+101. The really nasty ones (we still have to get ones pointed out) are the ones which would not understand 101 and still forward the response to the client but not the data. That's what my proposal tries to spot in an HTTP-compatible manner. > Currently the protocol is designed to try to fail and only work if > everything is perfect. > I think we should instead make it try to work and fail only if there is a > problem. 100% agree here too. Also, some "ping" type messages will help spot another class of hard to debug network issues : the small MTU paths. It happens that due to poor VLAN or PPPoE settings on some equipment, some devices can't receive full-sized ethernet frames and will silently drop them. It's not easily spotted at all from either end, since it rarely strikes. That would mean that a long connection could work for some time then suddenly block during a larger exchange. For instance because the client is resending aggregated TCP segments after a few drops, or because the user has performed a copy-paste of some text in a box. Neither side will be able to spot this. The client will fill system buffers and the server will wait for the client to talk. A "ping" would notice this quickly because it would simply not get any response due to the segment that cannot go through. For the same reason such a "ping" would also detect broken connections caused by firewall timeouts, NAT gateways, local IP address changes, etc... So I'm all in favor of that, and I agree that my proposal doesn't address these issues. It just helps quickly detecting if we can use WS over a path or switch to something else without having the user wait for ages. Regards, Willy From gregw@webtide.com Wed Jul 21 16:55:35 2010 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 45FA73A6840 for ; Wed, 21 Jul 2010 16:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 nDatSYRGzWrD for ; Wed, 21 Jul 2010 16:55:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0FFAF3A6892 for ; Wed, 21 Jul 2010 16:55:33 -0700 (PDT) Received: by fxm1 with SMTP id 1so4358941fxm.31 for ; Wed, 21 Jul 2010 16:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.121.19 with SMTP id f19mr1057832far.73.1279756550297; Wed, 21 Jul 2010 16:55:50 -0700 (PDT) Received: by 10.223.112.129 with HTTP; Wed, 21 Jul 2010 16:55:50 -0700 (PDT) In-Reply-To: References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> Date: Thu, 22 Jul 2010 09:55:50 +1000 Message-ID: From: Greg Wilkins To: Mike Belshe Content-Type: multipart/alternative; boundary=001636c596eb9457c5048bee8ae5 Cc: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 21 Jul 2010 23:55:35 -0000 --001636c596eb9457c5048bee8ae5 Content-Type: text/plain; charset=UTF-8 On 22 July 2010 09:42, Mike Belshe wrote: > On the TLS issue, we're going in circles. Both sides are correct on the > facts about the pros and cons of TLS (more or less). I don't think the spec > should require TLS. But, would it be possible to define alternate > handshakes based on whether TLS is used? > > If we use the currently defined handshake, TLS will be at a performance > disadvantage to insecure WebSockets, because TLS will require more > round-trips. > > Could we define, as part of the WebSocket protocol, that when WebSocket is > negotiated over TLS it uses the TLS/NPN extension to effectively fold the > WebSocket Upgrade handshake into the TLS handshake? This removes a round > trip from the WebSocket startup time. The next-protocol-negotiation > extension is defined here: > http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00 > +1 there has been on opinion expressed that we can only ever have 1 websocket handshake. Thus because we are starting with port 80, the handshake is currently some mutant child of HTTP that must be sent even if another port is used and no HTTP is involved. This approach is stuck trying to fixate on the exact syntax of the handshake, literally down to counting spaces! Instead we need to establish the semantic context in which a websocket connection can be established, and then allow multiple ways to establish that context. HTTP upgrade is one such way, TLS/NPN is another. I'm sure there will eventually be more (maybe SPDY will support a DOWNGRADE method :) If the semantic context is secure (eg contains random token generated after any URL was formed by application), then does it really matter what syntax was used to establish the context? regards --001636c596eb9457c5048bee8ae5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 22 July 2010 09:42, Mike Belshe <mike@belshe.com> wrote:
On the TLS issue, we're going in circles. =C2=A0Both sides are correct = on the facts about the pros and cons of TLS (more or less). =C2=A0I don'= ;t think the spec should require TLS. =C2=A0But, would it be possible to de= fine alternate handshakes based on whether TLS is used?

If we use the currently defined handshake, TLS will be at a = performance disadvantage to insecure WebSockets, because TLS will require m= ore round-trips.

Could we define, as part of the WebSocket pr= otocol, that when WebSocket is negotiated over TLS it uses the TLS/NPN exte= nsion to effectively fold the WebSocket Upgrade handshake into the TLS hand= shake? =C2=A0This removes a round trip from the WebSocket startup time. =C2= =A0The next-protocol-negotiation extension is defined here: =C2=A0http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00

+1

there has been on opinion expressed that we= can only ever have 1 websocket handshake.=C2=A0 Thus because we are starti= ng with port 80, the handshake is currently some mutant child of HTTP that = must be sent even if another port is used and no HTTP is involved.

This approach is=C2=A0 stuck trying to fixate on the exact syntax of the ha= ndshake, literally down to counting spaces!

Instead we need to estab= lish the semantic context in which a websocket connection can be establishe= d, and then allow multiple ways to establish that context.=C2=A0=C2=A0 HTTP= upgrade is one such way, TLS/NPN is another.=C2=A0 I'm sure there will= eventually be more (maybe SPDY will support a DOWNGRADE method :)

If the semantic context is secure (eg contains random token generated= =20 after any URL was formed by application), then does it really matter=20 what syntax was used to establish the context?

regards


--001636c596eb9457c5048bee8ae5-- From wfernandom2004@gmail.com Wed Jul 21 16:55:57 2010 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 056363A6840 for ; Wed, 21 Jul 2010 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] 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 Av0YvH9pgSIe for ; Wed, 21 Jul 2010 16:55:56 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D10263A6809 for ; Wed, 21 Jul 2010 16:55:55 -0700 (PDT) Received: by qwe5 with SMTP id 5so3121236qwe.31 for ; Wed, 21 Jul 2010 16:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qke9/MxlHroWAuM70KooJWeJ6BDpnULoEJcQ3tfm+Nc=; b=D9BuMDuqdTxTNyDvj+DEBuKh7GT9Ilf+NYptr3go9TJnDUQ0Z4Z9Ssp6729G9yDQQ4 aPMqSFkoZEXRF+dwVh4Sv9o72DlSFM8BVLG/QZd52vuCvv1/OzWp4NQQUBNQc4gUixTA VqcxXVrDh5GqQ3zgiG5mn8cDjs8O1H8BrJLnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uFBB+9werfr/Q74O0hZbFTsBh9ix+EE/ekIQtmdXLW4ziQ2ByAVpGLRk6ZH8aIK/A9 QVN6ko5oI3stwgXKsugKxRkgjlmIqI/AFPsL2yKdrWeVzZRhw5GaJ3gk3OA/p6RP7Kzt jwZoLgDzX/pfaFfcHw9lWsDbczrkDslYpZsR4= MIME-Version: 1.0 Received: by 10.224.78.233 with SMTP id m41mr800637qak.27.1279756571945; Wed, 21 Jul 2010 16:56:11 -0700 (PDT) Received: by 10.229.55.10 with HTTP; Wed, 21 Jul 2010 16:56:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 20:56:11 -0300 Message-ID: From: Wellington Fernando de Macedo To: Greg Wilkins Content-Type: multipart/alternative; boundary=00c09f99e454dead71048bee8b55 Cc: hybi@ietf.org Subject: Re: [hybi] Authentication headers 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, 21 Jul 2010 23:55:57 -0000 --00c09f99e454dead71048bee8b55 Content-Type: text/plain; charset=ISO-8859-1 *> For example, the only authentication scheme that would work and be secure is Basic auth > over TLS to the same host as served the HTML page. In practice, only very > few sites use that combination of technologies; the cost of supporting it > seems higher than the benefit gained from it.* Well, where I last worked it used TLS+Basic Auth (using PAM). This is very useful, sure :) * > There are also a number of situations where it > would seem that it should work but where it won't* If it is true, then http auth should be removed at all. The Mozilla's implementation shares the ws credentials with the http ones (using the origin). So it isn't a problem. I think that removing http auth should be horribly bad. Similarly I think denying websockets from using it isn't a good thing either. *> Sure there are other ways than using headers, but the fact remains that many implementations do use headers > and I see no reason to break those implementation nor prevent their usage with websocket.* Actually I don't see any reasons to prevent these headers. Regards, Wellington. 2010/7/21 Greg Wilkins > > > On 21 July 2010 17:01, Ian Hickson wrote: > >> Cookies are supported because they are >> _very_ widely used, so there's something to reuse. HTTP auth is used so >> rarely that I'd seriously consider dropping it from HTTP at this point; I >> really don't think it's worth adding to WebSockets. >> > > > HTTP headers are frequently used for authentication mechanisms that are > neither the standard HTTP ones, nor plain simple cookies. For example many > OAUTH implementations allow tokens to be negotiated using HTTP headers. > > Sure there are other ways than using headers, but the fact remains that > many implementations do use headers and I see no reason to break those > implementation nor prevent their usage with websocket. > > > > > --00c09f99e454dead71048bee8b55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > For example, the only authentication scheme that would work and be secure is Basic auth
> over TLS to the same host as served the HTML page. In practice, only v= ery
=A0> few sites use that combination of technologies; the cost of = supporting it
> seems higher than the benefit gained from it.


Well, where I= last worked it used TLS+Basic Auth (using PAM). This is very useful, sure = :)

> There are also a number of situations where it
> wo= uld seem that it should work but where it won't


If it is true, then http auth should be removed at all. The Mozilla'= ;s implementation shares the ws
credentials with the http ones (using th= e origin). So it isn't a problem. I think that removing
http auth sh= ould be horribly bad. Similarly I think denying websockets from using it is= n't a good
thing either.

> Sure there are other ways than using headers, = but the fact remains that=20 many implementations do use headers
> and I see no reason to break t= hose=20 implementation nor prevent their usage with websocket.


Actually = I don't see any reasons to prevent these headers.

Regards,
Wellington.


2010/7/21 Greg Wilkins = <gregw@webtide.co= m>


On 21 July 2010 17:01, Ian Hickson <ian@hix= ie.ch> wrote:
=A0Cookies are supported because they are
_very_ widely used, so there's something to reuse. HTTP auth is used so=
rarely that I'd seriously consider dropping it from HTTP at this point;= I
really don't think it's worth adding to WebSockets.


HTTP headers are frequently used for authentication mec= hanisms that are neither the standard HTTP ones, nor plain simple cookies. = For example many OAUTH implementations allow tokens to be negotiated using = HTTP headers.

Sure there are other ways than using headers, but the fact remains that= many implementations do use headers and I see no reason to break those imp= lementation nor prevent their usage with websocket.



=A0

--00c09f99e454dead71048bee8b55-- From wfernandom2004@gmail.com Wed Jul 21 17:05:21 2010 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 EB91A3A6840 for ; Wed, 21 Jul 2010 17:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gIxQ+NWEUtQQ for ; Wed, 21 Jul 2010 17:05:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 9CB803A6809 for ; Wed, 21 Jul 2010 17:05:19 -0700 (PDT) Received: by qyk27 with SMTP id 27so3158944qyk.10 for ; Wed, 21 Jul 2010 17:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4Rp4yI4eEdH2ZZZ+OhcgrJ6oL91GdmEyK8aFBsUA5EM=; b=Ur4VB/DlvxwI0a2P/M0JAdnSJK8DS1WcJv+8EHVHR0kSSiSbSRv3gosG6bK3ZpyVwB rRaWsM26cCgpM//0PSWDNnlKlP0n8JLj5uajKBE4XGwiHrk4VP1NuwnsHNnghOwiBNKs 01Qcr5YV881k/BDnA6ByB3hWor4Dlo9rXd8GM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KJs+hPizAUAc+WuQxoaiKayf8R8NdYToZ4r0pK0nmtPlGcP2uhjIhKkSvnJhP8cETR VuKgJskrJYU+WjjWIP9zL5hQWQVmJOgzFdoJZcdVpqx3f3sJoXGmdvDmZ2a7B+6zrXmA L9yHj5HsRoCoESn9Ccz9I2D1+dK19RO9B/lRI= MIME-Version: 1.0 Received: by 10.224.47.75 with SMTP id m11mr789895qaf.54.1279757133344; Wed, 21 Jul 2010 17:05:33 -0700 (PDT) Received: by 10.229.55.10 with HTTP; Wed, 21 Jul 2010 17:05:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 21:05:33 -0300 Message-ID: From: Wellington Fernando de Macedo To: Ian Hickson Content-Type: multipart/alternative; boundary=0015175117ae550d79048beeadea Cc: hybi@ietf.org Subject: Re: [hybi] Authentication headers 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, 22 Jul 2010 00:05:22 -0000 --0015175117ae550d79048beeadea Content-Type: text/plain; charset=ISO-8859-1 > For example, the only authentication scheme that would work and be secure is Basic auth > over TLS to the same host as served the HTML page. Also, it isn't true. Again, all available Mozilla's http authentication (like digest) work with websocket. 2010/7/21 Ian Hickson > On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote: > > > > I'm updating the Mozilla's implementation of the WS protocol to its > > latest version (v.76). I know that handling the 401 http response was > > already removed in the v75. But now I've noted that even the http > > Authorization header has been removed. > > > > Well, I think that the 401 http status was removed in order to prevent > > the browser to open unexpected auth dialogs to the user. Actually, I > > know there is the cookie information, but I think it isn't always > > enough. So, I would like to ask, why can't a "normal" request include > > the Authorization header from its page origin? > > There's some commented-out text to that effect, but frankly it's not clear > to me that it would be particularly useful in practice. For example, the > only authentication scheme that would work and be secure is Basic auth > over TLS to the same host as served the HTML page. In practice, only very > few sites use that combination of technologies; the cost of supporting it > seems higher than the benefit gained from it. It also seems unreliable; it > relies on the browser remembering the credentials used when loading the > Web page, for instance. There are also a number of situations where it > would seem that it should work but where it won't, for example if a page > on one path uses pushState() to go to another path and then opens a > WebSocket connection to the same host with the second path, the UA would > not know the realm of the second path and thus wouldn't know to include > the authentication information. > > Basically, it seemed hacky. I couldn't really find a compelling argument > to support this rather than having it at the application layer. (You can > still leverage the basic auth feature that way, just have the server send > back a unique token that identifies the user's session and then pass that > back on the WebSocket connection.) Cookies are supported because they are > _very_ widely used, so there's something to reuse. HTTP auth is used so > rarely that I'd seriously consider dropping it from HTTP at this point; I > really don't think it's worth adding to WebSockets. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > --0015175117ae550d79048beeadea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > For example, the only authentication scheme that would work and be sec= ure is Basic auth
> over TLS to the same host as served the HTML page.

Also, it isn= 't true. Again, all available Mozilla's http authentication (like d= igest) work with websocket.

2010/7/21 Ian= Hickson <ian@hixie.ch= >
<= div class=3D"h5">On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote: >
> I'm updating the Mozilla's implementation of the WS protocol t= o its
> latest version (v.76). I know that handling the 401 http response was<= br> > already removed in the v75. But now I've noted that even the http<= br> > Authorization header has been removed.
>
> Well, I think that the 401 http status was removed in order to prevent=
> the browser to open unexpected auth dialogs to the user. Actually, I > know there is the cookie information, but I think it isn't always<= br> > enough. So, I would like to ask, why can't a "normal" re= quest include
> the Authorization header from its page origin?

There's some commented-out text to that effect, but frankly= it's not clear
to me that it would be particularly useful in practice. For example, the only authentication scheme that would work and be secure is Basic auth
over TLS to the same host as served the HTML page. In practice, only very few sites use that combination of technologies; the cost of supporting it seems higher than the benefit gained from it. It also seems unreliable; it<= br> relies on the browser remembering the credentials used when loading the
Web page, for instance. There are also a number of situations where it
would seem that it should work but where it won't, for example if a pag= e
on one path uses pushState() to go to another path and then opens a
WebSocket connection to the same host with the second path, the UA would not know the realm of the second path and thus wouldn't know to include=
the authentication information.

Basically, it seemed hacky. I couldn't really find a compelling argumen= t
to support this rather than having it at the application layer. (You can still leverage the basic auth feature that way, just have the server send back a unique token that identifies the user's session and then pass th= at
back on the WebSocket connection.) Cookies are supported because they are _very_ widely used, so there's something to reuse. HTTP auth is used so=
rarely that I'd seriously consider dropping it from HTTP at this point;= I
really don't think it's worth adding to WebSockets.

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'

--0015175117ae550d79048beeadea-- From wfernandom2004@gmail.com Wed Jul 21 17:07:33 2010 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 B30923A68F0 for ; Wed, 21 Jul 2010 17:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 imA8ABb-qr2F for ; Wed, 21 Jul 2010 17:07:32 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 384803A6840 for ; Wed, 21 Jul 2010 17:07:32 -0700 (PDT) Received: by qwe5 with SMTP id 5so3126366qwe.31 for ; Wed, 21 Jul 2010 17:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kkv2f07O5n/NrgICIVx2T8INEoM87jxxXOSjfVKr8iQ=; b=MrraNNcJsdrhRNFNG9FKfrvj0MLuCxiu1Yfj35Dz2R0E7PbqC3UPAZBSb48UO3LhKU HUTpqYXroggiZGP3l0j53nLkUq/06L47KIeHG1R7LINSIxF6Hbm2b+1jC/U3Q8KVz1cW 6vcSuPbyBWDX4OC0XEZciN2ykVrmEuKZbq0z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yDTnDmGAmSVqhRGrVYJaV8pCrSnoZBLfk2IjVekcKCYPCqTmhgpun+WH8WfLnN5H6O s3e8HOJu8MDAxLI0vITyHrDTOX2sDLyubHV2Xrcnl2aa84KG/UqNXOG7FFHXT0cR/9FV 6tHs8kJ1MUXfPnUnrBqbI9wPCC6jGC8pcJ2Dg= MIME-Version: 1.0 Received: by 10.224.79.151 with SMTP id p23mr718301qak.312.1279757268756; Wed, 21 Jul 2010 17:07:48 -0700 (PDT) Received: by 10.229.55.10 with HTTP; Wed, 21 Jul 2010 17:07:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 21:07:48 -0300 Message-ID: From: Wellington Fernando de Macedo To: Ian Hickson Content-Type: multipart/alternative; boundary=00c09f9c974d672e8e048beeb5e8 Cc: hybi@ietf.org Subject: Re: [hybi] Authentication headers 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, 22 Jul 2010 00:07:33 -0000 --00c09f9c974d672e8e048beeb5e8 Content-Type: text/plain; charset=ISO-8859-1 > Also, it isn't true. Again, all available Mozilla's http authentication (like digest) work with websocket. Well, I said something wrong... Actually digest with websockets just works when connecting to the proxy. Sorry. 2010/7/21 Wellington Fernando de Macedo > > For example, the only authentication scheme that would work and be secure > is Basic auth > > over TLS to the same host as served the HTML page. > > Also, it isn't true. Again, all available Mozilla's http authentication > (like digest) work with websocket. > > 2010/7/21 Ian Hickson > > On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote: >> > >> > I'm updating the Mozilla's implementation of the WS protocol to its >> > latest version (v.76). I know that handling the 401 http response was >> > already removed in the v75. But now I've noted that even the http >> > Authorization header has been removed. >> > >> > Well, I think that the 401 http status was removed in order to prevent >> > the browser to open unexpected auth dialogs to the user. Actually, I >> > know there is the cookie information, but I think it isn't always >> > enough. So, I would like to ask, why can't a "normal" request include >> > the Authorization header from its page origin? >> >> There's some commented-out text to that effect, but frankly it's not clear >> to me that it would be particularly useful in practice. For example, the >> only authentication scheme that would work and be secure is Basic auth >> over TLS to the same host as served the HTML page. In practice, only very >> few sites use that combination of technologies; the cost of supporting it >> seems higher than the benefit gained from it. It also seems unreliable; it >> relies on the browser remembering the credentials used when loading the >> Web page, for instance. There are also a number of situations where it >> would seem that it should work but where it won't, for example if a page >> on one path uses pushState() to go to another path and then opens a >> WebSocket connection to the same host with the second path, the UA would >> not know the realm of the second path and thus wouldn't know to include >> the authentication information. >> >> Basically, it seemed hacky. I couldn't really find a compelling argument >> to support this rather than having it at the application layer. (You can >> still leverage the basic auth feature that way, just have the server send >> back a unique token that identifies the user's session and then pass that >> back on the WebSocket connection.) Cookies are supported because they are >> _very_ widely used, so there's something to reuse. HTTP auth is used so >> rarely that I'd seriously consider dropping it from HTTP at this point; I >> really don't think it's worth adding to WebSockets. >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> > > --00c09f9c974d672e8e048beeb5e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Also, it isn't true. Again, all available Mozilla's http authe= ntication (like digest) work with websocket.

Well, I said something = wrong... Actually digest with websockets just works when connecting to the = proxy.
Sorry.

2010/7/21 Wellington Fernando de M= acedo <wfe= rnandom2004@gmail.com>
> For example, the only authentication scheme that wou= ld work and be secure is Basic auth
> over TLS to the same host as served the HTML page.

Also, = it isn't true. Again, all available Mozilla's http authentication (= like digest) work with websocket.

2010/7/= 21 Ian Hickson <ian@hixie.ch>

<= div>On Mon, 7 Jun 2010, Wellington Fernando de Macedo wrote:
>
> I'm updating the Mozilla's implementation of the WS protocol t= o its
> latest version (v.76). I know that handling the 401 http response was<= br> > already removed in the v75. But now I've noted that even the http<= br> > Authorization header has been removed.
>
> Well, I think that the 401 http status was removed in order to prevent=
> the browser to open unexpected auth dialogs to the user. Actually, I > know there is the cookie information, but I think it isn't always<= br> > enough. So, I would like to ask, why can't a "normal" re= quest include
> the Authorization header from its page origin?

There's some commented-out text to that effect, but frankly= it's not clear
to me that it would be particularly useful in practice. For example, the only authentication scheme that would work and be secure is Basic auth
over TLS to the same host as served the HTML page. In practice, only very few sites use that combination of technologies; the cost of supporting it seems higher than the benefit gained from it. It also seems unreliable; it<= br> relies on the browser remembering the credentials used when loading the
Web page, for instance. There are also a number of situations where it
would seem that it should work but where it won't, for example if a pag= e
on one path uses pushState() to go to another path and then opens a
WebSocket connection to the same host with the second path, the UA would not know the realm of the second path and thus wouldn't know to include=
the authentication information.

Basically, it seemed hacky. I couldn't really find a compelling argumen= t
to support this rather than having it at the application layer. (You can still leverage the basic auth feature that way, just have the server send back a unique token that identifies the user's session and then pass th= at
back on the WebSocket connection.) Cookies are supported because they are _very_ widely used, so there's something to reuse. HTTP auth is used so=
rarely that I'd seriously consider dropping it from HTTP at this point;= I
really don't think it's worth adding to WebSockets.

--
Ian Hickson =A0 =A0 =A0 =A0 =A0 =A0 =A0 U+1047E =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0)\._.,--....,'``. =A0 =A0fL
http://ln.hixie.ch/ = =A0 =A0 =A0 U+263A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/, =A0 _.. \ =A0 _\ =A0;`= ._ ,.
Things that are impossible just take longer. =A0 `._.-(,_..'--(,_..'= ;`-.;.'


--00c09f9c974d672e8e048beeb5e8-- From w@1wt.eu Wed Jul 21 17:07:58 2010 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 74E083A6892 for ; Wed, 21 Jul 2010 17:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=-1.393, 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 qL9O6FTzYPc9 for ; Wed, 21 Jul 2010 17:07:57 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 177DA3A6840 for ; Wed, 21 Jul 2010 17:07:56 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6M0899v007498; Thu, 22 Jul 2010 02:08:09 +0200 Date: Thu, 22 Jul 2010 02:08:09 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100722000809.GB7174@1wt.eu> References: <20100518121245.GR20356@shareable.org> <20100519013238.GB2318@shareable.org> <20100721151531.GA2990@1wt.eu> <20100721154519.GA3243@1wt.eu> <20100721233834.GG14589@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721233834.GG14589@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 22 Jul 2010 00:07:58 -0000 Hi Jamie, On Thu, Jul 22, 2010 at 12:38:34AM +0100, Jamie Lokier wrote: > Willy Tarreau wrote: > > On Wed, Jul 21, 2010 at 08:22:11AM -0700, Roberto Peon wrote: > > > I believe Mike quoted numbers in an earlier thread. > > > > > > Just to be sure we're talking about the same thing, I'm talking about the > > > UPGRADE feature of HTTP generically, and not as it applies to the current > > > draft Websocket spec. > > > > I thought they were related to the current version since it also uses > > Upgrade. Anyway, even if some don't support it yet, it will be easy > > to detect bypass them based on simple rules. > > Um, will it? How would that work? Basically at some (many?) ISPs, you can find such an architecture : [ ISP's clients ] \ | / POP | | routers | / cache L7 load balancer ---<- cache | \ cache | routers | (internet) The clients connect to somesite.com:80. At least they believe they do so. The first layer of routers see "port 80" and decide to forward to the load balancers, otherwise they forward everything to the internet. Obviously there are variants, it is possible that everything is sent to the LBs too, that's just an example. The LBs have to support 3 main features : - check if the URL has to be handled by the cache farm or not. If not, let's simply route it to the internet. - bypass the caches if too many are dead so that the remaining ones can't handle the load. - apply a load balancing algorithm on the request (eg: URL hash) to select a working cache, and forward the request to that cache. The request is sent unmodified and the cache receives the packets with the original destination IP address (sometimes they just rely on the Host header though). The first point is crucial. If the LB sends everything to caches, it costs a lot in terms of hardware, especially if the hardware is not suited to the type of application (imagine streaming video over a classical cache for instance, it would eat long-lived connections and CPU for zero added value). Also, there are always some cases where a bug or incompatibility will be discovered on the caches and they will have to be bypassed for some sites or request types. Last, they can degrade quality of service without bringing anything (eg: when dealing with XMLHttpRequest or interactive applications). This is the reason why the LBs in front of the cache are said to be Layer7, they're HTTP-aware. Alteon was already doing a lot of business with their products 10 years ago on this precise feature. Thus, the ISP has the ability to add rules which check the HTTP requests and decide whether or not it makes sense to send it to the cache farm or if it's easier to forward it to the server. The only prerequisite is that the L7 LB is HTTP-compliant, or at least understands HTTP enough so that everything that it decides to forward without passing through the caches will be unmodified. The goal of the ISP is not to *control* what passes there, but to *save bandwidth*. That means that rules can be very coarse. Some will simply decide that any URL containing a question mark will bypass the caches. Others will decide that youtube has too much data to store locally and that it's better to bypass the cache than thrashing it with youtube-only contents. And others will simply say that any connection containing "Upgrade: WebSocket" will bypass the caches. But for that to work, the HTTP-like protocol has to be HTTP-compatible ;-) Hoping this clarifies the things a bit, Willy From jamie@shareable.org Wed Jul 21 17:10:53 2010 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 496DD3A696E for ; Wed, 21 Jul 2010 17:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 IbJQaUYTwP0B for ; Wed, 21 Jul 2010 17:10:52 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id DB30C3A6840 for ; Wed, 21 Jul 2010 17:10:51 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObjNR-000174-E5; Thu, 22 Jul 2010 01:11:05 +0100 Date: Thu, 22 Jul 2010 01:11:05 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20100722001105.GH14589@shareable.org> References: <4BF12FF1.2020101@webtide.com> <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> 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" Subject: Re: [hybi] #1: HTTP Compliance 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, 22 Jul 2010 00:10:53 -0000 Greg Wilkins wrote: > I can visibly tell when establishing a > chat room if I have the WS transport enabled in the client or not, > because I can see the extra delays as WS is tried and fails. > This will be a barrier to frameworks like cometd-2 including WS in > their transport negotiations. (Aside: I think Ian's past responses suggest the following resolution: When you're establishing a chat room connection, you *ought* to know if you're connecting to a WS-aware chat service, in the same way that you already must know in advance which WS subprotocol to request if you do get a WS connection.) As noted some time ago, even when WS negotation *succeeds*, it can be slower than comet-style HTTP, both slower in sending the first messages, and slower in receiving the first responses. That situation is ridiculous. It means latency-optimised apps may open *two* connections in parallel: One comet-style HTTP, and one WebSocket. They will communicate initial messages over the HTTP connection, and switch to the WebSocket connection when that is ready. That's not kind on low bandwidth links, nor easy to program, so it's an ugly compromise. We can greatly improve the situation by avoiding some delays in the negotiation sequence. Unfortunately it seems each "waiting point" needs a different method of avoidance, so TLS negotation round trip delay is reduced only by using an ignorable TLS extension to carry initial messages; HTTP handshake round trip delay is reduced only by encoding initial messages in a HTTP-compatible manner, post-HTTP confirmation round trip delay is removed only by encoding initial messages in a way that is harmless to non-WS servers, and delays to messages originating between those stages are reduced only by rather fiddly inter-stage encodings. (Ideally we'd avoid the TCP 3-way handshake round trip too by including some data in the SYN, finally outperforming HTTP :-), but I have the uncertain impression that's considered inadvisable.) Fortunately there is a systematic approach possible, even though the details are annoyingly technical, and fortunately each step could be optionally implemented or not according to the implementer's preference. Simple implementations could ignore them entirely. -- Jamie From w@1wt.eu Wed Jul 21 17:10:59 2010 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 5670F3A6B2C for ; Wed, 21 Jul 2010 17:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=-1.365, 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 4-XGA5Q5Opgi for ; Wed, 21 Jul 2010 17:10:58 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id EE97E3A6AF3 for ; Wed, 21 Jul 2010 17:10:57 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6M0BCMh007519; Thu, 22 Jul 2010 02:11:12 +0200 Date: Thu, 22 Jul 2010 02:11:12 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20100722001112.GC7174@1wt.eu> References: <4BC860FD.8080007@webtide.com> <35EFEA5E-9017-48A1-BB66-A0AF947E159F@d2dx.com> <4C468EAE.4050507@gmx.de> <02BB0E0C-133B-4733-B053-A9D6E870F199@apple.com> 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: Hybi Subject: Re: [hybi] WebSocket, TLS and intermediaries 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, 22 Jul 2010 00:10:59 -0000 On Thu, Jul 22, 2010 at 09:55:50AM +1000, Greg Wilkins wrote: > On 22 July 2010 09:42, Mike Belshe wrote: > > > On the TLS issue, we're going in circles. Both sides are correct on the > > facts about the pros and cons of TLS (more or less). I don't think the spec > > should require TLS. But, would it be possible to define alternate > > handshakes based on whether TLS is used? > > > > If we use the currently defined handshake, TLS will be at a performance > > disadvantage to insecure WebSockets, because TLS will require more > > round-trips. > > > > Could we define, as part of the WebSocket protocol, that when WebSocket is > > negotiated over TLS it uses the TLS/NPN extension to effectively fold the > > WebSocket Upgrade handshake into the TLS handshake? This removes a round > > trip from the WebSocket startup time. The next-protocol-negotiation > > extension is defined here: > > http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00 > > > > +1 > > there has been on opinion expressed that we can only ever have 1 websocket > handshake. Thus because we are starting with port 80, the handshake is > currently some mutant child of HTTP that must be sent even if another port > is used and no HTTP is involved. > > This approach is stuck trying to fixate on the exact syntax of the > handshake, literally down to counting spaces! > > Instead we need to establish the semantic context in which a websocket > connection can be established, and then allow multiple ways to establish > that context. HTTP upgrade is one such way, TLS/NPN is another. +1 ! Regards, Willy From mjs@apple.com Wed Jul 21 17:15:07 2010 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 5078E3A693F for ; Wed, 21 Jul 2010 17:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TZZyPf3DGCln for ; Wed, 21 Jul 2010 17:15:03 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 2B2123A69FB for ; Wed, 21 Jul 2010 17:15:02 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 20894A49566A for ; Wed, 21 Jul 2010 17:15:19 -0700 (PDT) X-AuditID: 11807130-b7cd0ae00000795d-ae-4c478d961445 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id E8.DD.31069.69D874C4; Wed, 21 Jul 2010 17:15:19 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dp4O38zONGJwE4MNNzTBeg)" Received: from [17.151.90.251] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5X003OONDIXG90@elliott.apple.com> for hybi@ietf.org; Wed, 21 Jul 2010 17:15:18 -0700 (PDT) From: Maciej Stachowiak In-reply-to: Date: Wed, 21 Jul 2010 17:15:18 -0700 Message-id: <2EB4F6C6-467A-4485-9D8F-B5476B1661D8@apple.com> References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> To: Mike Belshe X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 22 Jul 2010 00:15:07 -0000 --Boundary_(ID_dp4O38zONGJwE4MNNzTBeg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jul 21, 2010, at 4:28 PM, Mike Belshe wrote: > > > I disagree that the protocol's development has been in any way held up by > this. I agree that we've talked about it a lot in the working group, but > the spec itself hasn't been affected by this as far as I can tell. > > To be specific, our earlier discussions about error handling, large frames, and binary frames were all cut short under the "too hard for amateur programmers". > > Based on the +1s in this thread, I think many agree that this has occurred. I don't yet know if we mostly agree that amateur programmers is not an overriding criteria, so how do we decide? Can we get a group decision on that now? > > Once we have a decision on that, we can finish looking at the other issues on the table. If we agree that "amateur programmer support" is not a feature, then it cannot be held up as an argument for or against any proposed solution once we've decided upon it. Or, if it is a priority, then we should weigh all proposed changes against it to ensure that the requirement is met. > > Can we call a vote on this issue alone and settle it? Chair-people, can you offer guidance? Without a decision on the importance of this issue, I know we'll go circular again when deciding on other issues. The IETF generally does not use voting as a means of decision-making. I don't have personal experience in how decision-making is done when there is not clear consensus, but these documents describe how it's supposed to work. http://tools.ietf.org/html/rfc2026 http://tools.ietf.org/html/rfc4677 Regards, Maciej --Boundary_(ID_dp4O38zONGJwE4MNNzTBeg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
On Jul 21, 2010, at 4:28 PM, Mike Belshe wrote:



I disagree that the protocol's development has been in any way held up by
this. I agree that we've talked about it a lot in the working group, but
the spec itself hasn't been affected by this as far as I can tell.

To be specific, our earlier discussions about error handling, large frames, and binary frames were all cut short under the "too hard for amateur programmers".

Based on the +1s in this thread, I think many agree that this has occurred.  I don't yet know if we mostly agree that amateur programmers is not an overriding criteria, so how do we decide?  Can we get a group decision on that now?

Once we have a decision on that, we can finish looking at the other issues on the table.  If we agree that "amateur programmer support" is not a feature, then it cannot be held up as an argument for or against any proposed solution once we've decided upon it.  Or, if it is a priority, then we should weigh all proposed changes against it to ensure that the requirement is met.

Can we call a vote on this issue alone and settle it?  Chair-people, can you offer guidance?  Without a decision on the importance of this issue, I know we'll go circular again when deciding on other issues.

The IETF generally does not use voting as a means of decision-making. I don't have personal experience in how decision-making is done when there is not clear consensus, but these documents describe how it's supposed to work.


Regards,
Maciej


--Boundary_(ID_dp4O38zONGJwE4MNNzTBeg)-- From jamie@shareable.org Wed Jul 21 17:21:57 2010 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 0DEFF3A696E for ; Wed, 21 Jul 2010 17:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 6qwCpo-My+aY for ; Wed, 21 Jul 2010 17:21:56 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 0B1E13A6809 for ; Wed, 21 Jul 2010 17:21:56 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObjY7-0001D8-Vf; Thu, 22 Jul 2010 01:22:07 +0100 Date: Thu, 22 Jul 2010 01:22:07 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20100722002207.GI14589@shareable.org> References: <20100519013238.GB2318@shareable.org> <20100721151531.GA2990@1wt.eu> <20100721154519.GA3243@1wt.eu> <20100721233834.GG14589@shareable.org> <20100722000809.GB7174@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100722000809.GB7174@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 22 Jul 2010 00:21:57 -0000 Willy Tarreau wrote: > Hi Jamie, > > On Thu, Jul 22, 2010 at 12:38:34AM +0100, Jamie Lokier wrote: > > Willy Tarreau wrote: > > > On Wed, Jul 21, 2010 at 08:22:11AM -0700, Roberto Peon wrote: > > > > I believe Mike quoted numbers in an earlier thread. > > > > > > > > Just to be sure we're talking about the same thing, I'm talking about the > > > > UPGRADE feature of HTTP generically, and not as it applies to the current > > > > draft Websocket spec. > > > > > > I thought they were related to the current version since it also uses > > > Upgrade. Anyway, even if some don't support it yet, it will be easy > > > to detect bypass them based on simple rules. > > > > Um, will it? How would that work? [Good description of transparent proxies at ISPs with configurable HTTP-aware rules on the routers.] Ah, I thought you meant "It will be easy to bypass *broken transparent proxies* based on simple rules *in the WebSocket clients and/or servers*". I.e. how to cope when the request hits a transparent proxy that doesn't work and you're *not* the ISP. Failing as fast as possible, and recognising it as a failure, is highly desirable if we can manage that. I don't know if we can. It would need actual experiments on a broad cross-section of the net. -- Jamie From w@1wt.eu Wed Jul 21 17:22:56 2010 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 31A303A6B4A for ; Wed, 21 Jul 2010 17:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=-1.338, 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 UuFESWc9WI1p for ; Wed, 21 Jul 2010 17:22:54 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id EABE33A6B2C for ; Wed, 21 Jul 2010 17:22:53 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6M0N8Aw007574; Thu, 22 Jul 2010 02:23:08 +0200 Date: Thu, 22 Jul 2010 02:23:08 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100722002308.GD7174@1wt.eu> References: <15307.1274106895.116423@Sputnik> <20100518003753.GP20356@shareable.org> <20100518121245.GR20356@shareable.org> <20100722001105.GH14589@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100722001105.GH14589@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 22 Jul 2010 00:22:56 -0000 On Thu, Jul 22, 2010 at 01:11:05AM +0100, Jamie Lokier wrote: > Greg Wilkins wrote: > > I can visibly tell when establishing a > > chat room if I have the WS transport enabled in the client or not, > > because I can see the extra delays as WS is tried and fails. > > This will be a barrier to frameworks like cometd-2 including WS in > > their transport negotiations. > > (Aside: I think Ian's past responses suggest the following resolution: > When you're establishing a chat room connection, you *ought* to know > if you're connecting to a WS-aware chat service, in the same way that > you already must know in advance which WS subprotocol to request > if you do get a WS connection.) > > As noted some time ago, even when WS negotation *succeeds*, it can be > slower than comet-style HTTP, both slower in sending the first > messages, and slower in receiving the first responses. > > That situation is ridiculous. > > It means latency-optimised apps may open *two* connections in > parallel: One comet-style HTTP, and one WebSocket. They will > communicate initial messages over the HTTP connection, and switch to > the WebSocket connection when that is ready. That's not kind on > low bandwidth links, nor easy to program, so it's an ugly compromise. And it's reliance on random numbers in userspace and MD5 to hash minuscule messages does not help at all keeping latency low ! > We can greatly improve the situation by avoiding some delays in the > negotiation sequence. > > Unfortunately it seems each "waiting point" needs a different method > of avoidance, so TLS negotation round trip delay is reduced only by > using an ignorable TLS extension to carry initial messages; HTTP > handshake round trip delay is reduced only by encoding initial > messages in a HTTP-compatible manner, post-HTTP confirmation round > trip delay is removed only by encoding initial messages in a way that > is harmless to non-WS servers, and delays to messages originating > between those stages are reduced only by rather fiddly inter-stage > encodings. Agreed. You're defining a well-stacked model where each layer informs the upper one about some information that may be needed for its handshake to complete without having to wait. > (Ideally we'd avoid the TCP 3-way handshake round trip too by > including some data in the SYN, finally outperforming HTTP :-), but I > have the uncertain impression that's considered inadvisable.) I think it was the principle of TTCP, but with TCP it's not possible because you don't know how large the other side's buffers before you receive the SYN-ACK which contains the MSS. However if you're interested, I can explain to you a system-dependant way to save one ACK from the client to the server by sending the data with the first ACK ;-) > Fortunately there is a systematic approach possible, even though the > details are annoyingly technical, and fortunately each step could be > optionally implemented or not according to the implementer's > preference. Simple implementations could ignore them entirely. That's what is nice with declarative protocols such as HTTP where you announce what you're doing. At least we should find a clean way to be able to decide whether we want an HTTP medium or just a TCP medium. I thought that the port was a good thing, but maybe the protocol scheme itself speaks better (ws/wss). After all, browsers currently use http/https for this. We could even have variants such as : - WS = plain TCP, no initial handshake - WSS = plain TLS, no initial handshake beyond TLS - WSTP = WS over HTTP = HTTP initial handshake Just a few ideas, hoping they will help others find better ones. Regards, Willy From L.Wood@surrey.ac.uk Wed Jul 21 17:24:15 2010 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 8B01F3A6840 for ; Wed, 21 Jul 2010 17:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 uxvdN9tiXeRh for ; Wed, 21 Jul 2010 17:24:14 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id BFBFC3A6B2C for ; Wed, 21 Jul 2010 17:24:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-78.messagelabs.com!1279758269!23110012!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 17707 invoked from network); 22 Jul 2010 00:24:29 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-11.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 22 Jul 2010 00:24:29 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 22 Jul 2010 01:24:29 +0100 From: To: Date: Thu, 22 Jul 2010 01:24:30 +0100 Thread-Topic: [hybi] HyBi WG update Thread-Index: AcspND+70xbTH8quS7ef7Njx+l+nYQ== Message-ID: <9E54059A-3287-426C-8C6B-542389ACB112@surrey.ac.uk> References: <4C1F3F93.2020805@ericsson.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hybi@ietf.org Subject: Re: [hybi] HyBi WG update 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, 22 Jul 2010 00:24:15 -0000 On 21 Jul 2010, at 23:44, Ian Hickson wrote: > On Wed, 21 Jul 2010, L.Wood@surrey.ac.uk wrote: >>=20 >> You don't need implementers implementing from the latest revision of the= =20 >> draft. >>=20 >> You need implementers implementing from a _considered_ version of the=20 >> draft, and a fixed referencable point at that. >=20 > Sure, but given that implementers are going to implement the spec=20 > regardless, I'd much rather they implemented the latest version, with all= =20 > the bugs removed, rather than a version that we _know_ is buggy. But that's a moving target. Then you can't contrast degrees of interoperabi= lity, or chase down problems. I personally wouldn't implement based on 'whatever specification I grabbed from CVS on a random date'. The latest version could just as well be the version with new bugs hastily introduced. Known bugs are preferable to unknown bugs... >=20 >> On the author's note: We've already discussed not promoting discussion=20 >> on WHATWG. This is an IETF draft; all discussion needs to be on hybi.=20 >=20 > Discussion will be where discussion is, not much we can do about that. WHATWG shouldn't be recommended. > I'm=20 > happy to adjust the note to point out that the IETF would rather own all= =20 > discussion and not have discussion elsewhere, but that wasn't the request= ,=20 > the request was just to remove the note altogether, which doesn't seem=20 > constructive (after all, we want to encourage feedback, and to do so we=20 > need to say where the feedback should go). >From most workgroup drafts, it's indicated in the filename. Yes, this is a bit of a covert signal to insiders such as workgroup chairs, so say to the hybi mailing list. > Clarification from the chairs=20 > as to the reason behind the request would be helpful here. >=20 >=20 >> Are you not following IETF list discussion except in sporadic bursts? >=20 > I only reply sporadically, because I work on a number of other parts of=20 > the WHATWG specification, and tend to work on each part for a few days=20 > before moving on to the next. This allows me to respond to feedback in=20 > bulk, so that many related points of view can be addressed at once rather= =20 > than responding to each one individually, which would result in much more= =20 > e-mail overall. meMeMEmemeMememe... this is not nurturing discussion, which is something you have expressed a desire to see happen. Your responses are no longer all sent in one bulk email, but is sent long after other participant= s have given up on discussion. We're discussing the text on where to send feedback and you're requesting clarification from the are-they-still-there chairs after, what, two months? That does not bode well for protocol development. Should your work processes take precedence over the workgroup? Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From w@1wt.eu Wed Jul 21 17:29:21 2010 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 362873A698B for ; Wed, 21 Jul 2010 17:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=-3.241, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 cnKUgqEbWg59 for ; Wed, 21 Jul 2010 17:29:19 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 1DA013A6970 for ; Wed, 21 Jul 2010 17:29:17 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6M0TSiG007633; Thu, 22 Jul 2010 02:29:28 +0200 Date: Thu, 22 Jul 2010 02:29:28 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20100722002928.GE7174@1wt.eu> References: <20100519013238.GB2318@shareable.org> <20100721151531.GA2990@1wt.eu> <20100721154519.GA3243@1wt.eu> <20100721233834.GG14589@shareable.org> <20100722000809.GB7174@1wt.eu> <20100722002207.GI14589@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100722002207.GI14589@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] #1: HTTP Compliance 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, 22 Jul 2010 00:29:21 -0000 On Thu, Jul 22, 2010 at 01:22:07AM +0100, Jamie Lokier wrote: > Willy Tarreau wrote: > > Hi Jamie, > > > > On Thu, Jul 22, 2010 at 12:38:34AM +0100, Jamie Lokier wrote: > > > Willy Tarreau wrote: > > > > On Wed, Jul 21, 2010 at 08:22:11AM -0700, Roberto Peon wrote: > > > > > I believe Mike quoted numbers in an earlier thread. > > > > > > > > > > Just to be sure we're talking about the same thing, I'm talking about the > > > > > UPGRADE feature of HTTP generically, and not as it applies to the current > > > > > draft Websocket spec. > > > > > > > > I thought they were related to the current version since it also uses > > > > Upgrade. Anyway, even if some don't support it yet, it will be easy > > > > to detect bypass them based on simple rules. > > > > > > Um, will it? How would that work? > > [Good description of transparent proxies at ISPs with configurable > HTTP-aware rules on the routers.] > > Ah, I thought you meant "It will be easy to bypass *broken transparent > proxies* based on simple rules *in the WebSocket clients and/or servers*". OK. > I.e. how to cope when the request hits a transparent proxy that > doesn't work and you're *not* the ISP. This happens all the time for such ISPs with simple HTTP sites that don't display a video or something. They know about that very fast through their forums from complaining customers, and they fix the issue using one of the bypass rules above. And sometimes they ask the cache editor to fix their product because they're fed up with feeding the L7 switch with bypass rules ;-) There are not that many ISPs in each country, I mean there are far less ISPs than there are web sites or potential WebSocket implementers. There's a high pressure on them to work as expected by customers. > Failing as fast as possible, and recognising it as a failure, is > highly desirable if we can manage that. I don't know if we can. That's my precise intent : fail ASAP if we know for sure it cannot work, and don't fail for no reason when we have no proof it cannot work when it would most likely have. Please see my proposal in another mail about that, I think it can improve on the current handshake for that. > It would need actual experiments on a broad cross-section of the net. I wholeheartly agree with that. It's the first time I read about testing before specifying on this list ! Doing so from the beginning would have saved a lot of man-hours ! Regards, Willy From ferg@caucho.com Wed Jul 21 17:31:44 2010 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 A9DDB3A6964 for ; Wed, 21 Jul 2010 17:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 y4H-xua+q28M for ; Wed, 21 Jul 2010 17:30:45 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 21B9E3A6978 for ; Wed, 21 Jul 2010 17:30:32 -0700 (PDT) Received: (qmail 43850 invoked from network); 22 Jul 2010 00:30:46 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 21 Jul 2010 17:30:46 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: B0ss9BgVM1mUVJol_y4tEl68xqcFwIeh5HfA293HZMA4nhI rbSH3fTONRY.RrdIxscXdL9bM1Vy8xfqwPb6cEVZbC05rXhXoqYxyDGnH.vj sFJnBS_ogyYIiqLrYzMuYodEK7_YINwqu5jsSTIyeoq5PQWXQIKxBSC44hOY cJioOtwLsbq0276beRrWAeZbz6zvxawDqn68.5An2MpVZleTlb2i27pphUMn 2exAqjgdIYW16g7JvfAx_XRta7hIbQOIl_PDMxqlelxUi12hv7inP71_xktY HYtIG3t2efILKeFWp_YM2rnsReI7a2lDVJ99zxTg6QmrnVnPB9PR8aQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C479130.4020500@caucho.com> Date: Wed, 21 Jul 2010 17:30:40 -0700 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mike Belshe References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 22 Jul 2010 00:31:44 -0000 X-List-Received-Date: Thu, 22 Jul 2010 00:31:44 -0000 Mike Belshe wrote: > > > On Wed, Jul 21, 2010 at 3:17 PM, Ian Hickson > wrote: > > > I disagree that the protocol's development has been in any way > held up by > this. I agree that we've talked about it a lot in the working > group, but > the spec itself hasn't been affected by this as far as I can tell. > > > To be specific, our earlier discussions about error handling, large > frames, and binary frames were all cut short under the "too hard for > amateur programmers". The entire spec has frozen in a broken state for months because of Ian's intransigence (frozen = "not affected"), and the chairs' unwillingness to address the issue. * It doesn't have any support for binary data. * It doesn't have any support for basic protocol concepts like chunking. * It doesn't have any way of extending to the multiplexing/flow control that's been brought up numerous times. * It doesn't have any to handle error frames. * It doesn't address the keepalive/ping issue at all. * It doesn't address the RTT issues. * It doesn't even conform to the HTTP specification correctly. The current spec is a joke. The only reason discussion started up again was because of the possibility of getting a real editor for the spec and moving on. If the chairs decide to do nothing -- again -- we'll be stuck with a bad spec that solves no problem well. > > And what did the protocol amateurs you spoke to say? It seems > unsurprising > that people whose careers are based on being able to solve complicated > protocol problems should want protocols to be complicated. > FFS. Nice combination ad-hom/strawman there. [Chairs? This is your editor.] The counterproposal at http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.html not complicated at all: it's a trivial protocol, and yet it solves the HyBi requirements, including requirements that the current draft ignores, as well as being extensible to muxing requirements. A dozen members of this list could come up with proposals as simple as that one and most would improve on it. -- Scott From jamie@shareable.org Wed Jul 21 17:37:46 2010 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 3C1FF3A6972 for ; Wed, 21 Jul 2010 17:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 jBqYZo80H2Hw for ; Wed, 21 Jul 2010 17:37:45 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id D73BC3A68F5 for ; Wed, 21 Jul 2010 17:37:44 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1ObjnV-0001U6-Dq; Thu, 22 Jul 2010 01:38:01 +0100 Date: Thu, 22 Jul 2010 01:38:01 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20100722003801.GJ14589@shareable.org> References: <20100721225210.GE6475@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721225210.GE6475@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org Subject: Re: [hybi] Proposal for a clean way to detect non-HTTP compliant transparent proxies 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, 22 Jul 2010 00:37:46 -0000 Willy Tarreau wrote: > > I've just thought about a way to fix the initial handshake so that it > works with proper HTTP-compliant implementations but still fails through > non-compliant transparent proxies. > > Let's have the client send the initial handshake request to the server. > This handshake is only made of HTTP headers. The client completes the > request with "Connection: close" so that a transparent intermediate > does not wait for a possible second request in case it does not understand > the upgrade response : > > GET /xxxx HTTP/1.1 > Upgrade: WebSocket > Connection: close > ... ws headers ... > ... > \r\n > > The server will send : > > HTTP/1.1 101 Swithing protocols > Upgrade: WebSocket > Content-length: 0 > Connection: close > ... ws headers ... > ... > \r\n > any-form-of-hello-message (eg: the server's protocol version) > > That way, if a transparent proxy does not have explicit support for 101, > it will only forward the headers with an empty body (CL: 0) and close the > connection towards the client. I think this won't work. RFC2616 (HTTP 1.1): "Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response." It's not spelled out explicitly, but the expectation is that proxies forward 1xx responses generically, and then forward the next response. If the proxy doesn't know how to handle 101 responses, then it may simply forward the 101 as a generic 1xx, and then try to forward the *following* bytes as a HTTP response. I would expect proxies to ignore Content-Length in 1xx: "1. Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message." In other words, a relatively stupid proxy, but which is aware of the 1xx rule, will not close the connection, and will treat the hello text and subsequent bytes as a HTTP response to modify and forward. There's some discussion on another list about using a 1xx response to indicate "request is being processed", for when the processing is slow to produce a response. The fact that is being taken seriously suggests that at least some deployments do forward 1xx messages in the way the standard requires. -- Jamie From ietf@adambarth.com Wed Jul 21 17:39:47 2010 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 743A93A6987 for ; Wed, 21 Jul 2010 17:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 CwbssOfyKMg3 for ; Wed, 21 Jul 2010 17:39:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 760203A6972 for ; Wed, 21 Jul 2010 17:39:46 -0700 (PDT) Received: by iwn38 with SMTP id 38so8004907iwn.31 for ; Wed, 21 Jul 2010 17:40:03 -0700 (PDT) Received: by 10.231.193.81 with SMTP id dt17mr758744ibb.177.1279759202921; Wed, 21 Jul 2010 17:40:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id h8sm29245457ibk.21.2010.07.21.17.40.01 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 17:40:02 -0700 (PDT) Received: by iwn38 with SMTP id 38so8004891iwn.31 for ; Wed, 21 Jul 2010 17:40:01 -0700 (PDT) Received: by 10.231.157.143 with SMTP id b15mr959866ibx.113.1279759201138; Wed, 21 Jul 2010 17:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.143.145 with HTTP; Wed, 21 Jul 2010 17:39:41 -0700 (PDT) In-Reply-To: <4C479130.4020500@caucho.com> References: <4BCAB2C1.2000404@webtide.com> <4BCB7829.9010204@caucho.com> <4BCC0A07.9030003@gmx.de> <4BCC111C.90707@gmx.de> <4BCC204D.30004@gmx.de> <4C462F9E.9030207@caucho.com> <4C479130.4020500@caucho.com> From: Adam Barth Date: Wed, 21 Jul 2010 17:39:41 -0700 Message-ID: To: Scott Ferguson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Extensibility mechanisms? 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, 22 Jul 2010 00:39:47 -0000 On Wed, Jul 21, 2010 at 5:30 PM, Scott Ferguson wrote: > The counterproposal at > > =A0http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest= .html > > not complicated at all: it's a trivial protocol, and yet it solves the Hy= Bi > requirements, including requirements that the current draft ignores, as w= ell > as being extensible to muxing requirements. > > A dozen members of this list could come up with proposals as simple as th= at > one and most would improve on it. This protocol is highly insecure. First, the server offers no proof that it understands the protocol, so it's very likely that it's vulnerable to cross-protocol attacks. Second, the client doesn't even require the server to respond at all before sending (almost) arbitrary content over the socket, which is very likely to lead to disaster. Adam From ietf@adambarth.com Wed Jul 21 17:42:48 2010 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 60A253A680B for ; Wed, 21 Jul 2010 17:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 di2Un4rVOgV7 for ; Wed, 21 Jul 2010 17:42:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2102E3A68F5 for ; Wed, 21 Jul 2010 17:42:46 -0700 (PDT) Received: by gyg8 with SMTP id 8so209258gyg.31 for