From andy.warmcat.com@googlemail.com Fri Apr 1 02:05:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6703A677C for ; Fri, 1 Apr 2011 02:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS5q55eAs1Kt for ; Fri, 1 Apr 2011 02:05:18 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4170D3A6452 for ; Fri, 1 Apr 2011 02:05:18 -0700 (PDT) Received: by wwa36 with SMTP id 36so2675614wwa.13 for ; Fri, 01 Apr 2011 02:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a91jMlpc49x+GOX4cMc+hevFJuUKBzFrM1cJIkbhVgk=; b=Tq7rZUauvXpeZf4pO8MzoK0x+hi2wuHClHqHw4cHNxAsseFocs5Q9TCH86DXoZuTrZ 13IgJhH67FjNbzXn9JVZTX/Uh64xf0pzLdkdp2k6q+w4fFYTgZLN92xCm/BEsu/RJr5y HnKwCF4IG+wHktKFP+Q2D32frAc9cGZ4RuM8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LeXaF5l92VPvb0xOgF12IkRiD3VY7i66o2XW5qUFDA4eRwKaDjkMJbmzCNBcQ3Mnyn iosvGJuHHmYCDxyOwPdGRqrI0YhDp6hY1/HGrDz/MKTvl4OhWbc9XzUnzdaJ8klbf/EQ jFCd4/uUpXULylKcKjfYZA3hz5uKRTuIR1N3c= Received: by 10.216.241.11 with SMTP id f11mr590366wer.76.1301648817950; Fri, 01 Apr 2011 02:06:57 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id b20sm1139579wbb.16.2011.04.01.02.06.54 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 02:06:55 -0700 (PDT) Sender: Andy Green Message-ID: <4D9595AC.6000307@warmcat.com> Date: Fri, 01 Apr 2011 10:06:52 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Endicott References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 09:05:19 -0000 On 04/01/2011 03:54 AM, Somebody in the thread at some point said: Hi - > 2. When WebSocket is provided as part of a HTTP server stack, having to > instantiate the WebSocket serving process (thread/handler/etc.) just to > resolve the handshake and determine if a WebSocket connection will > actually proceed is awkward, potentially expensive > and possibly insecure. The responsibility to determine if the HTTP > server will support a HTTP Upgrade to any given protocol for a given URL > is properly the responsibility of the HTTP server, not WebSocket. The > HTTP server must be able, via the Upgrade request to consider only (a) > the URL and (b) the Upgrade protocol and decide if it will support it. > If it will, then all further negotiation is the responsibility of the > protocol being upgraded to. I dunno that seems clean to me. Somebody connects claiming to want websocket service then the websocket plugin / library / code is obviously the place to form an opinion about the connection request. If that's expensive or insecure then that's an implementation issue? > 4. When WebSocket is provided as a stand-alone process, using a HTTP > Upgrade as the handshake presents at least two problems. (a) changing > from line-oriented I/O (in the HTTP handshake) to a byte-oriented I/O libwebsockets uses a bytewise parser for both HTTP and websocket protocol traffic. It could have bugs like anything else but it's not inherently more fragile or dodgy or 'line orientated', it's the same bytewise state machine. So again this is implementation and there are reasonable and secure implementations possible. > (for WebSocket frames) is awkward and potentially error prone, and (b) > any HTTP client-agent can potentially make a request to a WebSocket > server and get back a HTTP response, this exposes the availability and > capabilities of the WebSocket server to a client-agent that is not > actually a WebSocket client. Neither of these concerns is really all > that severe, but it is something to be aware of. Well, if it doesn't like what is told, typically the server will just hang upon the client. To get anything long-lived you have to have correct magic in the keys in the client request. -Andy From andy.warmcat.com@googlemail.com Fri Apr 1 02:11:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCC33A6774 for ; Fri, 1 Apr 2011 02:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CsNMgDWl6gC for ; Fri, 1 Apr 2011 02:10:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1754B3A66B4 for ; Fri, 1 Apr 2011 02:10:58 -0700 (PDT) Received: by wwa36 with SMTP id 36so2679107wwa.13 for ; Fri, 01 Apr 2011 02:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+wOYsHv3aqH/HhyQGHErucsXUm5dyOgY2j6mtyVTQ00=; b=D3Nw14ujFLqvYECUDrmJMrCwfpUY17yB+Mj9mzRQ0o6ljRMIRucjGystjWDRpvydei 0Qgpx1BThJuUxGBVFLJsl7wgAbOZfrdcnU5zBt6MIt0oCP/JYACcfo1J4yNI6oADJYr8 tk7UsrAgPeXDKn0uYE4kbskkkQb1b9EOXaHm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Y/1Qk0TrAtBuZMOymAzTbc6cXxFvkIjH6ccr73qyZFeqDIyKCSmIGwt8nBVZoKoFQI fRRAySAti8Hy0W9HL62pDfI+tVXb28nxNhU8Ov4yyYmdlWehh+QVzl2QTGY+3+h3Nkvp uQQiGgywJK9WkyNAI5BgfCP51Gq3AYUoG5vgA= Received: by 10.216.17.3 with SMTP id i3mr594201wei.80.1301649158706; Fri, 01 Apr 2011 02:12:38 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id w25sm1143946wbd.5.2011.04.01.02.12.37 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 02:12:38 -0700 (PDT) Sender: Andy Green Message-ID: <4D959704.1090303@warmcat.com> Date: Fri, 01 Apr 2011 10:12:36 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Longtin References: <000701cbf022$9adb51d0$d091f570$@net> In-Reply-To: <000701cbf022$9adb51d0$d091f570$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] Two Questions 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, 01 Apr 2011 09:11:00 -0000 On 04/01/2011 05:09 AM, Somebody in the thread at some point said: > To all, > > I had to ask... > > I would like to know, from an HTTP perspective, if a generic and valid > *HTTP* upgrade request cannot be replied to, per the HTTP spec. This (a > none response) seems to be a correct response per the WS 06 spec to an > invalid *WebSocket* upgrade/handshake request from a client. The spec can't really control what an intermediary might return anyway. So a restrictive firewall might come back with a 5xx http response without even contacting the websocket server. > Secondly, I am still unclear on whether WS *can* or *must* use ports 80 / > 443. Section 1.7 uses the term 'by default'. I think that implies *can* or > *should* but not *must*... It's definitely not 'must', there'd be no point in that restriction. What's implied I think is that you'll get best connectivity experience considering proxies and so on going via port 80 or as I found in the most restrictive case, 443. -Andy From salvatore.loreto@ericsson.com Fri Apr 1 02:20:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A693A677C for ; Fri, 1 Apr 2011 02:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 FaHjWGUK39EC for ; Fri, 1 Apr 2011 02:20:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 043603A6774 for ; Fri, 1 Apr 2011 02:20:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-10-4d959927a8d6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AC.B1.21265.729959D4; Fri, 1 Apr 2011 11:21:43 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 1 Apr 2011 11:21:43 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2433A26E8 for ; Fri, 1 Apr 2011 12:21:43 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D022250AB9 for ; Fri, 1 Apr 2011 12:21:42 +0300 (EEST) Received: from dhcp-1550.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 635F9509C6 for ; Fri, 1 Apr 2011 12:21:42 +0300 (EEST) Message-ID: <4D959926.60208@ericsson.com> Date: Fri, 1 Apr 2011 11:21:42 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] HYBI recording available 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, 01 Apr 2011 09:20:05 -0000 I want just point out that it is an IETF experiment to make more easy attend and actively participate remotely to WG f2f session or to watch the record of it ... whenever you have time, if you will both IETF community and Meetecho guys are looking for comments/feedback and you guys have provided a critical one (I was sure HyBi group would have provided some good one ): the security concerns are for sure something that Meetecho guys have to address... thanks a lot /Sal On 4/1/11 2:46 AM, Adam Barth wrote: > That's all very nice, but I'm not going to audit your Java source code > in order to watch this content. However, I would very much like to > watch the video in my browser. I doubt I'm the only one. > > Kind regards, > Adam > > > On Thu, Mar 31, 2011 at 5:11 PM, ietf@meetecho.com wrote: >> Hi guys, >> >> we answer your questions once and for all (hopefully ;-)) below. First of >> all, I'm afraid not all of you realized that the recordings are not "just" >> videos. Indeed, they are multimedia assets properly assembled (and >> synchronized) through a SMIL (http://www.w3.org/AudioVideo/) file. As an >> example, here is the .smil representation of the HyBi recording: >> >> http://meetecho-ietf.comics.unina.it/recordings/hybi/recording.smil >> >> As you can easily recognize, it contains references to slide images, chat >> log (as a textstream), plus the movie file containing both audio and video >> (http://143.225.229.137/recordings/hybi/video.mov). If you are familiar with >> smil (and I assume you are, since you all live in 2011), you can just take >> the mentioned file and play with it in order to: (i) either let it work with >> your favorite smil player; (ii) or patiently download all of the referenced >> resources (with your favorite software) and enjoy them separately. >> >> In order to facilitate your work, we have put on-line, in the downloads >> section on www.meetecho.com: (i) a ready-to-go java application that you can >> download on your computer and which can be fed with the smil file in order >> to play out the recordings (it is actually the scary software we launch when >> you click on the on-line recording link); (ii) the source code of the >> mentioned scary application, which you can freely download and modify in >> order to both double-check its correctness and improve it. In the second >> case (i.e. if you happen to improve it) we would be glad to receive from you >> the updated version. Please keep in mind that the application requires that >> you have Java Media Framework installed on your PC. >> >> Just one thing: www.meetecho.com requires that you register before allowing >> you to download our software. Registration is just for our logs and we don't >> sell private information to third parties. If it is too much for you, just >> throw in the towel ;-). >> >> Hope this helps, >> >> The Meetecho Team >> >> Da: "Simone Bordet" simone.bordet@gmail.com >> A: "Lorenzo Miniero" ietf@meetecho.com >> Cc: "Willy Tarreau" w@1wt.eu, hybi@ietf.org >> Data: Fri, 1 Apr 2011 00:30:36 +0200 >> Oggetto: Re: [hybi] HYBI recording available >>> Hi, >>> >>> On Thu, Mar 31, 2011 at 21:04, Lorenzo Miniero wrote: >>>> Dear Adam and Willy, >>>> >>>> about the full access, that's a security policy notification that is >>>> common to all JNLP-based applications. >>> Not exactly true, as not all JNLP application needs >>> java.security.AllPermission to run. >>> >>>> We can just reassure you that the only thing the application does is >>>> retrieve the SMIL description file, i.e. a standard way to describe a >>>> synchronized view of all the involved media, and in turn download the media >>>> content itself. After that, the playout starts allowing you to seek. >>> The player uses native libraries, which requires all permissions, so >>> there is no easy way out (unless of course you change the player). >>> >>> Would it be possible to convert the video to some other format that >>> only requires a browser to see, as per Adam's suggestion ? >>> >>>> Hoping this isn't a dealbreaker for you :) >>> It is for me also. We're in 2011 and JNLP requiring AllPermission >>> looks soooo 2000s. >>> >>> I could watch it in a virtual machine, but it's a lot more complicated >>> than it needs to. >>> >>> Simon >>> -- >>> 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. Victoria Livschitz >> _______________________________________________ >> 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 dendicott@gmail.com Fri Apr 1 04:18:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BB03A67FA for ; Fri, 1 Apr 2011 04:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc8XT9mCcr11 for ; Fri, 1 Apr 2011 04:18:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A22643A67F3 for ; Fri, 1 Apr 2011 04:18:27 -0700 (PDT) Received: by wwa36 with SMTP id 36so2760924wwa.13 for ; Fri, 01 Apr 2011 04:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O4xZhvxZgWMZ0mMbPhxQwIH0Dhi1cAy2rMEBdXFuaVA=; b=MtcbPgbXPMcy95YrLmumxlqcTMx2eCbB2mcMLsn74ly3gqWVlsZE/qADvYorTktvfW DsA84EwrvOy8vdSNzNg2mRAkloxH1z8a69+CWKTBYOn56ikjGaCyNFs/rS1HuZ6zkzdH jHsDemR6OpARgrQEdsCmqRXR56UfCSNXLCIVQ= 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=bdDYYaoK0qjC0eMUbRKZv/K8HOb/XbjKvJVI+vLQJqdMp5k5f351OS2WwYbQGuxYj8 FNU/H9CVrxrKpXHmXjosBuGphu12TZFyDOf41Pfvym++c0lqUTnr9sDKo5+rswlJtnZm jWBn8I23KpLQWiaHcQFBbaJyG5IcFwEpYkPRg= MIME-Version: 1.0 Received: by 10.216.166.2 with SMTP id f2mr728912wel.24.1301656807356; Fri, 01 Apr 2011 04:20:07 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 04:20:07 -0700 (PDT) In-Reply-To: <000601cbf022$4c420320$e4c60960$@net> References: <000601cbf022$4c420320$e4c60960$@net> Date: Fri, 1 Apr 2011 07:20:07 -0400 Message-ID: From: David Endicott To: Greg Longtin Content-Type: multipart/alternative; boundary=0016364269df9f3b4e049fd9974a Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 11:18:30 -0000 --0016364269df9f3b4e049fd9974a Content-Type: text/plain; charset=ISO-8859-1 > > > 1. Further, WebSocket protocol servers may not be part of a HTTP serving > environment and having it answer HTTP (however limited) could confuse > client > agents. > > I'm not sure I understand the 'confuse client agents' concept. If a client > agent includes the header 'Upgrade: websocket' in an HTTP request, it > should > be expecting the response as defined in the spec. > What I was thinking of was a HTTP client-agent that mistakenly connected to a WebSocket server. It would send a normal HTTP GET. The WebSocket server would, of course, reject that connection. That rejection response (or dropped connection) might befuddle a client-agent expecting a typical HTTP response. Or, perhaps worse, the client-agent sends a reasonably legit but mistaken HTTP Upgrade and gets the Upgrade accepted response and is then completely confused by the non-http traffic that follows. I admit these are unlikely scenarios and it isn't really our problem to deal with client-agents pointed at the wrong endpoint. > > > 2. When WebSocket is provided as part of a HTTP server stack, having to > instantiate the WebSocket serving process (thread/handler/etc.) just to > resolve the handshake > > I'm not sure why 'when A' implies 'B.' Somewhere, the stack needs know > what > will be considered valid 'Request-URI' and possibly > 'Sec-WebSocket-Protocol' > information. That is a concern of whomever administers the stack. > > Agreed. The stack does need to know. I argue that the proper place in the stack (when WebSocket is deployed as part of it) is the HTTP server. It's the HTTP servers job to deal with URLs in it's context. WebSockets is a transport layer into/with the resource(s) and should participate in a unified URL scheme. It should not side-step the established URL scheme and introduce its own - which if it's examining the given URL I would argue it is. WebSocket is a transport protocol, not an application protocol - URL mapping & access control is the job of the HTTP server. WebSocket is a transport of frames for a URL defined resource, much like TCP is the transport for HTTP packaged URL defined resources. > > 4 (a) changing from line-oriented I/O (in the HTTP handshake) to a > byte-oriented I/O (for WebSocket frames) is awkward and potentially error > prone > > Considering WS servers will be designed for byte-oriented I/O, the > line-oriented I/O coding requirements are minimal, and not necessarily > error > prone. > As I mentioned, it's not big deal. But there is a conceptual shift. For me, that suggests a change in protocols and is further evidence that perhaps HTTP Upgrade is outside the domain of WebSocket. > 4 (b) any HTTP client-agent can potentially make a request to a WebSocket > server and get back a HTTP response, this exposes the availability and > capabilities of the WebSocket server > > Without the correct Request-URI and possibly 'Sec-WebSocket-Protocol' > header, what can the client find out? If the HTTP client request is > invalid, the spec states (somewhat vaguely) in Section 7.2.2. the following > 'Certain algorithms require or recommend that the server _abort the > WebSocket connection_ during the opening handshake.' Hence, 'get back a > HTTP response' may not occur with the client agent's request. > > If the client-agent request is valid, the availability of that URL as WebSocket, and some capabilities of that connection are provided in the handshake response. This may, or may not be a concern. Requiring the WebSocket server to evaluate any incoming HTTP request increases the possibility of denial-of-service as any HTTP client-agent can send any HTTP request (Upgrade or not) and make the WebSocket server evaluate it before terminating connection. It need not even be a malicious client-agent, just a confused one (perhaps doing XMLHttpRequest polling) If the HTTP server could make that initial determination we get to leverage that infrastructure to reduce exposure. If it's a stand-alone WebSocket server, incoming HTTP requests can be dropped much sooner in the communication (like on the first few bytes). I think everyone is a little sensitive and spent from all the reading. > Indeed. Protocol design is *hard*. --0016364269df9f3b4e049fd9974a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> 1. Further, WebSocket protocol servers may not be part of a HTTP ser= ving
environment and having it answer HTTP (however limited) could confuse clien= t
agents.

I'm not sure I understand the 'confuse client agents' con= cept. =A0If a client
agent includes the header 'Upgrade: websocket' in an HTTP request, = it should
be expecting the response as defined in the spec.

=
What I was thinking of was a HTTP client-agent that mistakenly c= onnected to a WebSocket server. =A0It would send a normal HTTP GET. =A0The = WebSocket server would, of course, reject that connection. =A0That rejectio= n response (or dropped connection) might befuddle a client-agent expecting = a typical HTTP response. =A0 Or, perhaps worse, the client-agent sends a re= asonably legit but mistaken HTTP Upgrade and gets the Upgrade accepted resp= onse and is then completely confused by the non-http traffic that follows.<= /div>

I admit these are unlikely scenarios and it isn't r= eally our problem to deal with client-agents pointed at the wrong endpoint.=



> 2. When WebSocket is provided as part of a HTTP server stack, having t= o
instantiate the WebSocket serving process (thread/handler/etc.) just to
resolve the handshake

I'm not sure why 'when A' implies 'B.' =A0Somewhe= re, the stack needs know what
will be considered valid 'Request-URI' and possibly 'Sec-WebSoc= ket-Protocol'
information. =A0That is a concern of whomever administers the stack.

Agreed. =A0The stack does nee= d to know. =A0I argue that the proper place in the stack (when WebSocket is= =A0deployed=A0as part of it) is the HTTP server. =A0It's the HTTP serve= rs job to deal with URLs in it's context. =A0 WebSockets is a transport= layer into/with the resource(s) and should participate in a unified URL sc= heme. =A0It should not side-step the established URL scheme and introduce i= ts own - which if it's=A0examining=A0the given URL I would argue it is.= =A0 =A0

WebSocket is a transport protocol, not an application p= rotocol - URL mapping & access control is the job of the HTTP server. = =A0 WebSocket is a transport of frames for a URL defined resource, much lik= e TCP is the transport for HTTP packaged URL defined resources.


> 4 (a) changing from line-oriented I/O (in the HTTP handshake) to a
byte-oriented I/O (for WebSocket frames) is awkward and potentially error prone

Considering WS servers will be designed for byte-oriented I/O, the line-oriented I/O coding requirements are minimal, and not necessarily erro= r
prone.

As I mentioned, it's not big= deal. =A0 But there is a conceptual shift. =A0 For me, that suggests a cha= nge in protocols and is further evidence that perhaps HTTP Upgrade is outsi= de the domain of WebSocket.

> 4 (b) any HTTP client-agent can potentially make a r= equest to a WebSocket
server and get back a HTTP response, this exposes the availability and
capabilities of the WebSocket server

Without the correct Request-URI and possibly 'Sec-WebSocket-Proto= col'
header, what can the client find out? =A0If the HTTP client request is
invalid, the spec states (somewhat vaguely) in Section 7.2.2. the following=
'Certain algorithms require or recommend that the server _abort the
WebSocket connection_ during the opening handshake.' =A0Hence, 'get= back a
HTTP response' may not occur with the client agent's request.

If the client-agent request is valid, the availabilit= y of that URL as WebSocket, and some capabilities of that connection are pr= ovided in the handshake response. =A0 This may, or may not be a concern. = =A0 Requiring the WebSocket server to evaluate any incoming HTTP request in= creases the possibility of denial-of-service as any HTTP client-agent can s= end any HTTP request (Upgrade or not) and make the WebSocket server evaluat= e it before terminating connection. =A0 It need not even be a malicious cli= ent-agent, just a confused one (perhaps doing XMLHttpRequest polling) =A0If= the HTTP server could make that initial determination we get to leverage t= hat infrastructure to reduce exposure. =A0 If it's a stand-alone WebSoc= ket server, incoming HTTP requests can be dropped much sooner in the commun= ication (like on the first few bytes).

I think everyone is a little= sensitive and spent from all the reading.

<= div> Indeed. =A0Protocol design is *hard*.
=A0
--0016364269df9f3b4e049fd9974a-- From dendicott@gmail.com Fri Apr 1 04:24:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B1B3A6819 for ; Fri, 1 Apr 2011 04:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl0lAURbL31k for ; Fri, 1 Apr 2011 04:24:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9CF613A6817 for ; Fri, 1 Apr 2011 04:24:22 -0700 (PDT) Received: by wyb29 with SMTP id 29so3218350wyb.31 for ; Fri, 01 Apr 2011 04:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zl5htydWhbsl38MqTdsT9Ew88gOheiz6oo5Hr92QpEc=; b=Y21yT4hzuYeS5ISmRquOIR5FP2i+9V9I0zBL350QoU3f19cyCkesJpOdDWs6rbTCpp Zc4be6mp1SE2cjmydeSLDoMS9yJ1hfjc1mC+p+N1MYD3QECFJAYTFmRBpdVgvexAge7a C90FX1JzZSjQTQBko0S+wp9fXKsiyA3afUFyE= 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=DwsaR6mO6oClXhJMATfT4kA2zcw4iPTKIiZ0XN2ZmeBgLfstqpV0kbK3NguYg74EUL 7lIc6vDokNNzrE1/eSEYg8o6b+Yh4CfjKPCSf9jQdzZqMly5r17GU+0r5NR6IFPDpoSt /xTNBdCU1ukgcmwXQDgHe4lfqn1tPb4g8fYEM= MIME-Version: 1.0 Received: by 10.216.221.16 with SMTP id q16mr3765058wep.71.1301657162357; Fri, 01 Apr 2011 04:26:02 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 04:26:02 -0700 (PDT) In-Reply-To: <20110401052150.GA658@1wt.eu> References: <000601cbf022$4c420320$e4c60960$@net> <20110401052150.GA658@1wt.eu> Date: Fri, 1 Apr 2011 07:26:02 -0400 Message-ID: From: David Endicott To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016e64c1afcc81d11049fd9acbd Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 11:24:24 -0000 --0016e64c1afcc81d11049fd9acbd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 1, 2011 at 1:21 AM, Willy Tarreau wrote: > On Thu, Mar 31, 2011 at 11:07:19PM -0500, Greg Longtin wrote: > > > 4 (a) changing from line-oriented I/O (in the HTTP handshake) to a > > > byte-oriented I/O (for WebSocket frames) is awkward and potentially > error > > > prone > > > > Considering WS servers will be designed for byte-oriented I/O, the > > line-oriented I/O coding requirements are minimal, and not necessarily > error > > prone. > > I would add that any HTTP server already deals with that. They accept > POST requests which are byte-oriented, they can send any file (eg: HTML, > GIF, etc...) which are byte-oriented too and browsers can correctly > retrieve these files. So in fact it's something which is already > implemented and works very well in every client and server. > > Agreed. It's not onerous. However, WebSocket is not HTTP. And simpler implementations are generally better. If we don't really need to, why should we? As I mentioned to Greg, it's not that having to switch trains in mid stream is a big problem, it's that it signals (to me at least) that we switching protocols. And if we're switching protocols (which we are), then the protocols should keep themselves to their own domains. > > > 4 (b) any HTTP client-agent can potentially make a request to a > WebSocket > > > server and get back a HTTP response, this exposes the availability and > > > capabilities of the WebSocket server > > > > Without the correct Request-URI and possibly 'Sec-WebSocket-Protocol' > > header, what can the client find out? If the HTTP client request is > > invalid, the spec states (somewhat vaguely) in Section 7.2.2. the > following > > 'Certain algorithms require or recommend that the server _abort the > > WebSocket connection_ during the opening handshake.' Hence, 'get back a > > HTTP response' may not occur with the client agent's request. > > There were discussions in the past about exposing some capabilities as > control frames, but that did not bring any major advantage, and that > required an additional round-trip before communication could start, > which is really not acceptable in some environments (eg: smartphones). > I would argue that one extra exchange of frames when connecting via HTTP Upgrade is not an undue burden. Further, if you establish a WebSocket connection directly (ie. not via a HTTP server), the actual data transport cost would be smaller. Again, this is nothing more than my belief that WebSocket should be defined as the transport protocol it is, and that HTTP Upgrade is yet another mechanism to boot-strap a WebSocket connection. If WebSocket only spoke websocket frames, then I could implement any number of ways for a client-agent to establish a connection, not just via HTTP Upgrade. > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016e64c1afcc81d11049fd9acbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 1, 2011 at 1:21 AM, Willy Ta= rreau <w@1wt.eu> wrote:
On Thu, Mar 31, 2011 at 11:07:19PM -0500, Greg Longtin wr= ote:
> > 4 (a) changing from line-oriented I/O (in the HTTP handshake) to = a
> > byte-oriented I/O (for WebSocket frames) is awkward and potential= ly error
> > prone
>
> Considering WS servers will be designed for byte-oriented I/O, the
> line-oriented I/O coding requirements are minimal, and not necessarily= error
> prone.

I would add that any HTTP server already deals with that. They accept=
POST requests which are byte-oriented, they can send any file (eg: HTML, GIF, etc...) which are byte-oriented too and browsers can correctly
retrieve these files. So in fact it's something which is already
implemented and works very well in every client and server.


Agreed. =A0It&= #39;s not onerous. =A0 However, WebSocket is not HTTP. =A0 =A0And simpler i= mplementations are generally better. =A0 =A0If we don't really need to,= why should we? =A0 As I mentioned to Greg, it's not that having to swi= tch trains in mid stream is a big problem, it's that it signals (to me = at least) that we switching protocols. =A0And if we're switching protoc= ols (which we are), then the protocols should keep themselves to their own = domains.

=A0
> > 4 (b) any HTTP client-agent can potentially make a request to a W= ebSocket
> > server and get back a HTTP response, this exposes the availabilit= y and
> > capabilities of the WebSocket server
>
> Without the correct Request-URI and possibly 'Sec-WebSocket-Protoc= ol'
> header, what can the client find out? =A0If the HTTP client request is=
> invalid, the spec states (somewhat vaguely) in Section 7.2.2. the foll= owing
> 'Certain algorithms require or recommend that the server _abort th= e
> WebSocket connection_ during the opening handshake.' =A0Hence, = 9;get back a
> HTTP response' may not occur with the client agent's request.<= br>
There were discussions in the past about exposing some capabilities a= s
control frames, but that did not bring any major advantage, and that
required an additional round-trip before communication could start,
which is really not acceptable in some environments (eg: smartphones).
<= /blockquote>

I would argue that one extra exchange of fr= ames when connecting via HTTP Upgrade is not an undue burden. =A0 Further, = if you establish a WebSocket connection directly (ie. not via a HTTP server= ), the actual data transport cost would be smaller.

Again, this is nothing more than my belief that WebSock= et should be defined as the transport protocol it is, and that HTTP Upgrade= is yet another mechanism to boot-strap a WebSocket connection. =A0 If WebS= ocket only spoke websocket frames, then I could implement any number of way= s for a client-agent to establish a connection, not just via HTTP Upgrade.<= /div>


Willy

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

--0016e64c1afcc81d11049fd9acbd-- From Greg@ChampionEnt.net Fri Apr 1 04:26:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A4E3A6811 for ; Fri, 1 Apr 2011 04:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiWdwZ4KV-M7 for ; Fri, 1 Apr 2011 04:26:12 -0700 (PDT) Received: from smtpout-1.iphouse.net (smtpout-1.iphouse.net [209.240.70.140]) by core3.amsl.com (Postfix) with ESMTP id B89EF3A67F3 for ; Fri, 1 Apr 2011 04:26:09 -0700 (PDT) Received: from smtpout-1.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id B1CC01CCE9 for ; Fri, 1 Apr 2011 06:27:49 -0500 (CDT) Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-1.iphouse.net (Postfix) with ESMTPSA id 676531CCE3 for ; Fri, 1 Apr 2011 06:27:49 -0500 (CDT) From: "Greg Longtin" To: "hybi" References: <000701cbf022$9adb51d0$d091f570$@net> <4D959704.1090303@warmcat.com> In-Reply-To: <4D959704.1090303@warmcat.com> Date: Fri, 1 Apr 2011 06:27:48 -0500 Message-ID: <000c01cbf05f$d4df6280$7e9e2780$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvwTPUShQjCCa+aQRqSEYXTlisLLgADuDXQ Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [hybi] Two Questions 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, 01 Apr 2011 11:26:12 -0000 Andy, Thanks for the reply. How about I rephrase. Per the HTTP spec, can an HTTP server *not* respond to a properly formatted but invalid upgrade request from a client? Or, *should* an HTTP server respond? My interpretation of the WS spec is that a non response is correct for invalid WS upgrade requests. Does that play well with the HTTP spec? > > I would like to know, from an HTTP perspective, if a generic and > > valid *HTTP* upgrade request cannot be replied to, per the HTTP > > spec. This (a none response) seems to be a correct response per > > the WS 06 spec to an invalid *WebSocket* upgrade/handshake > > request from a client. > The spec can't really control what an intermediary might return anyway. > So a restrictive firewall might come back with a 5xx http response > without even contacting the websocket server. Thanks, Greg Longtin From dendicott@gmail.com Fri Apr 1 04:38:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90DB3A680E for ; Fri, 1 Apr 2011 04:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A268d59gwrsn for ; Fri, 1 Apr 2011 04:38:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5A6783A6805 for ; Fri, 1 Apr 2011 04:38:34 -0700 (PDT) Received: by wwa36 with SMTP id 36so2774952wwa.13 for ; Fri, 01 Apr 2011 04:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LJXf6vlZYWbe12fcy/Sg68wP7COSXIw6+uTLQQgUGng=; b=qsWqaM77Hbs+7w7ZvHqayOkBJPwwjPYuLMTHPIpfq78CXuQ7HSlLOqEZ7wlcJkpjWA mhHIdR1OWadCpgOvpvEy35lXOd36K76NRI+ECA0VaPLVjJU4ATX7Q8xoRU6E9eX2BAiO XoYNrx1DI3R0EjadVSpbhwhi6gj9Gv7PEm7Lk= 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=DMF4/jBPxZNGk6zxYR572c7EebA4lfzEJrB0Xi6sWZ+nNyHNcWEUa5sycxFcIhsxSM FQ38zZsRhWWmhQDkwOcvukZYMNOfc95oPnh0wCwnrI+KJz9z9T+Ojuwlz933Xks20Hkr USK33pBAB4qlEjtN7SrK6qFvde5OezFGKLwfA= MIME-Version: 1.0 Received: by 10.216.143.135 with SMTP id l7mr725365wej.86.1301658014089; Fri, 01 Apr 2011 04:40:14 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 04:40:14 -0700 (PDT) In-Reply-To: <4D9595AC.6000307@warmcat.com> References: <4D9595AC.6000307@warmcat.com> Date: Fri, 1 Apr 2011 07:40:14 -0400 Message-ID: From: David Endicott To: Andy Green Content-Type: multipart/alternative; boundary=0016e6d59d668c8177049fd9dfec Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 11:38:38 -0000 --0016e6d59d668c8177049fd9dfec Content-Type: text/plain; charset=ISO-8859-1 > > 2. When WebSocket is provided as part of a HTTP server stack, having to >> instantiate the WebSocket serving process (thread/handler/etc.) just to >> resolve the handshake and determine if a WebSocket connection will >> actually proceed is awkward, potentially expensive >> and possibly insecure. The responsibility to determine if the HTTP >> server will support a HTTP Upgrade to any given protocol for a given URL >> is properly the responsibility of the HTTP server, not WebSocket. The >> HTTP server must be able, via the Upgrade request to consider only (a) >> the URL and (b) the Upgrade protocol and decide if it will support it. >> If it will, then all further negotiation is the responsibility of the >> protocol being upgraded to. >> > > I dunno that seems clean to me. Somebody connects claiming to want > websocket service then the websocket plugin / library / code is obviously > the place to form an opinion about the connection request. If that's > expensive or insecure then that's an implementation issue? True, in some implementations the cost of passing the HTTP Upgrade request over to be evaluated won't be much. However, in the work I've been doing, spawning the WebSocket server as a seperate process has been a good & valid method (for many unrelated reasons), this can be expensive. It seems to me that when deployed in a HTTP stack, letting the webserver decided based on URL & Upgrade: protocol if it will even consider supporting it is a useful arrangement. Also, I believe it more properly reflects the real conceptual domains. For example, if the HTTP server can decide, "Yes, I'm going to do WebSocket for that URL", it can chroot to that URLs place in the filesystem, instantiate the WebSocket server/handler and pass the TCP connection off with a clean conscience. Evaluating the validity of a URL is not the job of a transport protocol. WebSocket is a transport protocol. > 4. When WebSocket is provided as a stand-alone process, using a HTTP >> Upgrade as the handshake presents at least two problems. (a) changing >> from line-oriented I/O (in the HTTP handshake) to a byte-oriented I/O >> > > libwebsockets uses a bytewise parser for both HTTP and websocket protocol > traffic. It could have bugs like anything else but it's not inherently more > fragile or dodgy or 'line orientated', it's the same bytewise state machine. > So again this is implementation and there are reasonable and secure > implementations possible. As previously mentioned, it's not the doing I have a problem with. It's what the doing implies. > (for WebSocket frames) is awkward and potentially error prone, and (b) >> any HTTP client-agent can potentially make a request to a WebSocket >> server and get back a HTTP response, this exposes the availability and >> capabilities of the WebSocket server to a client-agent that is not >> actually a WebSocket client. Neither of these concerns is really all >> that severe, but it is something to be aware of. >> > > Well, if it doesn't like what is told, typically the server will just hang > upon the client. To get anything long-lived you have to have correct magic > in the keys in the client request. > Possibly causing client-agent timeout delays. Perhaps not. That's the client-agent's problem. Again, I don't this is all that serious of a concern, just that it's another ramification of the mixing of HTTP and WebSockets. And don't get me started on the magic keys (Sec-WebSocket-Key). Personally I believe this part of the handshake to be useless hand-waving that does not provide what it's supposedly intended to do. The client can generate any value and ignore the server's response, it proves nothing. I have not expressed a concern about it as it is harmless and not onerous to implement. And I'm ok with implementing hand-waving if it'll get asynchronous traffic with a browser client out the door into the real world sooner. > -Andy > --0016e6d59d668c8177049fd9dfec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2. When WebSocket is provided as part of a HTTP server stack, having to
instantiate the WebSocket serving process (thread/handler/etc.) just to
resolve the handshake and determine if a WebSocket connection will
actually proceed is awkward, potentially expensive
and possibly insecure. =A0 =A0The responsibility to determine if the HTTP server will support a HTTP Upgrade to any given protocol for a given URL is properly the responsibility of the HTTP server, not WebSocket. =A0 The HTTP server must be able, via the Upgrade request to consider only (a)
the URL and (b) the Upgrade protocol and decide if it will support it.
If it will, then all further negotiation is the responsibility of the
protocol being upgraded to.

I dunno that seems clean to me. =A0Somebody connects claiming to want webso= cket service then the websocket plugin / library / code is obviously the pl= ace to form an opinion about the connection request. =A0If that's expen= sive or insecure then that's an implementation issue?

True, in some implementations the cost of passing the H= TTP Upgrade request over to be evaluated won't be much. =A0However, in = the work I've been doing, spawning the WebSocket server as a seperate p= rocess has been a good & valid method (for many unrelated reasons), thi= s can be expensive. =A0 =A0It seems to me that when deployed in a HTTP stac= k, letting the webserver decided based on URL & Upgrade: protocol if it= will even consider supporting it is a useful arrangement. =A0Also, I belie= ve it more properly reflects the real conceptual domains.

For example, if the HTTP server can decide, "Yes, = I'm going to do WebSocket for that URL", it can chroot to that URL= s place in the filesystem, instantiate the WebSocket server/handler and pas= s the TCP connection off with a clean=A0conscience. =A0 =A0

Evaluating the validity of a URL is not the job of a tr= ansport protocol. =A0 WebSocket is a transport protocol.


4. When WebSocket is provided as a stand-alone process, using a HTTP
Upgrade as the handshake presents at least two problems. =A0(a) changing from line-oriented I/O (in the HTTP handshake) to a byte-oriented I/O

libwebsockets uses a bytewise parser for both HTTP and websocket protocol t= raffic. =A0It could have bugs like anything else but it's not inherentl= y more fragile or dodgy or 'line orientated', it's the same byt= ewise state machine. =A0So again this is implementation and there are reaso= nable and secure implementations possible.

As previously mentioned, it's not the doing I have = a problem with. =A0It's what the doing implies.

=A0
(for WebSocket frames) is = awkward and potentially error prone, and (b)
any HTTP client-agent can potentially make a request to a WebSocket
server and get back a HTTP response, this exposes the availability and
capabilities of the WebSocket server to a client-agent that is not
actually a WebSocket client. =A0 Neither of these concerns is really all that severe, but it is something to be aware of.

Well, if it doesn't like what is told, typically the server will just h= ang upon the client. =A0To get anything long-lived you have to have correct= magic in the keys in the client request.

Possibly causing client-agent timeout delays. =A0Perhaps not. =A0 That= 's the client-agent's problem. =A0 =A0Again, I don't this is al= l that serious of a concern, just that it's another ramification of the= mixing of HTTP and WebSockets.

And don't get me started on the magic keys (Sec-Web= Socket-Key). =A0 Personally I believe this part of the handshake to be usel= ess hand-waving that does not provide what it's supposedly intended to = do. =A0 =A0The client can generate any value and ignore the server's re= sponse, it proves nothing. =A0 =A0 =A0I have not expressed a concern about = it as it is harmless and not onerous to implement. =A0And I'm ok with i= mplementing hand-waving if it'll get asynchronous traffic with a browse= r client out the door into the real world sooner.



-Andy

--0016e6d59d668c8177049fd9dfec-- From dendicott@gmail.com Fri Apr 1 04:45:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4473A6808 for ; Fri, 1 Apr 2011 04:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaI-kbW+T9ME for ; Fri, 1 Apr 2011 04:45:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4798B3A680E for ; Fri, 1 Apr 2011 04:45:21 -0700 (PDT) Received: by wyb29 with SMTP id 29so3235696wyb.31 for ; Fri, 01 Apr 2011 04:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HAsfsKrEjHAZ+/dSO1sa7YQplu1xbrnd9c1/OtNnDYk=; b=koenBhao5qpnaNZlCfwysfJSjSUYljM1O/iQut5a/HZ09vMPG5BbiDi+bE3sWgurBl uQl3pDo1JcvqZfrSguWUBx8gPRw2w2/QIbgcszlyCEWKO6yrryNYKaG08nxNVc7xVfZq IoRNJpM0lRJMV5uvM4FGKtn+UIY94LGqObEDk= 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=bWNk7RgX+i8ozcVObxpmfq19Ak78P0abPcMbNU/uEmrKrQ9eN8qqDZRwf2ORZQJ5M8 RpEZ9kT8mmR9T9NU9qEwLQ7a9ACAo9+ikJLdbPQXebB26h0HCcNYhe9DazoqXHb38tPZ 6wIt6LUNfb+BJiwiazcIJSYS+y4cvoaBEEfl0= MIME-Version: 1.0 Received: by 10.216.168.67 with SMTP id j45mr717103wel.101.1301658420832; Fri, 01 Apr 2011 04:47:00 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 04:47:00 -0700 (PDT) In-Reply-To: <000701cbf022$9adb51d0$d091f570$@net> References: <000701cbf022$9adb51d0$d091f570$@net> Date: Fri, 1 Apr 2011 07:47:00 -0400 Message-ID: From: David Endicott To: Greg Longtin Content-Type: multipart/alternative; boundary=00163683340acae95a049fd9f717 Cc: hybi Subject: Re: [hybi] Two Questions 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, 01 Apr 2011 11:45:22 -0000 --00163683340acae95a049fd9f717 Content-Type: text/plain; charset=ISO-8859-1 I believe that HTTP Upgrade is a HTTP request. As such I would expect an HTTP response. Therefore I should expect any valid HTTP response. I would *strongly* argue that WebSockets must NOT be restricted to a specific port. Transport protocols must not be bound to a specific port. On Fri, Apr 1, 2011 at 12:09 AM, Greg Longtin wrote: > To all, > > I had to ask... > All the time, with the asking. :-) --00163683340acae95a049fd9f717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe that HTTP Upgrade is a HTTP request. =A0As such I would expect an= HTTP response. =A0 Therefore I should expect any valid HTTP response.
=
I would *strongly* argue that WebSockets must NOT be restric= ted to a specific port. =A0=A0

Transport protocols must not be bound to a specific por= t.



On Fri, Apr = 1, 2011 at 12:09 AM, Greg Longtin <Greg@championent.net> wrote:
To all,

I had to ask...

All the time, with the = asking. =A0 =A0:-)=A0

--00163683340acae95a049fd9f717-- From Greg@ChampionEnt.net Fri Apr 1 05:29:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2393A6904 for ; Fri, 1 Apr 2011 05:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oza5RQJLrJNQ for ; Fri, 1 Apr 2011 05:29:06 -0700 (PDT) Received: from smtpout-2.iphouse.net (smtpout-2.iphouse.net [209.240.70.141]) by core3.amsl.com (Postfix) with ESMTP id 411E628C361 for ; Fri, 1 Apr 2011 05:24:01 -0700 (PDT) Received: from smtpout-2.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 103E91CCDA for ; Fri, 1 Apr 2011 07:25:41 -0500 (CDT) Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-2.iphouse.net (Postfix) with ESMTPSA id B85CB1CCD9 for ; Fri, 1 Apr 2011 07:25:40 -0500 (CDT) From: "Greg Longtin" To: "hybi" References: <000601cbf022$4c420320$e4c60960$@net> In-Reply-To: Date: Fri, 1 Apr 2011 07:25:39 -0500 Message-ID: <000f01cbf067$e9fab310$bdf01930$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvwYVw6uWOpxBv9STC2E2YFaAS80AABEZEw Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 12:29:17 -0000 David, First of all, my interest in WS is in using it for LAN based real-time control. Simply put, sockets in a browser. I know very little about DOS attacks. > Requiring the WebSocket server to evaluate any incoming HTTP request increases the possibility of denial-of-service as any HTTP client-agent can send any HTTP request (Upgrade or not) and make the WebSocket server evaluate it before terminating connection. I would assume that most DOS attacks are not using traditional client-agents (browsers), and hence, can adapt to whatever 'packet layout' suits their needs. Also, I suspect most current DOS prevention technology is based on http filtering, which would imply that it could filter DOS WS upgrade requests with minimal modification. If the handshake request was byte oriented, I suspect a small percentage of current 'firewall/protection' equipment could correctly filter it against WS DOS attacks. Greg Longtin From dendicott@gmail.com Fri Apr 1 05:52:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970EA3A681F for ; Fri, 1 Apr 2011 05:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJOP7fsSBt-G for ; Fri, 1 Apr 2011 05:52:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 62E6D3A6838 for ; Fri, 1 Apr 2011 05:52:01 -0700 (PDT) Received: by wyb29 with SMTP id 29so3294129wyb.31 for ; Fri, 01 Apr 2011 05:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ffH5muvifGnq2avdg9kOnjbTbDuR6l8+yZjqVL7QR5A=; b=DCTldwj7C4IwR396Sf4FAMvxs1J6HogUiv8sTodP/i7BS56EYhFdM8cIBDmN8bUdmK eJoWV74y9DYQeDWAcOJkMh4WPhjVlJQko2U/3AD63CKzMF7d5fgw3nDSkQaUdGYjnTHp xJT9LviPh98lvzJtD71z+7Nc5menHE2+U45Uo= 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=mXKOmhWfcNNdImxyI4Kd2/Z6k46sopNHpNVKDuywFW9nXX52DJBN1jwSrWju4sK8Td eEnNhmSJmivyttIL8OOVhK6Iarq80MXg5VZjCHZ/kF6YYsZKlDk3sdpHtDdMYtzdHKG1 ayFKb7h6S7nO+I7xlQQ4+nCpicahh6ut7D1Oo= MIME-Version: 1.0 Received: by 10.216.221.16 with SMTP id q16mr3842831wep.71.1301662420971; Fri, 01 Apr 2011 05:53:40 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 05:53:40 -0700 (PDT) In-Reply-To: <000f01cbf067$e9fab310$bdf01930$@net> References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> Date: Fri, 1 Apr 2011 08:53:40 -0400 Message-ID: From: David Endicott To: Greg Longtin Content-Type: multipart/alternative; boundary=0016e64c1afc3830f8049fdae642 Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 12:52:03 -0000 --0016e64c1afc3830f8049fdae642 Content-Type: text/plain; charset=ISO-8859-1 Hey Greg, Your use case sounds interesting. In my case, asynchronous communication with a browser addresses a *very* pressing (ie. critical) need in my industry. We work with "real-time" data (financial market data, if you want to be specific) and we've been unable to take real advantage of web technologies because of the lack of server-push type transports. I also consider this to be sockets-in-a-browser - but the framed nature works nicely with the browser side Javascript object. My intention is to be tossing around JSON strings that represent messages over WebSocket. Aside: why do we differentiate between binary and text frames? WebSockets is a transport protocol with a length field. The payload is opaque. Why does it care what the content-type is? Wouldn't interpretation of content-type be up to the application layer? (like how an application decides if it'll open a file in text or binary mode). Not that I really care, just curious. While most of our stuff will be on private networks (ie. not via public web presence), dealing with confused client-agents or badly implemented customer code, we do have to consider DOS issues, even unintended ones. When a HTTP server has to instantiate a WebSocket server handler to evaluate the handshake, the time & cost is greater than if it can just reject it out of hand. It gets worse if the WebSocket server needs to spin up databases or open a back-end connection to other servers (authentication, data providers, etc.). Yes, a good implementation won't do that until the handshake completes successfully, but allowing the HTTP server to decide on it's own if it will accept WebSocket (HTTP Upgrade: WebSocket) on the requested URL saves several steps. And, of course, if the WebSocket server is operating stand-alone, it can drop connection within the first few bytes, assuming we're not using a HTTP Upgrade handshake. I don't believe the Sec-WebSocket-Protocol is the concern of the HTTP server. That is an aspect of WebSockets and I believe should properly be part of that layer. The HTTP server can define, "I support WebSockets on that URL" and then WebSockets can specify which sub-protocols (ie. application protocols) it is going to carry. These are separate domains of responsibility. On Fri, Apr 1, 2011 at 8:25 AM, Greg Longtin wrote: > David, > > First of all, my interest in WS is in using it for LAN based real-time > control. Simply put, sockets in a browser. I know very little about DOS > attacks. > > > Requiring the WebSocket server to evaluate any incoming HTTP request > increases the possibility of denial-of-service as any HTTP client-agent can > send any HTTP request (Upgrade or not) and make the WebSocket server > evaluate it before terminating connection. > > I would assume that most DOS attacks are not using traditional > client-agents > (browsers), and hence, can adapt to whatever 'packet layout' suits their > needs. Also, I suspect most current DOS prevention technology is based on > http filtering, which would imply that it could filter DOS WS upgrade > requests with minimal modification. > > If the handshake request was byte oriented, I suspect a small percentage of > current 'firewall/protection' equipment could correctly filter it against > WS > DOS attacks. > > Greg Longtin > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016e64c1afc3830f8049fdae642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Greg,

Your use case sounds interesting. =A0 In my ca= se, asynchronous communication with a browser addresses a *very* pressing (= ie. critical) need in my industry. =A0We work with "real-time" da= ta =A0(financial market data, if you want to be specific) and we've bee= n unable to take real advantage of web technologies because of the lack of = server-push type transports. =A0 I also consider this to be sockets-in-a-br= owser - but the framed nature works nicely with the browser side Javascript= object. =A0 My intention is to be tossing around JSON strings that represe= nt messages over WebSocket. =A0=A0

Aside: why do we differentiate between binary and text = frames? =A0WebSockets is a transport protocol with a length field. =A0The p= ayload is opaque. =A0 Why does it care what the content-type is? =A0 Wouldn= 't interpretation of content-type be up to the application layer? =A0(l= ike how an application decides if it'll open a file in text or binary m= ode). =A0 =A0Not that I really care, just curious.

While most of our stuff will be on private networks (ie= . not via public web presence), dealing with confused client-agents or badl= y implemented customer code, we do have to consider DOS issues, even uninte= nded ones.

When a HTTP server has to=A0instantiate=A0a WebSocket s= erver handler to evaluate the handshake, the time & cost is greater tha= n if it can just reject it out of hand. =A0It gets worse if the WebSocket s= erver needs to spin up databases or open a back-end connection to other ser= vers (authentication, data providers, etc.). =A0 =A0Yes, a good implementat= ion won't do that until the handshake completes successfully, but allow= ing the HTTP server to decide on it's own if it will accept WebSocket (= HTTP Upgrade: WebSocket) on the requested URL saves several steps. =A0 And,= of course, if the WebSocket server is operating stand-alone, it can drop c= onnection within the first few bytes, assuming we're not using a HTTP U= pgrade handshake.

I don't believe the Sec-WebSocket-Protocol is the c= oncern of the HTTP server. =A0That is an aspect of WebSockets and I believe= should properly be part of that layer. =A0The HTTP server can define, &quo= t;I support WebSockets on that URL" and then WebSockets can specify wh= ich sub-protocols (ie. application protocols) it is going to carry. =A0 The= se are=A0separate=A0domains of=A0responsibility.



On Fri, A= pr 1, 2011 at 8:25 AM, Greg Longtin <Greg@championent.net> wrote:
David,

First of all, my interest in WS is in using it for LAN based real-time
control. =A0Simply put, sockets in a browser. =A0I know very little about D= OS
attacks.

> Requiring the WebSocket server to evaluate any incoming HTTP request increases the possibility of denial-of-service as any HTTP client-agent can=
send any HTTP request (Upgrade or not) and make the WebSocket server
evaluate it before terminating connection.

I would assume that most DOS attacks are not using traditional client= -agents
(browsers), and hence, can adapt to whatever 'packet layout' suits = their
needs. =A0Also, I suspect most current DOS prevention technology is based o= n
http filtering, which would imply that it could filter DOS WS upgrade
requests with minimal modification.

If the handshake request was byte oriented, I suspect a small percentage of=
current 'firewall/protection' equipment could correctly filter it a= gainst WS
DOS attacks.

Greg Longtin

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

--0016e64c1afc3830f8049fdae642-- From Greg@ChampionEnt.net Fri Apr 1 06:06:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036D63A6838 for ; Fri, 1 Apr 2011 06:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ9N8z+BpUxA for ; Fri, 1 Apr 2011 06:06:22 -0700 (PDT) Received: from smtpout-1.iphouse.net (smtpout-1.iphouse.net [209.240.70.140]) by core3.amsl.com (Postfix) with ESMTP id 64F2A3A6819 for ; Fri, 1 Apr 2011 06:06:21 -0700 (PDT) Received: from smtpout-1.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id A9B891CDC0 for ; Fri, 1 Apr 2011 08:08:00 -0500 (CDT) Received: from GJL8710w (longtin.dsl.visi.com [209.98.144.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-1.iphouse.net (Postfix) with ESMTPSA id 5A8A21CDBE for ; Fri, 1 Apr 2011 08:08:00 -0500 (CDT) From: "Greg Longtin" To: "hybi" References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> In-Reply-To: Date: Fri, 1 Apr 2011 08:07:59 -0500 Message-ID: <001601cbf06d$d3b5f550$7b21dff0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvwa9QNrkO0nOBzSR6EcdDM+ZuNtgAARsAQ Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 13:06:23 -0000 David, > Aside: why do we differentiate between binary and text frames? So the browser/user-agent knows what to do with it? AFAIK, that API at the W3C/WhatWG is TBD. > allowing the HTTP server to decide on its own if it will accept WebSocket (HTTP Upgrade: WebSocket) on the requested URL saves several steps. I believe that was the reason the handshake is HTTP, so (at some point) HTTP servers could be configured to accept/reject the WS upgrade. In the mean time... Confused. I thought you wanted a non HTTP handshake. > My intention is to be tossing around JSON strings That's what I'm using. Certainly helpful that JavaScript (ECMA5?) natively supports JSON. Thanks, Greg Longtin From dendicott@gmail.com Fri Apr 1 06:36:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F167B3A6835 for ; Fri, 1 Apr 2011 06:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9dj9gv74lHl for ; Fri, 1 Apr 2011 06:36:41 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 867213A680F for ; Fri, 1 Apr 2011 06:36:40 -0700 (PDT) Received: by wwa36 with SMTP id 36so2867019wwa.13 for ; Fri, 01 Apr 2011 06:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4sLJKRk4+TY3okhZlDU8CHfqPP6nBE1gb6pnpufocw8=; b=mVY8ICWDZ7hy1uuaQgRCKOIbIJuIUWseRqUU3Eea9mBs0iaXhX7MwPis4Vbyo9MWiB g24WNIdn9BKMXNA0RWhLUN4C4EHkZtN0Rjb/N4+hFr56sJKZqZioGMWTYc4v03/Zo3EL PgtNCJDuQUMafvvrnk/pbFHkLSG1psVd0N1RU= 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=IRjqW9acqVh38ZNkb1EgrIHqygWmkMSGnS3X0NzQnL5UXPNXuLUtFeMY3JLcLIeJhe fv9D+BiqIZae+Li9ly9GPkMSuKXk9E3Coo2JNh+W0cTCFY3dDT9kad7DsuUWkHMd0i7G pxZD428A7Gll/jNoEwtJmO0tWdTpFpqOnBraM= MIME-Version: 1.0 Received: by 10.216.145.92 with SMTP id o70mr1897105wej.86.1301665100208; Fri, 01 Apr 2011 06:38:20 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 06:38:20 -0700 (PDT) In-Reply-To: <001601cbf06d$d3b5f550$7b21dff0$@net> References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> Date: Fri, 1 Apr 2011 09:38:20 -0400 Message-ID: From: David Endicott To: Greg Longtin Content-Type: multipart/alternative; boundary=0016e6dd8a62ea1ba5049fdb85eb Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 13:36:42 -0000 --0016e6dd8a62ea1ba5049fdb85eb Content-Type: text/plain; charset=ISO-8859-1 > > > Aside: why do we differentiate between binary and text frames? > > So the browser/user-agent knows what to do with it? AFAIK, that API at the > W3C/WhatWG is TBD. > Yes, but... If we're going to tell the user-agent what the content type is, we should tell them the 'content-type', not a half-arsed binary/text. If we're going to leave the content type knowledge to an understanding between the server & user-agent at a higher level, then an untyped opaque payload would be appropriate. Personally I like to view WebSockets as "framed TCP", so opaque payloads would be my choice. In my case, when as a user-agent, I connect with WebSocket sub-protocol "foo", I know that traffic via "foo" is going to be in some format. That's a property of the specification of sub-protocol "foo". If "foo" is going to support multiple content-types, I will need to include that ability as part of sub-protocol "foo". In neither case should WebSocket, the transport, care what the payload is. > allowing the HTTP server to decide on its own if it will accept WebSocket > (HTTP Upgrade: WebSocket) on the requested URL saves several steps. > > I believe that was the reason the handshake is HTTP, so (at some point) > HTTP > servers could be configured to accept/reject the WS upgrade. In the mean > time... > > Confused. I thought you wanted a non HTTP handshake. > Oh I do - I was probably confusing things there, jumping between what-is and what-I-would. I would like to see the HTTP Upgrade include only "Upgrade: WebSocket" and the URL. ie. HTTP Upgrade is not part of WebSockets, but just another mechanism for establishing it. Then, the WebSocket negotiation/handshake (using websocket frames) would specify the application protocol (aka: Sec-WebSocket-Protocol) - and any other parameters of the connection (compression, masking, palindromic invariance, etc.) Thus, once a "WebSocket" connection is established (by whatever means), the two ends can determine the context of their connection (sub-protocol, capabilities, etc.). When deployed in a HTTP stack and using HTTP Upgrade, the webserver can decide if it will establish the connection based on it's domain of responsibility (Upgrade & URL) and WebSockets can decide if it will accept the connection based on it's domain of responsibility (application protocol, etc.) The URL is a parameter that identifies content resource (and might have been re-mapped/translated/redirected by the HTTP server). When deployed as a stand-alone, the WebSocket can decide if it will accept the connection based on .... hey, exactly like the previous paragraph. > My intention is to be tossing around JSON strings > > That's what I'm using. Certainly helpful that JavaScript (ECMA5?) natively > supports JSON. > Thank the Goddess for fortuitous happenstance. Ends up making a really clean application protocol framework, doesn't it? --0016e6dd8a62ea1ba5049fdb85eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Aside: why do we differentiate between binary and text frames?

So the browser/user-agent knows what to do with it? =A0AFAIK, that AP= I at the
W3C/WhatWG is TBD.

Yes, but... =A0 =A0 = If we're going to tell the user-agent what the content type is, we shou= ld tell them the 'content-type', not a half-arsed binary/text. =A0 = If we're going to leave the content type knowledge to an understanding = between the server & user-agent at a higher level, then an untyped opaq= ue payload would be appropriate. =A0Personally I like to view WebSockets as= "framed TCP", so opaque payloads would be my choice. =A0

=A0In my case, when as a user-agent, I connect with Web= Socket sub-protocol "foo", I know that traffic via "foo"= ; is going to be in some format. =A0That's a property of the specificat= ion of sub-protocol "foo". =A0 If "foo" is going to sup= port multiple content-types, I will need to include that ability as part of= sub-protocol "foo". =A0 In neither case should WebSocket, the tr= ansport, care what the payload is.


> allowing= the HTTP server to decide on its own if it will accept WebSocket
(HTTP Upgrade: WebSocket) on the requested URL saves seve= ral steps.

I believe that was the reason the handshake is HTTP, so (at some poin= t) HTTP
servers could be configured to accept/reject the WS upgrade. =A0In the mean=
time...

Confused. =A0I thought you wanted a non HTTP handshake.

Oh I do - I was probably confusing things there, jumping b= etween what-is and what-I-would.=A0

I would like t= o see the HTTP Upgrade include only "Upgrade: WebSocket" and the = URL. =A0 ie. HTTP Upgrade is not part of WebSockets, but just another mecha= nism for establishing it. =A0=A0

Then, the WebSocket negotiation/handshake (using websoc= ket frames) would specify the application protocol (aka: Sec-WebSocket-Prot= ocol) - and any other parameters of the connection (compression, masking,= =A0palindromic=A0invariance, etc.) =A0 =A0

Thus, once a "WebSocket" connection is establ= ished (by whatever means), the two ends can determine the context of their = connection (sub-protocol, capabilities, etc.). =A0

When deployed in a HTTP stack and using HTTP Upgrade, the webserver can dec= ide if it will establish the connection based on it's domain of=A0respo= nsibility=A0(Upgrade & URL) and WebSockets can decide if it will accept= the connection based on it's domain of responsibility (application pro= tocol, etc.) =A0 The URL is a parameter that identifies content resource (a= nd might have been re-mapped/translated/redirected by the HTTP server).

When deployed as a stand-alone, the WebSocket can decid= e if it will accept the connection based on .... hey, exactly like the prev= ious paragraph.


> My intention is to be tossing around JSON strings
That's what I'm using. =A0Certainly helpful that JavaScript (= ECMA5?) natively
supports JSON.

Thank the Goddess for=A0= fortuitous=A0happenstance. =A0 =A0Ends up making a really clean application= protocol framework, doesn't it?


--0016e6dd8a62ea1ba5049fdb85eb-- From metajack@gmail.com Fri Apr 1 06:52:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AE13A67FC for ; Fri, 1 Apr 2011 06:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGMLMhkccKHj for ; Fri, 1 Apr 2011 06:52:42 -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 B39133A67FA for ; Fri, 1 Apr 2011 06:52:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so4114696iwn.31 for ; Fri, 01 Apr 2011 06:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AOdzzjeixbQsjMauJlg23JgLC6QjJzVcEECDlFifGzs=; b=lhRIYyFltmGNaJIj7lY0NVRhZdei1UiSaBNyt2DiTDwyqZ1T9k4VzwFMeWra8cO5mn btYvF2j5Wo6HgKK39Jw9lovC9xdw6obTVPATalPuG8xlH8l/9rsJTfsq9Eqqei1MLcpc ScHuDgZO5+C/HMAk/FacBQeoaFLjERKAMkpgY= 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:cc:content-type :content-transfer-encoding; b=oImbPyS7f6UYITiz7S0o8qF+e5ferPBbk9DgbPOE2ANCdb3BX6CPPXgkoQrLdcS/KE C9eFclGEObhcIQFZpq+I7tBkpl7icDeZpCd4RpWUja8oWP5iWuK8+SDQjO0sJ0JzGCGx Dt9XaazFfw5C0kZz/y66Uya0vornYob7LTjVs= MIME-Version: 1.0 Received: by 10.231.61.65 with SMTP id s1mr2127041ibh.120.1301666062813; Fri, 01 Apr 2011 06:54:22 -0700 (PDT) Sender: metajack@gmail.com Received: by 10.231.34.76 with HTTP; Fri, 1 Apr 2011 06:54:22 -0700 (PDT) In-Reply-To: <4D959704.1090303@warmcat.com> References: <000701cbf022$9adb51d0$d091f570$@net> <4D959704.1090303@warmcat.com> Date: Fri, 1 Apr 2011 07:54:22 -0600 X-Google-Sender-Auth: 6oHv_oYRnL6RdGYHld4qLvE1P6A Message-ID: From: Jack Moffitt To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi Subject: Re: [hybi] Two Questions 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, 01 Apr 2011 14:00:50 -0000 >> I would like to know, from an HTTP perspective, if a generic and valid >> *HTTP* upgrade request cannot be replied to, per the HTTP spec. =A0This = (a >> none response) seems to be a correct response per the WS 06 spec to an >> invalid *WebSocket* upgrade/handshake request from a client. > > The spec can't really control what an intermediary might return anyway. = =A0So > a restrictive firewall might come back with a 5xx http response without e= ven > contacting the websocket server. This can actually be a feature that the underlying protocol doesn't return certain error codes. For example, XMPP BOSH defines only 4xx level errors, not 5xx ones, so any 5xx error must be a failure at an intermediary. This serves a few purposes: 1) We now can tell at the application layer whether the HTTP failure represents failure of the BOSH protocol stack, in which case the error code has an interpretation, 2) We know it failed at the intermediary layer. If it fails on first request, it's probably a configuration error. If it fails after a successful request, it's probably a transient issue. Please note also that XMLHTTPRequest returns a whole slew of non-HTTP errors (0 and 1xxxx) for things like socket timeouts and dns lookup failures. It would be nice if the same errors existed in the JS API, although I expect that is not a problem for HyBi. jack. From ferg@caucho.com Fri Apr 1 09:58:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7961D3A6900 for ; Fri, 1 Apr 2011 09:58:43 -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=[AWL=-0.000, 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 mV9+yecSlTe2 for ; Fri, 1 Apr 2011 09:58:42 -0700 (PDT) Received: from nm9-vm0.bullet.mail.sp2.yahoo.com (nm9-vm0.bullet.mail.sp2.yahoo.com [98.139.91.196]) by core3.amsl.com (Postfix) with SMTP id F144A3A68BF for ; Fri, 1 Apr 2011 09:58:22 -0700 (PDT) Received: from [98.139.91.67] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 01 Apr 2011 17:00:00 -0000 Received: from [98.139.91.57] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 01 Apr 2011 17:00:00 -0000 Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 01 Apr 2011 17:00:00 -0000 X-Yahoo-Newman-Id: 803050.49607.bm@omp1057.mail.sp2.yahoo.com Received: (qmail 32075 invoked from network); 1 Apr 2011 17:00:00 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 01 Apr 2011 10:00:00 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: h3fpbBMVM1kE4IzHLMQKXwF2V8rOalG7_athNrI2gAUvYHP O0ZCBQwiQUW4UqHxQwnaufM3ObS1bee1SOErf3FE3qtmasMzj0XhLjwHydNO aid.lO4IvqqR2Ug5B2oXW3OYEzZylVNNPqeZF6Z7W4oKZ_UX9i8R5D4uauee 9IMENBpDs6FcYH9OQTZsMkxsE43Xo78K314kCFmAiyu0Mju25QIGIftQd4qr SmkZAlnbct4MdGrboeUOLhsVJsU4yUGuVrCkNc.qp5Tf8nYaowNlWfnLc.OQ Ky2wSeJft8HIsLjybbDsKlJpw2E8DqvDgb0ftCihweSwIDBYvHKqScXhKmjs OAyeSWCLnaqJpxZ3OXOEcGGHzSaqefkWzNyJ7IZ4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D960490.2040804@caucho.com> Date: Fri, 01 Apr 2011 10:00:00 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070606030907070804000302" Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 16:58:43 -0000 This is a multi-part message in MIME format. --------------070606030907070804000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/01/2011 06:38 AM, David Endicott wrote: > > > Aside: why do we differentiate between binary and text frames? > > So the browser/user-agent knows what to do with it? AFAIK, that > API at the > W3C/WhatWG is TBD. > > > Yes, but... If we're going to tell the user-agent what the content > type is, we should tell them the 'content-type', not a half-arsed > binary/text. If we're going to leave the content type knowledge to > an understanding between the server & user-agent at a higher level, > then an untyped opaque payload would be appropriate. Personally I > like to view WebSockets as "framed TCP", so opaque payloads would be > my choice. As I remember, the text/binary is a pragmatic decision primarily based on balancing browser API needs with low-level specialized protocols. Tossing around JSON, for example, is really text. And since no one wants to make the ASCII/ISO-8859-1 assumptions/mistakes again, it's good to enforce UTF-8 encoding at the framing layer so it's correct from the beginning. For more specialized clients (like some I'm working on), having the direct binary is what's needed. We did discuss a full mime-type extension, but that very quickly became complicated for a simple framing protocol. So while text/binary is perhaps not the most minimal solution possible, it's still simple and solves the main use cases. -- Scott > > In my case, when as a user-agent, I connect with WebSocket > sub-protocol "foo", I know that traffic via "foo" is going to be in > some format. That's a property of the specification of sub-protocol > "foo". If "foo" is going to support multiple content-types, I will > need to include that ability as part of sub-protocol "foo". In > neither case should WebSocket, the transport, care what the payload is. > > > > allowing the HTTP server to decide on its own if it will accept > WebSocket > (HTTP Upgrade: WebSocket) on the requested URL saves several steps. > > I believe that was the reason the handshake is HTTP, so (at some > point) HTTP > servers could be configured to accept/reject the WS upgrade. In > the mean > time... > > Confused. I thought you wanted a non HTTP handshake. > > > Oh I do - I was probably confusing things there, jumping between > what-is and what-I-would. > > I would like to see the HTTP Upgrade include only "Upgrade: WebSocket" > and the URL. ie. HTTP Upgrade is not part of WebSockets, but just > another mechanism for establishing it. > > Then, the WebSocket negotiation/handshake (using websocket frames) > would specify the application protocol (aka: Sec-WebSocket-Protocol) - > and any other parameters of the connection (compression, > masking, palindromic invariance, etc.) > > Thus, once a "WebSocket" connection is established (by whatever > means), the two ends can determine the context of their connection > (sub-protocol, capabilities, etc.). > > When deployed in a HTTP stack and using HTTP Upgrade, the webserver > can decide if it will establish the connection based on it's domain > of responsibility (Upgrade & URL) and WebSockets can decide if it will > accept the connection based on it's domain of responsibility > (application protocol, etc.) The URL is a parameter that identifies > content resource (and might have been re-mapped/translated/redirected > by the HTTP server). > > When deployed as a stand-alone, the WebSocket can decide if it will > accept the connection based on .... hey, exactly like the previous > paragraph. > > > > My intention is to be tossing around JSON strings > > That's what I'm using. Certainly helpful that JavaScript (ECMA5?) > natively > supports JSON. > > > Thank the Goddess for fortuitous happenstance. Ends up making a > really clean application protocol framework, doesn't it? > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------070606030907070804000302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/01/2011 06:38 AM, David Endicott wrote:
> Aside: why do we differentiate between binary and text frames?

So the browser/user-agent knows what to do with it?  AFAIK, that API at the
W3C/WhatWG is TBD.

Yes, but...     If we're going to tell the user-agent what the content type is, we should tell them the 'content-type', not a half-arsed binary/text.   If we're going to leave the content type knowledge to an understanding between the server & user-agent at a higher level, then an untyped opaque payload would be appropriate.  Personally I like to view WebSockets as "framed TCP", so opaque payloads would be my choice. 

As I remember, the text/binary is a pragmatic decision primarily based on balancing browser API needs with low-level specialized protocols.

Tossing around JSON, for example, is really text. And since no one wants to make the ASCII/ISO-8859-1 assumptions/mistakes again, it's good to enforce UTF-8 encoding at the framing layer so it's correct from the beginning.

For more specialized clients (like some I'm working on), having the direct binary is what's needed.

We did discuss a full mime-type extension, but that very quickly became complicated for a simple framing protocol.

So while text/binary is perhaps not the most minimal solution possible, it's still simple and solves the main use cases.

-- Scott


 In my case, when as a user-agent, I connect with WebSocket sub-protocol "foo", I know that traffic via "foo" is going to be in some format.  That's a property of the specification of sub-protocol "foo".   If "foo" is going to support multiple content-types, I will need to include that ability as part of sub-protocol "foo".   In neither case should WebSocket, the transport, care what the payload is.


> allowing the HTTP server to decide on its own if it will accept WebSocket
(HTTP Upgrade: WebSocket) on the requested URL saves several steps.

I believe that was the reason the handshake is HTTP, so (at some point) HTTP
servers could be configured to accept/reject the WS upgrade.  In the mean
time...

Confused.  I thought you wanted a non HTTP handshake.

Oh I do - I was probably confusing things there, jumping between what-is and what-I-would. 

I would like to see the HTTP Upgrade include only "Upgrade: WebSocket" and the URL.   ie. HTTP Upgrade is not part of WebSockets, but just another mechanism for establishing it.   

Then, the WebSocket negotiation/handshake (using websocket frames) would specify the application protocol (aka: Sec-WebSocket-Protocol) - and any other parameters of the connection (compression, masking, palindromic invariance, etc.)    

Thus, once a "WebSocket" connection is established (by whatever means), the two ends can determine the context of their connection (sub-protocol, capabilities, etc.).  

When deployed in a HTTP stack and using HTTP Upgrade, the webserver can decide if it will establish the connection based on it's domain of responsibility (Upgrade & URL) and WebSockets can decide if it will accept the connection based on it's domain of responsibility (application protocol, etc.)   The URL is a parameter that identifies content resource (and might have been re-mapped/translated/redirected by the HTTP server).

When deployed as a stand-alone, the WebSocket can decide if it will accept the connection based on .... hey, exactly like the previous paragraph.


> My intention is to be tossing around JSON strings

That's what I'm using.  Certainly helpful that JavaScript (ECMA5?) natively
supports JSON.

Thank the Goddess for fortuitous happenstance.    Ends up making a really clean application protocol framework, doesn't it?



_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi

--------------070606030907070804000302-- From dendicott@gmail.com Fri Apr 1 10:15:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB063A68C3 for ; Fri, 1 Apr 2011 10:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDP4knliRqND for ; Fri, 1 Apr 2011 10:15:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 63AF63A679F for ; Fri, 1 Apr 2011 10:15:23 -0700 (PDT) Received: by wwa36 with SMTP id 36so3047403wwa.13 for ; Fri, 01 Apr 2011 10:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AooIVqV8n6f/Daf2t1sEAYMIwGun1AejdWPrhPPL8a8=; b=KBk09PhQolEH8UzQejHP6bJS8VKBNXnSbiWhHUUA9KOFNMUPOYHDQNFH/6EYV0jIOk 2VGNAdT7QzdapkR32XQZgTYcUJbfAnOaHX/OeXlD4VIQN/qGGc32yCnmKD1woabHNKCY k3xPIIkwF6IrqSH9hoE54PhYC9vOIODq4R6p0= 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=ZDx4onNN9pSQG6DfkKxvgYN5OFBw97nwgTb6bjpE1PYPVY+QHtikT+PjHZZgX8wKrW Thzr2WM9uegZNPhtA8MlGJFBfWsnZJO6thaNAWkps2q/LNIpalK8gzv68XsG65nrCkHg ef8U6WXNwNkTIdmPxp+nd3/2hIHf/Ok6LyOgQ= MIME-Version: 1.0 Received: by 10.216.67.17 with SMTP id i17mr3958550wed.101.1301678223215; Fri, 01 Apr 2011 10:17:03 -0700 (PDT) Received: by 10.216.153.41 with HTTP; Fri, 1 Apr 2011 10:17:03 -0700 (PDT) In-Reply-To: <4D960490.2040804@caucho.com> References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <4D960490.2040804@caucho.com> Date: Fri, 1 Apr 2011 13:17:03 -0400 Message-ID: From: David Endicott To: Scott Ferguson Content-Type: multipart/alternative; boundary=000e0ce0b4921b5035049fde9403 Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 17:15:25 -0000 --000e0ce0b4921b5035049fde9403 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 1, 2011 at 1:00 PM, Scott Ferguson wrote: > On 04/01/2011 06:38 AM, David Endicott wrote: > > > Aside: why do we differentiate between binary and text frames? >> >> So the browser/user-agent knows what to do with it? AFAIK, that API at >> the >> W3C/WhatWG is TBD. >> > > Yes, but... If we're going to tell the user-agent what the content > type is, we should tell them the 'content-type', not a half-arsed > binary/text. If we're going to leave the content type knowledge to an > understanding between the server & user-agent at a higher level, then an > untyped opaque payload would be appropriate. Personally I like to view > WebSockets as "framed TCP", so opaque payloads would be my choice. > > > As I remember, the text/binary is a pragmatic decision primarily based on > balancing browser API needs with low-level specialized protocols. > > Tossing around JSON, for example, is really text. And since no one wants to > make the ASCII/ISO-8859-1 assumptions/mistakes again, it's good to enforce > UTF-8 encoding at the framing layer so it's correct from the beginning. > > For more specialized clients (like some I'm working on), having the direct > binary is what's needed. > > We did discuss a full mime-type extension, but that very quickly became > complicated for a simple framing protocol. > > So while text/binary is perhaps not the most minimal solution possible, > it's still simple and solves the main use cases. > > Yes, I would agree the benefits / convenience for the client-agent outweigh any "purity of design" considerations. I was not complaining, just curious if there were reasons beyond the obvious real-world practicality that I wasn't aware of. --000e0ce0b4921b5035049fde9403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 1, 2011 at 1:00 PM, Scott Fe= rguson <ferg@caucho= .com> wrote:
=20 =20 =20
On 04/01/2011 06:38 AM, David Endicott wrote:
> Aside: why do we differentiate between binary and text frames?

So the browser/user-agent knows what to do with it? =A0AFAIK, that API at the
W3C/WhatWG is TBD.

Yes, but... =A0 =A0 If we're going to tell the user-agent = what the content type is, we should tell them the 'content-type= 9;, not a half-arsed binary/text. =A0 If we're going to leave the content type knowledge to an understanding between the server & user-agent at a higher level, then an untyped opaque payload would be appropriate. =A0Personally I like to view WebSockets as "framed TCP", so opaque payloads would be= my choice.=A0

As I remember, the text/binary is a pragmatic decision primarily based on balancing browser API needs with low-level specialized protocols.

Tossing around JSON, for example, is really text. And since no one wants to make the ASCII/ISO-8859-1 assumptions/mistakes again, it's good to enforce UTF-8 encoding at the framing layer so it's correct from the beginning.

For more specialized clients (like some I'm working on), having the direct binary is what's needed.

We did discuss a full mime-type extension, but that very quickly became complicated for a simple framing protocol.

So while text/binary is perhaps not the most minimal solution possible, it's still simple and solves the main use cases.


Yes, I would agree the benef= its / convenience for the client-agent outweigh any "purity of design&= quot; considerations. =A0 I was not complaining, just curious if there were= reasons beyond the obvious real-world practicality that I wasn't aware= of.

--000e0ce0b4921b5035049fde9403-- From sm@resistor.net Fri Apr 1 11:04:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEFB73A6909 for ; Fri, 1 Apr 2011 11:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW8PGHxlSNT9 for ; Fri, 1 Apr 2011 11:04:56 -0700 (PDT) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by core3.amsl.com (Postfix) with ESMTP id B90123A690C for ; Fri, 1 Apr 2011 11:04:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p31I6QFs017069; Fri, 1 Apr 2011 11:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1301681193; bh=kljxxs68Lt6HUJVSLMIEEi1hdnHxtDP89RpmQ4d64mA=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=UZemtlnz1eBw2e2mOk2AcZd0wR8WUOvDzdbyP7L8FR5ND1i/wLPQBjXpt0VFgw5iX Dc6/tnHkhzwNlh9rRTjmFdMU3Zd0SetqDPQ1i0Dl1pZB16GOZgPVRR+SzHONBR4Y6c GC0lEfSGELIoAB4sUBZbs8kYQmTiu+8WdM1xMSdQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1301681193; bh=kljxxs68Lt6HUJVSLMIEEi1hdnHxtDP89RpmQ4d64mA=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=j/uYBZQLJ49lqXAsUCy0o9iQIVIbp0ZdScrd1cxHciViwfaTuFapTBKbU178MBeqH 0GfIJSCQL/nNH67U9GSmul2tKuj/LyaZUpbk3U+IRj6pKPUcMRvQiAI0BCuJh8DEMX ezhvI8bWRx+OxGYy4ykUI2rfjFkadGsaSmDhJ7xI= Message-Id: <6.2.5.6.2.20110401104745.0e99cc70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Apr 2011 11:05:53 -0700 To: Greg Longtin From: SM In-Reply-To: <000701cbf022$9adb51d0$d091f570$@net> References: <000701cbf022$9adb51d0$d091f570$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: hybi@ietf.org Subject: Re: [hybi] Two Questions 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, 01 Apr 2011 18:04:59 -0000 Hi Greg, At 21:09 31-03-2011, Greg Longtin wrote: >Secondly, I am still unclear on whether WS *can* or *must* use ports 80 / >443. Section 1.7 uses the term 'by default'. I think that implies *can* or >*should* but not *must*... From RFC 2119: "In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized." The only part in the draft which may imply conformance is in some parts of Section 3 of draft-ietf-hybi-thewebsocketprotocol-06: "If there is no explicit /port/, then: if /secure/ is false, let /port/ be 80, otherwise let /port/ be 443." Regards, -sm From andy.warmcat.com@googlemail.com Fri Apr 1 11:16:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCB93A6911 for ; Fri, 1 Apr 2011 11:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaE8JrJyh754 for ; Fri, 1 Apr 2011 11:16:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2929A3A690D for ; Fri, 1 Apr 2011 11:16:08 -0700 (PDT) Received: by wyb29 with SMTP id 29so3585101wyb.31 for ; Fri, 01 Apr 2011 11:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DcElGF1t4fBG6FZ8dVE4hpq/BXdqHjDrtBw4IXf17/g=; b=av5eOeKBs2/nMX5xSk49L2fjSqJnQ2uS42h6fBlIbkysT9TPp4VLKiDGHSWOhhpHsA 39gOr4waXg3tQ1MVk401V/Kod9nVC1qSoICJYctrA+j21ZNkMQE++dhevfxhcRqZK88J 6Qci/diMMB5E/HQG/vUYTIRUISKtID2tFPwwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dLPBG5V2ReR6Dtwn//KonMmtEd3kxgyTCXta0QI16DDbtol8nqnzPpPNZlzIbMXchJ iaKWMD1UXg+uV9/Id+YQo4JnrJFLhbAb4WOMlbcnQyTdyjHCpMGmEzhgOlnFrs7nTXNU NcNdj4kI6wWF9/Yv98rQIhQdmWl/G2yNI1Ato= Received: by 10.227.141.29 with SMTP id k29mr4307216wbu.150.1301681867874; Fri, 01 Apr 2011 11:17:47 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id u9sm1419683wbg.17.2011.04.01.11.17.46 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 11:17:46 -0700 (PDT) Sender: Andy Green Message-ID: <4D9616C9.1010408@warmcat.com> Date: Fri, 01 Apr 2011 19:17:45 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110310 Fedora/3.1.9-2.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Longtin References: <000701cbf022$9adb51d0$d091f570$@net> <4D959704.1090303@warmcat.com> <000c01cbf05f$d4df6280$7e9e2780$@net> In-Reply-To: <000c01cbf05f$d4df6280$7e9e2780$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] Two Questions 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, 01 Apr 2011 18:16:09 -0000 On 04/01/2011 12:27 PM, Somebody in the thread at some point said: Hi - > How about I rephrase. Per the HTTP spec, can an HTTP server *not* respond > to a properly formatted but invalid upgrade request from a client? Or, > *should* an HTTP server respond? > > My interpretation of the WS spec is that a non response is correct for > invalid WS upgrade requests. Does that play well with the HTTP spec? A TCP connection can get dropped any time; the http spec important as it is in the world can't mandate otherwise. So it's "compatible with http" if a websocket server doesn't like what the client asked for and just closes the socket flat. For websocket client as mentioned earlier again the specs can only really talk about what websocket endpoints should do if compliant. The rest of the world like proxies, ssh servers or smtp or what have you will still "answer the phone" if the websocket client is asked to connect to them. The handshake seems enough to detect it's not a websocket server in that case and stop. -Andy From bruce@callenish.com Fri Apr 1 11:39:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF4B3A6916 for ; Fri, 1 Apr 2011 11:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Z8EgNv+-NMAS for ; Fri, 1 Apr 2011 11:39:51 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 6A3A03A6918 for ; Fri, 1 Apr 2011 11:39:51 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q5jHm-0005KB-1W; Fri, 01 Apr 2011 11:41:30 -0700 Message-ID: <4D961C5A.9020104@callenish.com> Date: Fri, 01 Apr 2011 11:41:30 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Endicott References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 18:39:52 -0000 [I hesitate to reply to a thread started so close to April 1st. However...] On 31/03/2011 7:54 PM, David Endicott wrote: > > 1. HTTP Upgrade request (and it's response) are properly part of a > HTTP exchange, not a WebSocket one. The use of HTTP Upgrade as a > mechanism to support WebSockets via a HTTP server is a good and valid > use of that HTTP capability, but it is not unique or specific to > WebSocket. If I understand you right, you are suggesting that WebSockets run as a separate protocol, but with an option to use the HTTP upgrade mechanism if desired. This has been suggested on the list about 9 months ago, when it got a little bit of support but not enough to push it forward. See http://www.ietf.org/mail-archive/web/hybi/current/msg02175.html and http://www.ietf.org/mail-archive/web/hybi/current/msg02203.html. I seem to recall that some of the browser guys pushed back saying that they really didn't want to support 4 different schemes for handshaking for such a minor benefit. It would also have some security implications for browsers, as follows. > Specifically I propose that the HTTP Upgrade based handshake be > removed from the WebSocket specification and replaced with a Control > frame handshake or negotiation. Some would argue that this would break the security of WebSockets. Right now, an XmlHTTPRequest can control all the bits after an HTTP handshake has completed, but it cannot influence any header that starts with "Sec-". This means that an attacker cannot provide a malicious WebSocket client written in Javascript that is automatically downloaded by the user just by visiting a web page. From dendicott@gmail.com Fri Apr 1 12:18:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB443A6934 for ; Fri, 1 Apr 2011 12:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-8vdAy4yDxI for ; Fri, 1 Apr 2011 12:18:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2C0413A6936 for ; Fri, 1 Apr 2011 12:18:19 -0700 (PDT) Received: by wyb29 with SMTP id 29so3629806wyb.31 for ; Fri, 01 Apr 2011 12:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i6h/OmLQiACjoS4A6Bb5CEJjoRaftCE/Otbwz8467dY=; b=kfuNmJu1E0jlC+Par8+ecREQCBA21sme1dMGUw9r/m4HV48iNLTD/yxWjCd6cIatit xij9pn46ZqpHP9gC483eSDrZjc79+HDGs3NBvvpeErXTIlIcZHhZ5VID3Mp5mx4LdMb5 MzURohVBgipxlFJGPQ/vWOVIp11S4tP+b11a0= 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=fHt0D3wV7OsVJy+xf6N7WQSrXeJzYxGk1wx3OuhuMe3J8V2CapX7hqiHEfkqTsJqRD 2ziN0L6A0DuMRri65xNFARMVJn3bTdTIyyEuWbnDC1o4tgwt/D3TrdKr0/VE+gxKwI2p X898LDUAv1RmYO+iCyk+hddoCJUNw5LKQ5rDw= MIME-Version: 1.0 Received: by 10.216.184.129 with SMTP id s1mr1209641wem.32.1301685599250; Fri, 01 Apr 2011 12:19:59 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Fri, 1 Apr 2011 12:19:59 -0700 (PDT) In-Reply-To: <4D961C5A.9020104@callenish.com> References: <4D961C5A.9020104@callenish.com> Date: Fri, 1 Apr 2011 15:19:59 -0400 Message-ID: From: David Endicott To: Bruce Atherton Content-Type: multipart/alternative; boundary=001485f1ec0ec0aa98049fe04bb3 Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 19:18:28 -0000 --001485f1ec0ec0aa98049fe04bb3 Content-Type: text/plain; charset=ISO-8859-1 > > [I hesitate to reply to a thread started so close to April 1st. However...] I hesitated to write it. 1. HTTP Upgrade request (and it's response) are properly part of a HTTP >> exchange, not a WebSocket one. The use of HTTP Upgrade as a mechanism to >> support WebSockets via a HTTP server is a good and valid use of that HTTP >> capability, but it is not unique or specific to WebSocket. >> > > If I understand you right, you are suggesting that WebSockets run as a > separate protocol, but with an option to use the HTTP upgrade mechanism if > desired. This has been suggested on the list about 9 months ago, when it got > a little bit of support but not enough to push it forward. See > http://www.ietf.org/mail-archive/web/hybi/current/msg02175.html and > http://www.ietf.org/mail-archive/web/hybi/current/msg02203.html. I seem to > recall that some of the browser guys pushed back saying that they really > didn't want to support 4 different schemes for handshaking for such a minor > benefit. > Yes, that is what I am suggesting. I have not read the archived discussion yet, but I will review it. The reason I decided to comment was I kept seeing other people stumble over the handshake process. I already knew from my implementations that it smelled wrong and when I was able to articulate clearly why I thought that, I tossed in my 0.02. As I said, I do not want to derail the standardization process, and maintaining the status-quo is (grudgingly) acceptable to me. I've dealt with quirks in other protocols, and this isn't really that big of a deal. To reiterate - imho, WS is a transport protocol. It should be considered entirely separate from HTTP. WS rides on TCP like HTTP rides on TCP - they are peers. HTTP Upgrade as a mechanism to establish WS is a Good Idea, but it seems inappropriately co-mingled with the WS specification. They are two different things and I believe should be clearly delineated as such. I don't view this as a minor benefit, I see it as true reflection of the protocol's roles. We need to stop thinking that we're slipping WS quietly in the back door like a nervous teenager breaking curfew. WS is a full fledged transport protocol on the same level as HTTP, SSH, SMTP and their ilk and should be treated as such. The significance of WS in the family of internet protocols is along side HTTP, not as it's black-sheep offspring. WS is intended to do what HTTP does but asynchronously. If that means more work for the browser implementers (and I would argue it doesn't) or that it affects how proxies and firewalls behave, then so be it - that is the real consequence of what we're trying to do and the sooner we face it the better. > Some would argue that this would break the security of WebSockets. Right > now, an XmlHTTPRequest can control all the bits after an HTTP handshake has > completed, but it cannot influence any header that starts with "Sec-". This > means that an attacker cannot provide a malicious WebSocket client written > in Javascript that is automatically downloaded by the user just by visiting > a web page. > Yes, I'm sure some would. I would argue that that most of those concerns are properly the responsibility of the client-agent implementers. In much that same way that javascript has the same-origin restriction (enforced by the client-agent), WS in the browser would have the same restriction. A malicious WS using script could only talk to the server it was downloaded from. I believe this exposes no more vulnerability than ajax does. If anyone has any specific examples to the contrary I would be open to hearing them. If a foul tempered client crafts a XmlHTTPRequest and attempts to access a WS server (assuming we're not using HTTP Upgrade) - it will fail. XmlHTTPRequest is a HTTP request, not a WS frame. Javascript clients cannot create an XmlHTTPRequest that is a proper WS frame so any attempt to perform a WS frame based negotiation/handshake is impossible. If the WS server is being provided via a HTTP Upgrade mechanism, then yes, some care may be needed - but that is part of "Using HTTP Upgrade to Establish WebSocket" And finally, if no other transport protocol takes extreme measures to prevent tomfoolery with the content (other than what is necessary to get it delivered, or reject it out of hand), I see no reason why WS should either. WS properly wraps content opaquely. IP doesn't care what's in the TCP it carries, TCP doesn't care what's in the HTTP it carries, and HTTP doesn't care (it escapes!) what's in the content it carries. Protecting the end user from malicious or incompetent implementations is the responsibility of the application layer (ie. the browser's javascript's WS object). Protecting the server from evil & stupid clients is the responsibility of the server implementation, not the transport protocol it uses. If I turn out to be wrong about my position, I pledge to consume the requisite number of crows. --001485f1ec0ec0aa98049fe04bb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[I hesitate to r= eply to a thread started so close to April 1st. However...]

I hesitated to write it.=A0


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
1. HTTP Upgrade request (and it's response) are properly part of a HTTP= exchange, not a WebSocket one. =A0The use of HTTP Upgrade as a mechanism t= o support WebSockets via a HTTP server is a good and valid use of that HTTP= capability, but it is not unique or specific to WebSocket.

If I understand you right, you are suggesting that WebSockets run as a sepa= rate protocol, but with an option to use the HTTP upgrade mechanism if desi= red. This has been suggested on the list about 9 months ago, when it got a = little bit of support but not enough to push it forward. See http://www.ietf.org/mail-archive/web/hybi/current/msg02175.html an= d http://www.ietf.org/mail-archive/web/hybi/current/msg0= 2203.html. I seem to recall that some of the browser guys pushed back s= aying that they really didn't want to support 4 different schemes for h= andshaking for such a minor benefit.

Yes, that is what I am suggesting. =A0 I h= ave not read the archived discussion yet, but I will review it. =A0 =A0

The reason I decided to comment was I kept seeing oth= er people stumble over the handshake process. =A0 I already knew from my im= plementations that it smelled wrong and when I was able to articulate clear= ly why I thought that, I tossed in my 0.02. =A0 =A0As I said, I do not want= to derail the standardization process, and maintaining the status-quo is (= grudgingly) acceptable to me. =A0 I've dealt with quirks in other proto= cols, and this isn't really that big of a deal.

To reiterate - imho, WS is a transport protocol. =A0 It= should be considered entirely separate from HTTP. =A0 WS rides on TCP like= HTTP rides on TCP - they are peers. =A0 HTTP Upgrade as a mechanism to est= ablish WS is a Good Idea, but it seems inappropriately co-mingled with the = WS specification. =A0 They are two different things and I believe should be= clearly delineated as such. =A0 I don't view this as a minor benefit, = I see it as true reflection of the protocol's roles.

We need to stop thinking that we're slipping WS qui= etly in the back door like a nervous teenager breaking curfew. =A0 WS is a = full fledged transport protocol on the same level as HTTP, SSH, SMTP and th= eir ilk and should be treated as such. =A0 =A0The significance of WS in the= family of internet protocols is along side HTTP, not as it's black-she= ep offspring. =A0 WS is intended to do what HTTP does but asynchronously. = =A0 =A0If that means more work for the browser implementers (and I would ar= gue it doesn't) or that it affects how proxies and firewalls behave, th= en so be it - that is the real consequence=A0of what we're trying to do= and the sooner we face it the better.


Some would argue that this would break the security of WebSockets. Right no= w, an XmlHTTPRequest can control all the bits after an HTTP handshake has c= ompleted, but it cannot influence any header that starts with "Sec-&qu= ot;. This means that an attacker cannot provide a malicious WebSocket clien= t written in Javascript that is automatically downloaded by the user just b= y visiting a web page.

Yes, I'm sure some would. =A0I would a= rgue that that most of those concerns are properly the responsibility of th= e client-agent implementers. =A0 In much that same way that javascript has = the same-origin restriction (enforced by the client-agent), WS in the brows= er would have the same restriction. =A0 A malicious WS using script could o= nly talk to the server it was downloaded from. =A0 I believe this exposes n= o more vulnerability than ajax does. =A0If anyone has any specific examples= to the contrary I would be open to hearing them.

If a foul tempered client crafts a XmlHTTPRequest and a= ttempts to access a WS server (assuming we're not using HTTP Upgrade) -= it will fail. =A0XmlHTTPRequest is a HTTP request, not a WS frame. =A0 Jav= ascript clients cannot create an XmlHTTPRequest that is a proper WS frame s= o any attempt to perform a WS frame based negotiation/handshake is impossib= le.

If the WS server is being provided via a HTTP Upgrade m= echanism, then yes, some care may be needed - but that is part of "Usi= ng HTTP Upgrade to Establish WebSocket"

And f= inally, if no other transport protocol takes extreme measures to prevent to= mfoolery with the content (other than what is necessary to get it delivered= , or reject it out of hand), I see no reason why WS should either. =A0 =A0W= S properly wraps content opaquely. =A0 =A0 IP doesn't care what's i= n the TCP it carries, TCP doesn't care what's in the HTTP it carrie= s, and HTTP doesn't care (it escapes!) what's in the content it car= ries.

Protecting the end user from malicious or incompetent i= mplementations is the responsibility of the application layer (ie. the brow= ser's javascript's WS object). =A0 Protecting the server from evil = & stupid clients is the responsibility of the server implementation, no= t the transport protocol it uses. =A0=A0


If I turn out to be wrong about my posi= tion, I pledge to consume the requisite number of crows.

--001485f1ec0ec0aa98049fe04bb3-- From bruce@callenish.com Fri Apr 1 13:18:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769103A6969 for ; Fri, 1 Apr 2011 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.018, 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 xrU9GIN2Y1sI for ; Fri, 1 Apr 2011 13:18:51 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id A3F013A6964 for ; Fri, 1 Apr 2011 13:18:51 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q5kpa-0008WT-1n; Fri, 01 Apr 2011 13:20:30 -0700 Message-ID: <4D96338F.5010603@callenish.com> Date: Fri, 01 Apr 2011 13:20:31 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Endicott References: <4D961C5A.9020104@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050302070309040203020004" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 20:18:52 -0000 This is a multi-part message in MIME format. --------------050302070309040203020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/04/2011 12:19 PM, David Endicott wrote: > > > Some would argue that this would break the security of WebSockets. > Right now, an XmlHTTPRequest can control all the bits after an > HTTP handshake has completed, but it cannot influence any header > that starts with "Sec-". This means that an attacker cannot > provide a malicious WebSocket client written in Javascript that is > automatically downloaded by the user just by visiting a web page. > > > Yes, I'm sure some would. I would argue that that most of those > concerns are properly the responsibility of the client-agent > implementers. In much that same way that javascript has the > same-origin restriction (enforced by the client-agent), WS in the > browser would have the same restriction. A malicious WS using script > could only talk to the server it was downloaded from. I believe this > exposes no more vulnerability than ajax does. If anyone has any > specific examples to the contrary I would be open to hearing them. The reason I referred to others who would argue the point is that I am not an expert on browser security, so I bow to the knowledge of those who are. They have said that the security is not the same with WebSockets. See http://www.ietf.org/mail-archive/web/hybi/current/msg06134.html for an example. I'll leave it to others to argue more fully the specifics. --------------050302070309040203020004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/04/2011 12:19 PM, David Endicott wrote:


Some would argue that this would break the security of WebSockets. Right now, an XmlHTTPRequest can control all the bits after an HTTP handshake has completed, but it cannot influence any header that starts with "Sec-". This means that an attacker cannot provide a malicious WebSocket client written in Javascript that is automatically downloaded by the user just by visiting a web page.

Yes, I'm sure some would.  I would argue that that most of those concerns are properly the responsibility of the client-agent implementers.   In much that same way that javascript has the same-origin restriction (enforced by the client-agent), WS in the browser would have the same restriction.   A malicious WS using script could only talk to the server it was downloaded from.   I believe this exposes no more vulnerability than ajax does.  If anyone has any specific examples to the contrary I would be open to hearing them.

The reason I referred to others who would argue the point is that I am not an expert on browser security, so I bow to the knowledge of those who are. They have said that the security is not the same with WebSockets. See http://www.ietf.org/mail-archive/web/hybi/current/msg06134.html for an example. I'll leave it to others to argue more fully the specifics.

--------------050302070309040203020004-- From dendicott@gmail.com Fri Apr 1 13:41:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D6B28C0E3 for ; Fri, 1 Apr 2011 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU62C2KGX1GF for ; Fri, 1 Apr 2011 13:41:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 57F1728C0D8 for ; Fri, 1 Apr 2011 13:41:14 -0700 (PDT) Received: by wyb29 with SMTP id 29so3686323wyb.31 for ; Fri, 01 Apr 2011 13:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/sylLQ88t0xWSXv+MJ/zkn+wDPSwGhn00MevuVgHelE=; b=giwxerr/3MJPhwVL1FLBalndJE9Mq3zfzR71OfdTqFOFmo+Xh9QYSAI3r7Jea4MBAU boXdLMpx8kiba7AqpSiGjQndJ+JUrEryF+sPfn04zdDH64YHkqMgu3YgjwjxxHBTbgaB LlSCzRSSosHaeZ8ffEqwikV8JuUI340vu6HmM= 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=bdwOGPuF49dUUrKmNggq3UNvrLM4QmTidiidt4ePRzBcaqj9giWMeAEuEuQfid6mE/ ST5PXwhR0WVrFKt1Rq+OYZXPVSbO2PmzYE95U7iiv4SFRbI+uDkhGS9oL8FAmgatJrZ5 MCHmAoLizuaVR/gO5qeIK8urKOoSRH8Un6Wg4= MIME-Version: 1.0 Received: by 10.216.69.131 with SMTP id n3mr868643wed.47.1301690574337; Fri, 01 Apr 2011 13:42:54 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Fri, 1 Apr 2011 13:42:54 -0700 (PDT) In-Reply-To: <4D96338F.5010603@callenish.com> References: <4D961C5A.9020104@callenish.com> <4D96338F.5010603@callenish.com> Date: Fri, 1 Apr 2011 16:42:54 -0400 Message-ID: From: David Endicott To: Bruce Atherton Content-Type: multipart/alternative; boundary=000e0cd66e6e4a75eb049fe1747f Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 01 Apr 2011 20:41:15 -0000 --000e0cd66e6e4a75eb049fe1747f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 1, 2011 at 4:20 PM, Bruce Atherton wrote: > On 01/04/2011 12:19 PM, David Endicott wrote: > > ... I believe this exposes no more vulnerability than ajax does. If > anyone has any specific examples to the contrary I would be open to hearing > them. > > > The reason I referred to others who would argue the point is that I am not > an expert on browser security, so I bow to the knowledge of those who are. > They have said that the security is not the same with WebSockets. See > http://www.ietf.org/mail-archive/web/hybi/current/msg06134.html for an > example. I'll leave it to others to argue more fully the specifics. > > Nor am I (hence the corvid consumption caveat) It is very possible I have overlooked or am unaware of something. That notwithstanding, I do feel fairly confident that doing WebSocket without a HTTP Upgrade handshake is no less secure than with it - and may actually be safer. Much of the jumping around and Sec-Websocket headers seem to be simply to deal with the behavior of HTTP & XmlHTTPRequest. Eliminate it from the WebSocket core specification and it seems to me that several problems / design warts just go away. I look forward to input from those more knowledgeable on this topic. --000e0cd66e6e4a75eb049fe1747f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 1, 2011 at 4:20 PM, Bruce At= herton <bruce@c= allenish.com> wrote:
=20 =20 =20
On 01/04/2011 12:19 PM, David Endicott wrote:
... =A0 I believe this exposes no more vulnerability than ajax does. =A0If anyone has any specific examples to the contrary I would be open to hearing them.

The reason I referred to others who would argue the point is that I am not an expert on browser security, so I bow to the knowledge of those who are. They have said that the security is not the same with WebSockets. See http://www.ietf.org/mail-archive/web/hybi/current/ms= g06134.html for an example. I'll leave it to others to argue more fully the specifics.


Nor am I (hence the corvid consumption ca= veat) =A0 It is very possible I have overlooked or am unaware of something.= =A0 =A0That notwithstanding, I do feel fairly confident that doing WebSock= et without a HTTP Upgrade handshake is no less secure than with it - and ma= y actually be safer. =A0 Much of the jumping around and Sec-Websocket heade= rs seem to be =A0simply to deal with the behavior of HTTP & XmlHTTPRequ= est. =A0Eliminate it from the WebSocket core specification and it seems to = me that several problems / design warts just go away.

I look forward to input from those more=A0knowledgeable=A0on this = topic.

--000e0cd66e6e4a75eb049fe1747f-- From ibc@aliax.net Sun Apr 3 08:11:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC153A69BF for ; Sun, 3 Apr 2011 08:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV5ckr3AS9gU for ; Sun, 3 Apr 2011 08:11:59 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id F40B33A682D for ; Sun, 3 Apr 2011 08:11:58 -0700 (PDT) Received: by qwc9 with SMTP id 9so4816069qwc.27 for ; Sun, 03 Apr 2011 08:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.64.194 with SMTP id f2mr5134938qai.147.1301843620173; Sun, 03 Apr 2011 08:13:40 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 3 Apr 2011 08:13:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Apr 2011 17:13:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: David Endicott Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 15:11:59 -0000 2011/4/1 David Endicott : > Specifically I propose that the HTTP Upgrade based handshake be removed f= rom > the WebSocket specification and replaced with a Control frame handshake o= r > negotiation. =C2=A0 =C2=A0This would mean that all WebSocket communicatio= n is done in > websocket frames. This makes lot of sense. In this way WebSocket would be a real protocol rather than a mix between pseudo-HTTP and other protocol. By looking like HTTP (during handshake process) WS gets into varios issues this working group has been dealing with for long time. It also doesn't take real advantages from HTTP world as response codes different than 101 are not defined by the draft (it's like an amateur PHP developer that just assumes things always work and never reacts on possible errors). Making WS a complete separate protocol would also involve not reusing HTTP default ports (80 and 443). Why to reuse them? just because the handshake mechanism (a hacked HTTP request/response) seems like HTTP? Unfortunatelly I think it's too late for a new approach of the WebSocket protocol, even if it would be really a much better design (IMHO). --=20 I=C3=B1aki Baz Castillo From jat@google.com Sun Apr 3 08:29:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054623A682D for ; Sun, 3 Apr 2011 08:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.784 X-Spam-Level: X-Spam-Status: No, score=-105.784 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llxnKfhxdToz for ; Sun, 3 Apr 2011 08:29:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CE13C3A6823 for ; Sun, 3 Apr 2011 08:29:11 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p33FUqSN022416 for ; Sun, 3 Apr 2011 08:30:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301844653; bh=QprtwrBUSJ2iwX3gT+6YjQ7fMoU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=JbkjW4jVVn1zL3NWgANPFRu4Rz2OSa5fOdm3zv0WzLdt34rhGl+jse1mqSW3NCC0C t73XHMuyLmL/U1MR9oYVA== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq12.eem.corp.google.com with ESMTP id p33FUokY023162 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 3 Apr 2011 08:30:51 -0700 Received: by gwb11 with SMTP id 11so1946631gwb.6 for ; Sun, 03 Apr 2011 08:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wgqN2ytkwOgDwAIsYgMDUUskq+EmhHSO0vT5y55o58o=; b=hbMtC4WGgk7lKnG1f67F87qf7uV5+QlWCvIqoUY9t4BSTtG9blt4HfbHGChUauJyS8 Ru6o5YCEt7v8Is8RQ8WQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ZEKPCExlkFgdiM7jpWCDI31U7vOglHc233K9dVqE8xfH9KW2GQpGffN9wWUYlTge3W 27LMRDVa1OU5HrjvjR/Q== Received: by 10.236.189.38 with SMTP id b26mr8682377yhn.147.1301844650105; Sun, 03 Apr 2011 08:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Sun, 3 Apr 2011 08:30:29 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Sun, 3 Apr 2011 11:30:29 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303f69bcec1da104a0055324 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 15:29:13 -0000 --20cf303f69bcec1da104a0055324 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 3, 2011 at 11:13 AM, I=C3=B1aki Baz Castillo wr= ote: > Making WS a complete separate protocol would also involve not reusing > HTTP default ports (80 and 443). Why to reuse them? just because the > handshake mechanism (a hacked HTTP request/response) seems like HTTP? > Please read the many discussions about this topic. Basically, if it uses dedicated ports and doesn't make use of existing HTTP infrastructure, it was felt that it would not be sufficiently deployable to displace existing mechanisms. It is expected that the current approach over SSL will work in the majority of cases (there are issues, particularly with proxies that don't support CONNECT outside of SSL for non-SSL WebSockets), so that is a big advantage. --=20 John A. Tamplin Software Engineer (GWT), Google --20cf303f69bcec1da104a0055324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 3, 2011 at 11:13 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
Making WS a complete separate protocol would also involve not reusing
HTTP default ports (80 and 443). Why to reuse them? just because the
handshake mechanism (a hacked HTTP request/response) seems like HTTP?

Please read the many discussions about this= topic.

Basically, if it uses dedicated ports and doesn&= #39;t make use of existing HTTP infrastructure, it was felt that it would n= ot be sufficiently deployable to displace existing mechanisms.

It is expected that the current approach over SSL will = work in the majority of cases (there are issues, particularly with proxies = that don't support CONNECT outside of SSL for non-SSL WebSockets), so t= hat is a big advantage.

--
John A. Tamplin
Software Engineer (GWT), Google
--20cf303f69bcec1da104a0055324-- From andy.warmcat.com@googlemail.com Sun Apr 3 08:30:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF643A682D for ; Sun, 3 Apr 2011 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pz1qZZ6wqIG for ; Sun, 3 Apr 2011 08:30:42 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 726CA3A6823 for ; Sun, 3 Apr 2011 08:30:42 -0700 (PDT) Received: by wwa36 with SMTP id 36so3941213wwa.13 for ; Sun, 03 Apr 2011 08:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9vLWE+e7EzYdKoYCRvYOVx6W/5k64X2+UeAoDXP0IhU=; b=xv1on9BiKNV8dB4yz9zD6AtPqOfylpnmOQ/TOd6KQEkJB4KN0+0ugMVPXjV5Atwnn6 ZsIpM5Oa4zSjA+ppw8yi0rXt2wwBwnlDwtmvXI13HFlNa0Z/JHyfH091gLnrWu8bhrbR sBW5bFZW2mxnuhqZgP5cpxN6GPnzRdxAuXNz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LOPw/l+B0HymuOG5wzPwj08Y5HoOfaJXL+qY+CrLytunwkKBzJyBijm64rKKzCYNhN 6KAvBAZAyyfp66cAJtzgFJ150hRf6ixKSAGxha1yCQVi9VyykozrrbiRABXSP7gHV6fI FlDi1lEnQkpjcb/xHvAeymtGPrDVrKKPuuFAI= Received: by 10.227.197.83 with SMTP id ej19mr102355wbb.105.1301844743377; Sun, 03 Apr 2011 08:32:23 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id l24sm2395620wbc.64.2011.04.03.08.32.21 (version=SSLv3 cipher=OTHER); Sun, 03 Apr 2011 08:32:22 -0700 (PDT) Sender: Andy Green Message-ID: <4D989304.9080802@warmcat.com> Date: Sun, 03 Apr 2011 16:32:20 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 15:30:43 -0000 On 04/03/2011 04:13 PM, Somebody in the thread at some point said: > Making WS a complete separate protocol would also involve not reusing > HTTP default ports (80 and 443). Why to reuse them? just because the > handshake mechanism (a hacked HTTP request/response) seems like HTTP? The reason for reusing them is they can be the only way out in restrictively firewalled sites. But it's not like it's defined to rely on being on 80 or 443, you can do what you like. > Unfortunatelly I think it's too late for a new approach of the > WebSocket protocol, even if it would be really a much better design > (IMHO). It's not any new approach, you're just suggesting splitting off the handshake and the websocket transport definition into separate documents. The end result is the same, who cares. -Andy From ibc@aliax.net Sun Apr 3 08:42:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BFF3A6835 for ; Sun, 3 Apr 2011 08:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhidMAPcALXN for ; Sun, 3 Apr 2011 08:42:35 -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 20A9F3A6823 for ; Sun, 3 Apr 2011 08:42:34 -0700 (PDT) Received: by qyk7 with SMTP id 7so3179705qyk.10 for ; Sun, 03 Apr 2011 08:44:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr4810153qch.201.1301845456236; Sun, 03 Apr 2011 08:44:16 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 3 Apr 2011 08:44:16 -0700 (PDT) In-Reply-To: <4D989304.9080802@warmcat.com> References: <4D989304.9080802@warmcat.com> Date: Sun, 3 Apr 2011 17:44:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 15:42:35 -0000 2011/4/3 Andy Green : >> Unfortunatelly I think it's too late for a new approach of the >> WebSocket protocol, even if it would be really a much better design >> (IMHO). > > It's not any new approach, you're just suggesting splitting off the > handshake and the websocket transport definition into separate documents. > =C2=A0The end result is the same, who cares. Instead of a HTTP handshake, I just suggest (as the first mail in this thread) the usage of a Websocket control frame to establish the WS "connection". --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sun Apr 3 08:53:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1567F3A697E for ; Sun, 3 Apr 2011 08:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmhZ-b0pPnB8 for ; Sun, 3 Apr 2011 08:53:06 -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 5368D3A6837 for ; Sun, 3 Apr 2011 08:53:06 -0700 (PDT) Received: by qyk7 with SMTP id 7so3182559qyk.10 for ; Sun, 03 Apr 2011 08:54:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.63.154 with SMTP id b26mr4988522qci.163.1301846087722; Sun, 03 Apr 2011 08:54:47 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 3 Apr 2011 08:54:47 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Apr 2011 17:54:47 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 15:53:07 -0000 2011/4/3 John Tamplin : > On Sun, Apr 3, 2011 at 11:13 AM, I=C3=B1aki Baz Castillo = wrote: >> >> Making WS a complete separate protocol would also involve not reusing >> HTTP default ports (80 and 443). Why to reuse them? just because the >> handshake mechanism (a hacked HTTP request/response) seems like HTTP? > > Please read the many discussions about this topic. I've read them and understand motivations, but I cannot agree (just my opin= ion). > Basically, if it uses dedicated ports and doesn't make use of existing HT= TP > infrastructure, it was felt that it would not be sufficiently deployable = to > displace existing mechanisms. > It is expected that the current approach over SSL will work in the majori= ty > of cases (there are issues, particularly with proxies that don't support > CONNECT outside of SSL for non-SSL WebSockets), so that is a big advantag= e. It "seems" that any new Internet protocol must be built on top of HTTP or, at least, reuse ports 80 or 443. If not, it seems that "it could not work". Some day Internet providers (specially mobile data connection providers) will close all the ports but HTTP ones and nobody will complain because Facebook still works. IMHO it sad to assume that end users are just able to contact port 80, and a new protocol should not be built on top of such assumption. Again, this is just my opinion, an opinion from somebody who doesn't come from HTTP world. Cheers. --=20 I=C3=B1aki Baz Castillo From andy.warmcat.com@googlemail.com Sun Apr 3 09:25:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3BB3A6837 for ; Sun, 3 Apr 2011 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGK0-e1g9HUH for ; Sun, 3 Apr 2011 09:25:08 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 0F2023A67CC for ; Sun, 3 Apr 2011 09:25:06 -0700 (PDT) Received: by wwk4 with SMTP id 4so934320wwk.1 for ; Sun, 03 Apr 2011 09:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cn2MstPO9D4RO9YkKYRc11EP3N6kq9T+qRSOq0yirN8=; b=Szqme8kG4LY3VMjXySBBI3zQt/THSaIfvAX4ufrNYZV6D7aYYuCoTdRMHfx7sJXC2V QiI7HJ7qozKOoR59GbASKBoekYA9npfh+Ep4DeF5qEm3JuS4S0jbCEXQwI+WnBwUAH5v kgT8EaMEdK2QQ1cS4fbqu7UWrb6WeK11oQKlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OGM+MKs8moJrA1HFPTlliiJnybZlVCJNY83wZ/MAj4wuGmVmMiMtMRt1QDYy8z2Xki vErNrWfg+678Z/Y7H5AKg6z3EFshCqA1+lrfEG0gyiw3Ks7wDo1HFmJw86SS7xUESKU2 X3Pb1KnaxqbFy/q7jdx05ypY/5Ij+MeRao1jg= Received: by 10.227.197.77 with SMTP id ej13mr6253624wbb.128.1301848008003; Sun, 03 Apr 2011 09:26:48 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o23sm2425159wbc.10.2011.04.03.09.26.46 (version=SSLv3 cipher=OTHER); Sun, 03 Apr 2011 09:26:47 -0700 (PDT) Sender: Andy Green Message-ID: <4D989FC5.4090407@warmcat.com> Date: Sun, 03 Apr 2011 17:26:45 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4D989304.9080802@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 16:25:10 -0000 On 04/03/2011 04:44 PM, Somebody in the thread at some point said: > 2011/4/3 Andy Green: >>> Unfortunatelly I think it's too late for a new approach of the >>> WebSocket protocol, even if it would be really a much better design >>> (IMHO). >> >> It's not any new approach, you're just suggesting splitting off the >> handshake and the websocket transport definition into separate documents. >> The end result is the same, who cares. > > Instead of a HTTP handshake, I just suggest (as the first mail in this > thread) the usage of a Websocket control frame to establish the WS > "connection". I assume this means running websocket on a different port altogether then. Given your user can get your html + scripts on port 80 or 443 via http, it sounds like a really good bet that he can do more connections on port 80 for the websocket ones too, leveraging specifically http semantics as the spec has it now. It's a much poorer bet that because he was able to get your html scripts from 80 or 443, that he can do websocket on 1234. I played with websockets being behind a really restrictive firewall and understood the value of re-using those magic ports first-hand. -Andy From ibc@aliax.net Sun Apr 3 09:36:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168C93A6837 for ; Sun, 3 Apr 2011 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIIosU3E5XB6 for ; Sun, 3 Apr 2011 09:36:20 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by core3.amsl.com (Postfix) with ESMTP id 497743A67CC for ; Sun, 3 Apr 2011 09:36:20 -0700 (PDT) Received: by qwc9 with SMTP id 9so4851061qwc.27 for ; Sun, 03 Apr 2011 09:38:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.75.196 with SMTP id z4mr4941659qcj.277.1301848681758; Sun, 03 Apr 2011 09:38:01 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 3 Apr 2011 09:38:01 -0700 (PDT) In-Reply-To: <4D989FC5.4090407@warmcat.com> References: <4D989304.9080802@warmcat.com> <4D989FC5.4090407@warmcat.com> Date: Sun, 3 Apr 2011 18:38:01 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 16:36:21 -0000 2011/4/3 Andy Green : > It's a much poorer bet that because he was able to get your html scripts > from 80 or 443, that he can do websocket on 1234. > > I played with websockets being behind a really restrictive firewall and > understood the value of re-using those magic ports first-hand. If WebSocket would use a separate port (i.e: 1234) and the protocol is widely implemented, then those really restrictive firewalls would also open port 1234, but using 80/443 from the beginning is like surronding to bad admins. If not, let use port 80 for everything (SMTP, SIP, IRC...). Oh wait, the purpose of a port is to identify a service, is WS breaking this sacred rule? IMHO yes. --=20 I=C3=B1aki Baz Castillo From jat@google.com Sun Apr 3 09:41:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978393A6837 for ; Sun, 3 Apr 2011 09:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.781 X-Spam-Level: X-Spam-Status: No, score=-105.781 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chy6kPYpeZGd for ; Sun, 3 Apr 2011 09:41:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A83493A6846 for ; Sun, 3 Apr 2011 09:41:44 -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 p33GhPhk005695 for ; Sun, 3 Apr 2011 09:43:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301849006; bh=S8voXnBRR8ZxGPjTXYff2b6C3iU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IN7R/OpMOMp55xXwwReUHO9tSefLTXEOjcBzIrFgMmVDLkdPk+1FU+u7IimOUni7c T3vCKvPLNqsZW4Av3btWA== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by kpbe17.cbf.corp.google.com with ESMTP id p33GhOBE025790 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 3 Apr 2011 09:43:24 -0700 Received: by gyg4 with SMTP id 4so2376434gyg.18 for ; Sun, 03 Apr 2011 09:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=m08HAm6Tk/1jtKyYwYwbw9+P6ci/Sk77POw4uIoM+XY=; b=DblS+H2zM5Apyv+RSgfleRIA2bn4CgRU8xKMogY8Bc/+20gFNZ+WyZZb4WX/yWnnGn up34l6D3g6Z1A4kbGqJw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mK0d8gxZAzQO/ufcjzClXrLO7rQbBPJu3Gpaa3/WU2teO3m+S1N4l5+PJS9na/Qrod rGzDNM0/XSq1GMaRApVw== Received: by 10.150.69.30 with SMTP id r30mr1625098yba.124.1301849004138; Sun, 03 Apr 2011 09:43:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Sun, 3 Apr 2011 09:43:04 -0700 (PDT) In-Reply-To: References: <4D989304.9080802@warmcat.com> <4D989FC5.4090407@warmcat.com> From: John Tamplin Date: Sun, 3 Apr 2011 12:43:04 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd59196715ff804a00657ad X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 16:41:45 -0000 --000e0cd59196715ff804a00657ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 3, 2011 at 12:38 PM, I=C3=B1aki Baz Castillo wr= ote: > If not, let use port 80 for everything (SMTP, SIP, IRC...). Oh wait, > the purpose of a port is to identify a service, is WS breaking this > sacred rule? IMHO yes. Those services aren't accessed by code downloaded over HTTP. While certainly there are non-HTTP uses for WebSockets, they aren't the primary one as they could just use TCP directly. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd59196715ff804a00657ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 3, 2011 at 12:38 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
If not, let use port 80 for everything (SMTP, SIP, IRC...= ). Oh wait,
the purpose of a port is to identify a service, is WS breaking this
sacred rule? IMHO yes.

Those services aren= 't accessed by code downloaded over HTTP. =C2=A0While certainly there a= re non-HTTP uses for WebSockets, they aren't the primary one as they co= uld just use TCP directly.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd59196715ff804a00657ad-- From ibc@aliax.net Sun Apr 3 09:56:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DF63A6850 for ; Sun, 3 Apr 2011 09:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFjlwIUUKCs8 for ; Sun, 3 Apr 2011 09:56:25 -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 B2E103A684F for ; Sun, 3 Apr 2011 09:56:25 -0700 (PDT) Received: by qyk7 with SMTP id 7so3199911qyk.10 for ; Sun, 03 Apr 2011 09:58:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr4845163qch.201.1301849886634; Sun, 03 Apr 2011 09:58:06 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 3 Apr 2011 09:58:06 -0700 (PDT) In-Reply-To: References: <4D989304.9080802@warmcat.com> <4D989FC5.4090407@warmcat.com> Date: Sun, 3 Apr 2011 18:58:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 16:56:27 -0000 2011/4/3 John Tamplin : > On Sun, Apr 3, 2011 at 12:38 PM, I=C3=B1aki Baz Castillo = wrote: >> >> If not, let use port 80 for everything (SMTP, SIP, IRC...). Oh wait, >> the purpose of a port is to identify a service, is WS breaking this >> sacred rule? IMHO yes. > > Those services aren't accessed by code downloaded over HTTP. =C2=A0While > certainly there are non-HTTP uses for WebSockets, they aren't the primary > one as they could just use TCP directly. With the inclusion of Websocket I expect that many services could offer an API so clients could use them directly via Websocket protocol, which could be useful not just for web browsers, but also for desktop application (those which today must poll data from a HTTP server each N seconds/minutes). I would like to imagine a realtime RSS service (with no periodical polling) for my RSS desktop client. So, you are assuming that: 1) Just web browsers will use WebSocket protocol. 2) Web browsers just should speak with a port 80/443. About point 2, how do you expect web browsers will be able -in a future- to open a realtime communication (voice/video) with a server (not just streaming media from server to client)? Will web browsers also send client's audio/video to a port 80/443? --=20 I=C3=B1aki Baz Castillo From jat@google.com Sun Apr 3 10:09:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8963A6990 for ; Sun, 3 Apr 2011 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.696 X-Spam-Level: X-Spam-Status: No, score=-105.696 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj00GlWsvdFL for ; Sun, 3 Apr 2011 10:09:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2E6C03A684F for ; Sun, 3 Apr 2011 10:09:02 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p33HAhsV029361 for ; Sun, 3 Apr 2011 10:10:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301850644; bh=ddVMO0maWCqBYlarZGQAtaAPyWQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BF6Gyy3yI438qeSvA3uLMEFg0oqxthp/PqazgJcxa+NIG0L2TsyvuPIXEH/3IzQYW k+Nr0hP/6yUfL6R2TLl4Q== Received: from ywi6 (ywi6.prod.google.com [10.192.9.6]) by wpaz5.hot.corp.google.com with ESMTP id p33HAgTQ016151 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 3 Apr 2011 10:10:42 -0700 Received: by ywi6 with SMTP id 6so2618696ywi.17 for ; Sun, 03 Apr 2011 10:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TWn1A3tJBbXn4Udaaj1VkNIGViRB7CsJla4lDbZA0pY=; b=YAmHmdCxmjfEkc077Hkd7nLwHd7mHSB72q6/xg0S33mUHc58pSKkD3Etl5YBP4qhqT WJ0mIyCuex2qO3za/mXg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=K0Yrm+K3b8wnt02nhxDs74UOHv3Sy6zqB6ZRHcr7v5SnAbU35fr0dtXsI7Fmv8lO06 ZHMsJoCDTeorg/uWOuRg== Received: by 10.150.177.15 with SMTP id z15mr5884314ybe.295.1301850642129; Sun, 03 Apr 2011 10:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Sun, 3 Apr 2011 10:10:22 -0700 (PDT) In-Reply-To: References: <4D989304.9080802@warmcat.com> <4D989FC5.4090407@warmcat.com> From: John Tamplin Date: Sun, 3 Apr 2011 13:10:22 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd6a9801323a504a006b93b X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 17:09:04 -0000 --000e0cd6a9801323a504a006b93b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 3, 2011 at 12:58 PM, I=C3=B1aki Baz Castillo wr= ote: > With the inclusion of Websocket I expect that many services could > offer an API so clients could use them directly via Websocket > protocol, which could be useful not just for web browsers, but also > for desktop application (those which today must poll data from a HTTP > server each N seconds/minutes). I would like to imagine a realtime RSS > service (with no periodical polling) for my RSS desktop client. > > So, you are assuming that: > > 1) Just web browsers will use WebSocket protocol. > No, just that they are the primary use-case we care about. Many of the restrictions come about because we are giving the ability for third-party code to make network connections from a user's browser. If we didn't have to support this use case, many things could be much simpler. > 2) Web browsers just should speak with a port 80/443. > > About point 2, how do you expect web browsers will be able -in a > future- to open a realtime communication (voice/video) with a server > (not just streaming media from server to client)? Will web browsers > also send client's audio/video to a port 80/443? Since most audio/video streaming to a browser currently takes place over HTTP despite alternatives, yes that seems likely. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd6a9801323a504a006b93b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 3, 2011 at 12:58 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
With the inclusion of Websocket I expect that many servic= es could
offer an API so clients could use them directly via Websocket
protocol, which could be useful not just for web browsers, but also
for desktop application (those which today must poll data from a HTTP
server each N seconds/minutes). I would like to imagine a realtime RSS
service (with no periodical polling) for my RSS desktop client.

So, you are assuming that:

1) Just web browsers will use WebSocket protocol.

=
No, just that they are the primary use-case we care about. =C2= =A0Many of the restrictions come about because we are giving the ability fo= r third-party code to make network connections from a user's browser. = =C2=A0If we didn't have to support this use case, many things could be = much simpler.
=C2=A0
2) Web browsers just should speak with a port 80/443.

About point 2, how do you expect web browsers will be able -in a
future- to open a realtime communication (voice/video) with a server
(not just streaming media from server to client)? Will web browsers
also send client's audio/video to a port 80/443?

<= /div>
Since most audio/video streaming to a browser currently takes pla= ce over HTTP despite alternatives, yes that seems likely.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd6a9801323a504a006b93b-- From ibc@aliax.net Sun Apr 3 10:22:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D9E3A6859 for ; Sun, 3 Apr 2011 10:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL+DecyuVErL for ; Sun, 3 Apr 2011 10:22:58 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 3A5FE3A6853 for ; Sun, 3 Apr 2011 10:22:58 -0700 (PDT) Received: by qyk29 with SMTP id 29so563039qyk.10 for ; Sun, 03 Apr 2011 10:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr4858813qch.201.1301851478880; Sun, 03 Apr 2011 10:24:38 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Sun, 3 Apr 2011 10:24:38 -0700 (PDT) In-Reply-To: References: <4D989304.9080802@warmcat.com> <4D989FC5.4090407@warmcat.com> Date: Sun, 3 Apr 2011 19:24:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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: Sun, 03 Apr 2011 17:22:59 -0000 2011/4/3 John Tamplin : >> 2) Web browsers just should speak with a port 80/443. >> >> About point 2, how do you expect web browsers will be able -in a >> future- to open a realtime communication (voice/video) with a server >> (not just streaming media from server to client)? Will web browsers >> also send client's audio/video to a port 80/443? > > Since most audio/video streaming to a browser currently takes place over > HTTP despite alternatives, yes that seems likely. So, in case I open a audio/video session with other person in my same city via web, then the media should be sent over TCP to the WebServer (which would be in other country) and come back to the other user. Are you assuming it? that would lead to several seconds of latency! Or maybe you are asuming that interactive media communication in a web page just means downloading or uploading videos to Youtube? Have you heard about RTP protocol integration into web browsers? there are already efforts in standarizing it: http://rtc-web.alvestrand.com/ietf-activity ---------------------------------------------------------------------------= ---------------- Name: Real-Time Communication in WEB-browsers (RTCWeb) There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients. ---------------------------------------------------------------------------= ---------------- There is life out of HTTP world, and several protocol much better than the old and limited HTTP. Please open your minds. --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Sun Apr 3 22:49:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892E73A6918 for ; Sun, 3 Apr 2011 22:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] 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 DMJX1Mcqg8PU for ; Sun, 3 Apr 2011 22:49:36 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id DAFC23A67EF for ; Sun, 3 Apr 2011 22:49:35 -0700 (PDT) Received: by vxg33 with SMTP id 33so4663658vxg.31 for ; Sun, 03 Apr 2011 22:51:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.175 with SMTP id dl15mr9012629vdb.69.1301896277770; Sun, 03 Apr 2011 22:51:17 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Sun, 3 Apr 2011 22:51:17 -0700 (PDT) In-Reply-To: References: <4D989304.9080802@warmcat.com> Date: Mon, 4 Apr 2011 15:51:17 +1000 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 04 Apr 2011 05:49:36 -0000 On 4 April 2011 01:44, I=F1aki Baz Castillo wrote: > 2011/4/3 Andy Green : >>> Unfortunatelly I think it's too late for a new approach of the >>> WebSocket protocol, even if it would be really a much better design >>> (IMHO). >> >> It's not any new approach, you're just suggesting splitting off the >> handshake and the websocket transport definition into separate documents= . >> =A0The end result is the same, who cares. > > Instead of a HTTP handshake, I just suggest (as the first mail in this > thread) the usage of a Websocket control frame to establish the WS > "connection". I think we need to consider this proposal in two parts: 1) Designing the handshake/protocol so that it could work well over a dedicated port 2) Actually deciding we want a dedicated port. Note that this was one of the reasons that I'm an advocate of Hello frames. If we move much of the protocol parameterisation (eg sub protocol and extension negotiation) into hello frames rather than HTTP headers, then this is more portable and would work WHEN AND IF we ever decided to have a dedicated port for ws. Hello frames can be done server->client->server to avoid a RTT's but maybe it is better to have them client->server->client so that the upgrade over HTTP would take one more RTT than a dedicated port and thus give an incentive to push for opening a port. So if there was interest at this late stage of moving some headers to hello frames - I'd be supportive of that. But I think we are too far down the upgrade path to change now and should keep HTTP upgrade for at least the short term. cheers From zt.tmzt@gmail.com Sun Apr 3 22:59:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7BE3A691A for ; Sun, 3 Apr 2011 22:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] 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 SMq2tCFT7vwv for ; Sun, 3 Apr 2011 22:59:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 03CFB3A6906 for ; Sun, 3 Apr 2011 22:59:40 -0700 (PDT) Received: by vxg33 with SMTP id 33so4667268vxg.31 for ; Sun, 03 Apr 2011 23:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bIDLlUzEgtfD9t+KgxCiRmQov4WCWs230CBcymJ3SRk=; b=tLUn9kJuEciFKl3XkHmUGvAfKHPFRnyWputLLLoqBiIOt4NwH/ITb9itKhn1Lf9ubS lyoIS0+67EcIoMc3k1KnQ9hbZe+7aByfbXNGGGX58wLlqvpsNKq3O9cH9dvUV/S2eE3f r7NDwyjcMp0W2f2kpVagOnIBx0gF7b3aUSRik= 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=ae5fZX9fl+LN/8/Nhzti67gs6fsUdIP8EVigNLgcrKg4Ln3rrN4Q6hWWLFNohtT3Cq tXYx9N4m9TwgbL+abBUdyvOVBYp2JNbBamzF5wSvhJeC+vu3hljtRBQs3/K8LYxGrlO7 /vsBLq9WFzCwd0Ho7dnLwq/Ma1cvK2gXD18Xg= MIME-Version: 1.0 Received: by 10.220.201.136 with SMTP id fa8mr1855563vcb.26.1301896882992; Sun, 03 Apr 2011 23:01:22 -0700 (PDT) Received: by 10.220.48.79 with HTTP; Sun, 3 Apr 2011 23:01:22 -0700 (PDT) Received: by 10.220.48.79 with HTTP; Sun, 3 Apr 2011 23:01:22 -0700 (PDT) In-Reply-To: References: <4D989304.9080802@warmcat.com> Date: Mon, 4 Apr 2011 02:01:22 -0400 Message-ID: From: "zt.tmzt@gmail.com" To: Greg Wilkins Content-Type: multipart/alternative; boundary=90e6ba53b1ee3eb59f04a0117dd3 Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 04 Apr 2011 05:59:48 -0000 --90e6ba53b1ee3eb59f04a0117dd3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there some reason you can't specify the field invovled in the handshake independent of the medium carrying them? Then use this to initialize the defaults of the dedicated WS framework handshake? For instance, what's to prevent an XMPP or other transport from being used if the protocol is designed with the proper degree of abstraction. Timothy Meade Real-time web developer On Apr 4, 2011 1:51 AM, "Greg Wilkins" wrote: > On 4 April 2011 01:44, I=F1aki Baz Castillo wrote: >> 2011/4/3 Andy Green : >>>> Unfortunatelly I think it's too late for a new approach of the >>>> WebSocket protocol, even if it would be really a much better design >>>> (IMHO). >>> >>> It's not any new approach, you're just suggesting splitting off the >>> handshake and the websocket transport definition into separate documents. >>> The end result is the same, who cares. >> >> Instead of a HTTP handshake, I just suggest (as the first mail in this >> thread) the usage of a Websocket control frame to establish the WS >> "connection". > > > I think we need to consider this proposal in two parts: > > 1) Designing the handshake/protocol so that it could work well over a > dedicated port > 2) Actually deciding we want a dedicated port. > > > Note that this was one of the reasons that I'm an advocate of Hello > frames. If we move much of the protocol parameterisation (eg sub > protocol and extension negotiation) into hello frames rather than HTTP > headers, then this is more portable and would work WHEN AND IF we > ever decided to have a dedicated port for ws. > > Hello frames can be done server->client->server to avoid a RTT's but > maybe it is better to have them client->server->client so that the > upgrade over HTTP would take one more RTT than a dedicated port and > thus give an incentive to push for opening a port. > > So if there was interest at this late stage of moving some headers to > hello frames - I'd be supportive of that. But I think we are too > far down the upgrade path to change now and should keep HTTP upgrade > for at least the short term. > > > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --90e6ba53b1ee3eb59f04a0117dd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


Is there some reason you can't specify the field invovled in the handsh= ake independent of the medium carrying them? Then use this to initialize th= e defaults of the dedicated WS framework handshake?

For instance, what's to prevent an XMPP or other transport from bein= g used if the protocol is designed with the proper degree of abstraction.

Timothy Meade
Real-time web developer

On Apr 4, 2011 1:51 AM, "Greg Wilkins"= <gregw@intalio.com> wrote:<= br type=3D"attribution">> On 4 April 2011 01:44, I=F1aki Baz Castillo &l= t;ibc@aliax.net> wrote:
>> 2011/4/3 Andy Green <andy@w= armcat.com>:
>>>> Unfortunatelly I think it's too= late for a new approach of the
>>>> WebSocket protocol, eve= n if it would be really a much better design
>>>> (IMHO).
>>>
>>> It's not any n= ew approach, you're just suggesting splitting off the
>>> h= andshake and the websocket transport definition into separate documents. >>> =A0The end result is the same, who cares.
>>
>&= gt; Instead of a HTTP handshake, I just suggest (as the first mail in this<= br>>> thread) the usage of a Websocket control frame to establish the= WS
>> "connection".
>
>
> I think we need = to consider this proposal in two parts:
>
> 1) Designing the = handshake/protocol so that it could work well over a
> dedicated port=
> 2) Actually deciding we want a dedicated port.
>
>
&= gt; Note that this was one of the reasons that I'm an advocate of Hello=
> frames. If we move much of the protocol parameterisation (eg sub<= br> > protocol and extension negotiation) into hello frames rather than HTTP=
> headers, then this is more portable and would work WHEN AND IF we=
> ever decided to have a dedicated port for ws.
>
> Hel= lo frames can be done server->client->server to avoid a RTT's but=
> maybe it is better to have them client->server->client so that t= he
> upgrade over HTTP would take one more RTT than a dedicated port = and
> thus give an incentive to push for opening a port.
>
> So if there was interest at this late stage of moving some headers to<= br>> hello frames - I'd be supportive of that. But I think we are= too
> far down the upgrade path to change now and should keep HTTP u= pgrade
> for at least the short term.
>
>
> cheers
> = _______________________________________________
> hybi mailing list> hybi@ietf.org
> https://www.ietf.org/mailma= n/listinfo/hybi
--90e6ba53b1ee3eb59f04a0117dd3-- From w@1wt.eu Sun Apr 3 23:05:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642EE3A6917 for ; Sun, 3 Apr 2011 23:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, SARE_LWSHORTT=1.24] 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 6x9QuvZEpBfj for ; Sun, 3 Apr 2011 23:05:50 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 1FBE73A67EF for ; Sun, 3 Apr 2011 23:05:49 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3467ThV016625; Mon, 4 Apr 2011 08:07:29 +0200 Date: Mon, 4 Apr 2011 08:07:29 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110404060729.GP5552@1wt.eu> References: <4D989304.9080802@warmcat.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.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 04 Apr 2011 06:05:51 -0000 On Mon, Apr 04, 2011 at 03:51:17PM +1000, Greg Wilkins wrote: > On 4 April 2011 01:44, Iñaki Baz Castillo wrote: > > 2011/4/3 Andy Green : > >>> Unfortunatelly I think it's too late for a new approach of the > >>> WebSocket protocol, even if it would be really a much better design > >>> (IMHO). > >> > >> It's not any new approach, you're just suggesting splitting off the > >> handshake and the websocket transport definition into separate documents. > >>  The end result is the same, who cares. > > > > Instead of a HTTP handshake, I just suggest (as the first mail in this > > thread) the usage of a Websocket control frame to establish the WS > > "connection". > > > I think we need to consider this proposal in two parts: > > 1) Designing the handshake/protocol so that it could work well over a > dedicated port > 2) Actually deciding we want a dedicated port. > > > Note that this was one of the reasons that I'm an advocate of Hello > frames. If we move much of the protocol parameterisation (eg sub > protocol and extension negotiation) into hello frames rather than HTTP > headers, then this is more portable and would work WHEN AND IF we > ever decided to have a dedicated port for ws. > > Hello frames can be done server->client->server to avoid a RTT's but > maybe it is better to have them client->server->client so that the > upgrade over HTTP would take one more RTT than a dedicated port and > thus give an incentive to push for opening a port. > > So if there was interest at this late stage of moving some headers to > hello frames - I'd be supportive of that. But I think we are too > far down the upgrade path to change now and should keep HTTP upgrade > for at least the short term. Agreed, and unfortunately, mandatory masking makes it harder to use hello frames to negociate anything. Or we should decide that the masking method can be negociated and defaults to XOR32 for client->server stream over HTTP. Willy From andy.warmcat.com@googlemail.com Mon Apr 4 01:24:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648403A6942 for ; Mon, 4 Apr 2011 01:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 CgqeaJwIBGn9 for ; Mon, 4 Apr 2011 01:24:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 503B23A6908 for ; Mon, 4 Apr 2011 01:24:38 -0700 (PDT) Received: by wwa36 with SMTP id 36so4289132wwa.13 for ; Mon, 04 Apr 2011 01:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WVRPJRywCSaaMblR6T19evB0igQ+rNlCLD3eqDa0B1o=; b=pLRg0fxsApxDuRVwCEqqqMWCu6ojcT0un3bg04LE0HsnmuFrfZ49LqYIsJv9M48e8d s01Wxng7BClggQoyQqQOwjgoYVgIviQ84AuJ8TMSCJpoC5E/Lw0BTIZlq5Ikh99Ycs6v Cv7DhPEbTLXdUuk/COR8k0Uc8TNUudta0CUj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=J2SDfAcpafn9MilGXpaT8sRHg/aSrQSVKZV2ks5zxCIZ+nU1pqUd8t/OzTEZ551TlM sZ+OJzeVAPWGAOXIBlODPXU4FefK+NK3xLGIsZe/U2xu+FvaVU7qWIgykQEKX4Zsy9aD NknmBLyW+jFqIQCDw7blAt9dgM4n/chKWuw7g= Received: by 10.227.177.13 with SMTP id bg13mr6417169wbb.92.1301905580157; Mon, 04 Apr 2011 01:26:20 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id p5sm2773666wbg.11.2011.04.04.01.26.18 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 01:26:19 -0700 (PDT) Sender: Andy Green Message-ID: <4D9980AA.7000905@warmcat.com> Date: Mon, 04 Apr 2011 09:26:18 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <4D989304.9080802@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 04 Apr 2011 08:24:46 -0000 On 04/04/2011 06:51 AM, Somebody in the thread at some point said: > So if there was interest at this late stage of moving some headers to > hello frames - I'd be supportive of that. But I think we are too > far down the upgrade path to change now and should keep HTTP upgrade > for at least the short term. I'm scratching my head at the value of this compared to the existing http handshake on a random port. Even if you use the websocket framing to do so, you will still have to do the dances like agree extensions, confirm it really talks websocket, look at protocol versioning, all the stuff that's already being done. The overhead of doing it like http is just the token names being given in ASCII? -Andy From salvatore.loreto@ericsson.com Mon Apr 4 01:25:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6933A6970 for ; Mon, 4 Apr 2011 01:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 h5Rx0rPPxfJE for ; Mon, 4 Apr 2011 01:25:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E469C28C0E4 for ; Mon, 4 Apr 2011 01:25:44 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-79-4d9980eea354 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.81.09202.EE0899D4; Mon, 4 Apr 2011 10:27:26 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Apr 2011 10:27:25 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BACBE262C for ; Mon, 4 Apr 2011 11:27:25 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 80F7250B39 for ; Mon, 4 Apr 2011 11:27:25 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 38DB3509C6 for ; Mon, 4 Apr 2011 11:27:25 +0300 (EEST) Message-ID: <4D9980ED.3070407@ericsson.com> Date: Mon, 4 Apr 2011 11:27:25 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020202010309010700040206" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 04 Apr 2011 08:25:58 -0000 --------------020202010309010700040206 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit (as a co-chair) back in late December 2010 we run the Straw Poll: "/is Upgrade with client->sever XOR mask acceptable/" some references: http://www.ietf.org/mail-archive/web/hybi/current/msg05378.html http://www.ietf.org/mail-archive/web/hybi/current/msg05389.html http://www.ietf.org/mail-archive/web/hybi/current/msg05426.html we reached rough consensus on the proposal, since then all the people involved in HyBi/WebSocket are working to standardize and improve (especially from a security point of view) that approach just to be clear the wg was not able to reach any form of consensus on any other alternative proposals (we had also one similar to this one), for a reason or another (e.g. NPN has been put on hold until TLS wg will make some progress) and *nothing let me think that something is changed since then*. So we have to live with Upgrade. cheers /Sal -- Salvatore Loreto www.sloreto.com On 4/1/11 5:54 AM, David Endicott wrote: > While I am not interested in disrupting or derailing the progress > being made on finalizing the Websocket specification, the recent > discussions about the initial HTTP Upgrade handshake leads me to offer > up the following proposal that I believe may resolve the situation. > > I propose we drop the HTTP Upgrade element from the WebSocket > specification entirely. I believe that the co-mingling of HTTP > Upgrade with WebSocket is a confusion of protocols and the two should > be more firmly separated. > > My justification is: > > 1. HTTP Upgrade request (and it's response) are properly part of a > HTTP exchange, not a WebSocket one. The use of HTTP Upgrade as a > mechanism to support WebSockets via a HTTP server is a good and valid > use of that HTTP capability, but it is not unique or specific to > WebSocket. Further, WebSocket protocol servers may not be part of a > HTTP serving environment and having it answer HTTP (however limited) > could confuse client agents. > > 2. When WebSocket is provided as part of a HTTP server stack, having > to instantiate the WebSocket serving process (thread/handler/etc.) > just to resolve the handshake and determine if a WebSocket connection > will actually proceed is awkward, potentially expensive > and possibly insecure. The responsibility to determine if the HTTP > server will support a HTTP Upgrade to any given protocol for a given > URL is properly the responsibility of the HTTP server, not WebSocket. > The HTTP server must be able, via the Upgrade request to consider > only (a) the URL and (b) the Upgrade protocol and decide if it will > support it. If it will, then all further negotiation is the > responsibility of the protocol being upgraded to. > > 3. If a HTTP server decides that it will allow an HTTP Upgrade to > WebSocket on the requested URL, the HTTP server can restrict the > WebSocket serving process to the docroot of that URL, thereby > maintaining consistency of the HTTP server's URL structure and > preventing the WebSocket server process from affecting any other part > of the filesystem as well as establishing a relative filesystem > context for the WebSocket serving process. The WebSocket server > process should not be allowed to determine the validity, > accessibility, remapping, etc. of the requested URL. That is the HTTP > server's responsibility. > > 4. When WebSocket is provided as a stand-alone process, using a HTTP > Upgrade as the handshake presents at least two problems. (a) changing > from line-oriented I/O (in the HTTP handshake) to a byte-oriented I/O > (for WebSocket frames) is awkward and potentially error prone, and (b) > any HTTP client-agent can potentially make a request to a WebSocket > server and get back a HTTP response, this exposes the availability and > capabilities of the WebSocket server to a client-agent that is not > actually a WebSocket client. Neither of these concerns is really all > that severe, but it is something to be aware of. > > Specifically I propose that the HTTP Upgrade based handshake be > removed from the WebSocket specification and replaced with a Control > frame handshake or negotiation. This would mean that all WebSocket > communication is done in websocket frames. This simplifies the > implementation and keeps each part in its own protocol context. It > strengthens the error checking between client-agents and the WebSocket > server. For example, if a HTTP client-agent incorrectly makes a > request of a stand-alone WebSocket server, the client's HTTP request > will fail as a WebSocket frame and the server can drop the connection. > The WebSocket server can further be assured that any establishing > connection that can provide valid frames is a client-agent that is > likely a conforming implementation. > > Personally I would prefer a negotiation control frame to be used as > the initial exchange. It defines that capability setup is determined > at connection establishment but also allows the possibility of later > re-negotiation should the situation change. Failing that, a simple > websocket based handshake would be fine. > > A note could be included on the use of the HTTP Upgrade by HTTP > servers as a mechanism to bootstrap a WebSocket connection, but this > is no different than it's use to boot-strap any other protocol. > Separating the two would allow the implementer to decide if and how > they wish to deal the ramifications of using that mechanism. > > > Again, let me reiterate that I have no interest in derailing this > working group, I have strong motivation to get a real > bidirectional asynchronous protocol into browser agents as soon as > possible, no matter how mangled the implementation. I will take good > over perfect, and soon over good. > > > tl;dr: HTTP is HTTP, WebSocket is WebSocket, do not mix. Leverage. > --------------020202010309010700040206 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit (as a co-chair)

back in late December 2010 we run the Straw Poll:
"is Upgrade with client->sever XOR mask acceptable"

some references:
http://www.ietf.org/mail-archive/web/hybi/current/msg05378.html
http://www.ietf.org/mail-archive/web/hybi/current/msg05389.html
http://www.ietf.org/mail-archive/web/hybi/current/msg05426.html

we reached rough consensus on the proposal,
since then all the people involved in HyBi/WebSocket are working to standardize
and improve (especially from a security point of view) that approach


just to be clear
the wg was not able to reach any form of consensus on any other alternative proposals
(we had also one similar to this one), for a reason or another
(e.g. NPN has been put on hold until TLS wg will make some progress)
and *nothing let me think that something is changed since then*.


So we have to live with Upgrade.


cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com



On 4/1/11 5:54 AM, David Endicott wrote:
While I am not interested in disrupting or derailing the progress being made on finalizing the Websocket specification, the recent discussions about the initial HTTP Upgrade handshake leads me to offer up the following proposal that I believe may resolve the situation.   

I propose we drop the HTTP Upgrade element from the WebSocket specification entirely.  I believe that the co-mingling of HTTP Upgrade with WebSocket is a confusion of protocols and the two should be more firmly separated.

My justification is:

1. HTTP Upgrade request (and it's response) are properly part of a HTTP exchange, not a WebSocket one.  The use of HTTP Upgrade as a mechanism to support WebSockets via a HTTP server is a good and valid use of that HTTP capability, but it is not unique or specific to WebSocket.   Further, WebSocket protocol servers may not be part of a HTTP serving environment and having it answer HTTP (however limited) could confuse client agents.   

2. When WebSocket is provided as part of a HTTP server stack, having to instantiate the WebSocket serving process (thread/handler/etc.) just to resolve the handshake and determine if a WebSocket connection will actually proceed is awkward, potentially expensive and possibly insecure.    The responsibility to determine if the HTTP server will support a HTTP Upgrade to any given protocol for a given URL is properly the responsibility of the HTTP server, not WebSocket.   The HTTP server must be able, via the Upgrade request to consider only (a) the URL and (b) the Upgrade protocol and decide if it will support it.   If it will, then all further negotiation is the responsibility of the protocol being upgraded to.

3. If a HTTP server decides that it will allow an HTTP Upgrade to WebSocket on the requested URL, the HTTP server can restrict the WebSocket serving process to the docroot of that URL, thereby maintaining consistency of the HTTP server's URL structure and preventing the WebSocket server process from affecting any other part of the filesystem as well as establishing a relative filesystem context for the WebSocket serving process.   The WebSocket server process should not be allowed to determine the validity, accessibility, remapping, etc. of the requested URL.  That is the HTTP server's responsibility.

4. When WebSocket is provided as a stand-alone process, using a HTTP Upgrade as the handshake presents at least two problems.  (a) changing from line-oriented I/O (in the HTTP handshake) to a byte-oriented I/O (for WebSocket frames) is awkward and potentially error prone, and (b) any HTTP client-agent can potentially make a request to a WebSocket server and get back a HTTP response, this exposes the availability and capabilities of the WebSocket server to a client-agent that is not actually a WebSocket client.   Neither of these concerns is really all that severe, but it is something to be aware of.
 

Specifically I propose that the HTTP Upgrade based handshake be removed from the WebSocket specification and replaced with a Control frame handshake or negotiation.    This would mean that all WebSocket communication is done in websocket frames.   This simplifies the implementation and keeps each part in its own protocol context.   It strengthens the error checking between client-agents and the WebSocket server.  For example, if a HTTP client-agent incorrectly makes a request of a stand-alone WebSocket server, the client's HTTP request will fail as a WebSocket frame and the server can drop the connection.  The WebSocket server can further be assured that any establishing connection that can provide valid frames is a client-agent that is likely a conforming implementation.

Personally I would prefer a negotiation control frame to be used as the initial exchange.  It defines that capability setup is determined at connection establishment but also allows the possibility of later re-negotiation should the situation change.    Failing that, a simple websocket based handshake would be fine.

A note could be included on the use of the HTTP Upgrade by HTTP servers as a mechanism to bootstrap a WebSocket connection, but this is no different than it's use to boot-strap any other protocol.   Separating the two would allow the implementer to decide if and how they wish to deal the ramifications of using that mechanism.   


Again, let me reiterate that I have no interest in derailing this working group, I have strong motivation to get a real bidirectional asynchronous protocol into browser agents as soon as possible, no matter how mangled the implementation.   I will take good over perfect, and soon over good.


tl;dr: HTTP is HTTP, WebSocket is WebSocket, do not mix.  Leverage.



--------------020202010309010700040206-- From simonp@opera.com Mon Apr 4 05:40:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7001F3A67D1 for ; Mon, 4 Apr 2011 05:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, 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 RZnYaR0s-3Fn for ; Mon, 4 Apr 2011 05:40:28 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 997C83A67D8 for ; Mon, 4 Apr 2011 05:40:27 -0700 (PDT) Received: from simon-pieterss-macbook.local ([87.253.73.138]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p34Cg70Z004677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Apr 2011 12:42:07 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "hybi@ietf.org" References: Date: Mon, 04 Apr 2011 14:42:05 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.10 (MacIntel) Subject: [hybi] Opera's Pre-Last Call review of websocket -06 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, 04 Apr 2011 12:40:40 -0000 Hi, We have reviewed http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 The introduction section is non-normative but has a number of MUSTs. Please don't have any requirements in the introduction. Why was Sec-WebSocket-Location removed? The spec does not define "WebSocket connection is established", "a WebSocket message has been received", "a WebSocket error has been detected", "the WebSocket closing handshake has started", which means that the API spec's hooks don't work and you would never get any 'open', 'message' or 'error' events. Should probably have some text about when pings may be sent. Should better cover error handling, e.g. what should happen when the high bit is set on the 63-bit length, what happens when the RSV bits are set, what should happen when FIN is set but opcode is 0x00, or a control frame is fragmented or has length greater than 125? I'd prefer detailed algorithms that covered every possible case, so that it is easy to argue that all cases are covered and so that it is clear when to fire relevant events and how many, etc. Just having a list with cases that are 'errors' does not make it clear when the error is to be detected or what should be done when multiple error cases match. > 2. Conformance requirements > All diagrams, examples, and notes in this specification are non- > normative, as are all sections explicitly marked non-normative. > Everything else in this specification is normative. > The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this > document are to be interpreted as described in RFC2119. For > readability, these words do not appear in all uppercase letters in > this specification. [RFC2119] It seems this specification uses a mix of lowercase and all uppercase. > Requirements phrased in the imperative as part of algorithms (such as > "strip any leading space characters" or "return false and abort these > steps") are to be interpreted with the meaning of the key word > ("must", "should", "may", etc) used in introducing the algorithm. > Conformance requirements phrased as algorithms or specific steps may > be implemented in any manner, so long as the end result is > equivalent. (In particular, the algorithms defined in this > specification are intended to be easy to follow, and not intended to > be performant.) > Implementations may impose implementation-specific limits on > otherwise unconstrained inputs, e.g. to prevent denial of service > attacks, to guard against running out of memory, or to work around > platform-specific limitations. > The conformance classes defined by this specification are user agents > and servers. > 2.1. Terminology > *ASCII* shall mean the character-encoding scheme defined in > [ANSI.X3-4.1986]. > *Converting a string to ASCII lowercase* means replacing all > characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER > A to LATIN CAPITAL LETTER Z) with the corresponding characters in the > range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL > LETTER Z). > Comparing two strings in an *ASCII case-insensitive* manner means > comparing them exactly, code point for code point, except that the > characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER > A to LATIN CAPITAL LETTER Z) and the corresponding characters in the > range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL > LETTER Z) are considered to also match. > The term "URI" is used in this section in a manner consistent with > the terminology used in HTML, namely, to denote a string that might > or might not be a valid URI or IRI and to which certain error > handling behaviors will be applied when the string is parsed. > [RFC3986] HTML calls it "URL", so doesn't seem particularly consistent. > When an implementation is required to _send_ data as part of the > WebSocket protocol, the implementation may delay the actual > transmission arbitrarily, e.g. buffering data so as to send fewer IP > packets. > 3. WebSocket URIs > 3.1. Parsing WebSocket URIs > The steps to *parse a WebSocket URI's components* from a string /uri/ > are as follows. These steps return either a /host/, a /port/, a > /resource name/, and a /secure/ flag, or they fail. > 1. If the /uri/ string is not an absolute URI, then fail this > algorithm. [RFC3986] [RFC3987] > 2. Resolve the /uri/ string using the resolve a Web address > algorithm defined by the Web addresses specification, with the > URI character encoding set to UTF-8. [RFC3629] [RFC3986] > [RFC3987] > NOTE: It doesn't matter what it is resolved relative to, since > we already know it is an absolute URI at this point. > 3. If /uri/ does not have a component whose value, when > converted to ASCII lowercase, is either "ws" or "wss", then fail > this algorithm. > 4. If /uri/ has a component, then fail this algorithm. > 5. If the component of /uri/ is "ws", set /secure/ to > false; otherwise, if the component is "wss", set > /secure/ to true; otherwise, fail this algorithm. We already know it's either "ws" or "wss", so this can't fail. > 6. Let /host/ be the value of the component of /uri/, > converted to ASCII lowercase. > 7. If /uri/ has a component, then let /port/ be that > component's value; otherwise, there is no explicit /port/. > 8. If there is no explicit /port/, then: if /secure/ is false, let > /port/ be 80, otherwise let /port/ be 443. > 9. Let /resource name/ be the value of the component (which > might be empty) of /uri/. > 10. If /resource name/ is the empty string, set it to a single > character U+002F SOLIDUS (/). > 11. If /uri/ has a component, then append a single U+003F > QUESTION MARK character (?) to /resource name/, followed by the > value of the component. > 12. Return /host/, /port/, /resource name/, and /secure/. > 3.2. Constructing WebSocket URIs > The steps to *construct a WebSocket URI* from a /host/, a /port/, a > /resource name/, and a /secure/ flag, are as follows: > 1. Let /uri/ be the empty string. > 2. If the /secure/ flag is false, then append the string "ws://" to > /uri/. Otherwise, append the string "wss://" to /uri/. > 3. Append /host/ to /uri/. > 4. If the /secure/ flag is false and port is not 80, or if the > /secure/ flag is true and port is not 443, then append the string > ":" followed by /port/ to /uri/. > 5. Append /resource name/ to /uri/. > 6. Return /uri/. > 3.3. Valid WebSocket URIs > For a WebSocket URI to be considered valid, the following conditions > MUST hold. > o The /host/ must be ASCII-only (i.e. it must have been punycode- > encoded already if necessary, and MUST NOT contain any characters > above U+007E). > o The /resource name/ string must be a non-empty string of > characters in the range U+0021 to U+007E that starts with a U+002F > SOLIDUS character (/). > Any WebSocket URIs not meeting the above criteria are considered > invalid, and a client MUST NOT attempt to make a connection to an > invalid WebSocket URI. A client SHOULD attempt to parse a URI > obtained from any external source (such as a web site or a user) > using the steps specified in Section 3.1 to obtain a valid WebSocket > URI, but MUST NOT attempt to connect with such an unparsed URI, and > instead only use the parsed version and only if that version is > considered valid by the criteria above. > 4. Data Framing > 4.1. Overview > In the WebSocket protocol, data is transmitted using a sequence of > frames. Frames sent from the client to the server are masked to > avoid confusing network intermediaries, such as intercepting proxies. > Frames sent from the server to the client are not masked. > The base framing protocol defines a frame type with an opcode, a > payload length, and designated locations for extension and > application data, which together define the _payload_ data. Certain > bits and opcodes are reserved for future expansion of the protocol. > As such, In the absence of extensions negotiated during the opening > handshake (Section 5), all reserved bits MUST be 0 and reserved > opcode values MUST NOT be used. > A data frame MAY be transmitted by either the client or the server at > any time after handshake completion and before that endpoint has sent > a close message (Section 4.5.1). > 4.2. Client-to-Server Masking > The client MUST mask all frames sent to the server. > The masking-key is contained completely within the frame. > The masking-key is a 32-bit value chosen at random by the client. > The masking-key MUST be derived from a strong source of entropy, and > the masking-key for a given frame MUST NOT make it simple for a > server to predict the masking-key for a subsequent frame. > Each masked frame consists of a 32-bit masking-key followed by > masked-data: > masked-frame = masking-key masked-data > masking-key = 4full-octet > masked-data = *full-octet > full-octet = %x00-FF > The masked-data is the clear-text frame "encrypted" using a simple > XOR cipher as follows. > Octet i of the masked-data is the XOR of octet i of the clear text > frame with octet i modulo 4 of the masking-key: > j = i MOD 4 > masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key > When preparing a masked-frame, the client MUST pick a fresh masking- > key uniformly at random from the set of allowed 32-bit values. The > unpredictability of the masking-nonce is essential to prevent the > author of malicious application data from selecting the bytes that > appear on the wire. > 4.3. Base Framing Protocol > This wire format for the data transfer part is described by the ABNF > given in detail in this section. A high level overview of the > framing is given in the following figure. [RFC5234] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|R| Payload len | Extended payload length | > |I|S|S|S| (4) |S| (7) | (16/63) | > |N|V|V|V| |V| | (if payload len==126/127) | > | |1|2|3| |4| | | > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > | Extended payload length continued, if payload len == 127 | > + - - - - - - - - - - - - - - - +-------------------------------+ > | | Extension data | > +-------------------------------+ - - - - - - - - - - - - - - - + > : : > +---------------------------------------------------------------+ > : Application data : > +---------------------------------------------------------------+ > FIN: 1 bit > Indicates that this is the final fragment in a message. The first > fragment may also be the final fragment. > RSV1, RSV2, RSV3, RSV4: 1 bit each > Must be 0 unless an extension is negotiated which defines meanings > for non-zero values > Opcode: 4 bits > Defines the interpretation of the payload data > Payload length: 7 bits > The length of the payload: if 0-125, that is the payload length. > If 126, the following 2 bytes interpreted as a 16 bit unsigned > integer are the payload length. If 127, the following 8 bytes > interpreted as a 64-bit unsigned integer (the high bit must be 0) > are the payload length. Multibyte length quantities are expressed > in network byte order. The payload length is the length of the > Extension data + the length of the Application Data. The length > of the Extension data may be zero, in which case the Payload > length is the length of the Application data. > Extension data: n bytes > The extension data is 0 bytes unless there is a reserved op-code > or reserved bit present in the frame which indicates an extension > has been negotiated. Any extension MUST specify the length of the > extension data, or how that length may be calculated, and its use > MUST be negotiated during the handshake. If present, the > extension data is included in the total payload length. > Application data: n bytes > Arbitrary application data, taking up the remainder of the frame > after any extension data. The length of the Application data is > equal to the payload length minus the length of the Extension > data. > The base framing protocol is formally defined by the following ABNF > [RFC5234]: > ws-frame = frame-fin > frame-rsv1 > frame-rsv2 > frame-rsv3 > frame-opcode > frame-rsv4 > frame-length > frame-extension > application-data; > frame-fin = %x0 ; more frames of this message follow > / %x1 ; final frame of message > frame-rsv1 = %x0 ; 1 bit, must be 0 > frame-rsv2 = %x0 ; 1 bit, must be 0 > frame-rsv3 = %x0 ; 1 bit, must be 0 > frame-opcode = %x0 ; continuation frame > / %x1 ; connection close > / %x2 ; ping > / %x3 ; pong > / %x4 ; text frame > / %x5 ; binary frame > / %x6-F ; reserved > frame-rsv4 = %x0 ; 1 bit, must be 0 > frame-length = %x00-7D > / %x7E frame-length-16 > / %x7F frame-length-63 > frame-length-16 = %x0000-FFFF > frame-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF > frame-extension = *( %x00-FF ) ; to be defined later > application-data = *( %x00-FF ) > 4.4. Fragmentation > The primary purpose of fragmentation is to allow sending a message > that is of unknown size when the message is started without having to > buffer that message. If messages couldn't be fragmented, then an > endpoint would have to buffer the entire message so its length could > be counted before first byte is sent. With fragmentation, a server > or intermediary may choose a reasonable size buffer, and when the > buffer is full write a fragment to the network. > A secondary use-case for fragmentation is for multiplexing, where it > is not desirable for a large message on one logical channel to > monopolize the output channel, so the MUX needs to be free to split > the message into smaller fragments to better share the output > channel. > The following rules apply to fragmentation: > o An unfragmented message consists of a single frame with the FIN > bit set and an opcode other than 0. > o A fragmented message consists of a single frame with the FIN bit > clear and an opcode other than 0, followed by zero or more frames > with the FIN bit clear and the opcode set to 0, and terminated by > a single frame with the FIN bit set and an opcode of 0. Its > content is the concatenation of the application data from each of > those frames in order. As an example, for a text message sent as > three fragments, the first fragment would have an opcode of 0x4 > and a FIN bit clear, the second fragment would have an opcode of > 0x0 and a FIN bit clear, and the third fragment would have an > opcode of 0x0 and a FIN bit that is set. > o Control frames MAY be injected in the middle of a fragmented > message. Control frames themselves MUST NOT be fragmented. _Note: > if control frames could not be interjected, the latency of a ping, > for example, would be very long if behind a large message. As > such, an endpoint MUST be capable of handling control frames in > the middle of a fragmented message._ Please don't have MUSTs inside notes, since the conformance section says notes are non-normative. > o A sender MAY create fragments of any size for non control > messages. > o Clients and servers MUST support receiving both fragmented and > unfragmented messages. > o An intermediary MAY change the fragmentation of a message if the > message uses only opcode and reserved bit values known to the > intermediary. > o As a consequence of these rules, all fragments of a message are of > the same type, as set by the first fragment's opcode. Since > Control frames cannot be fragmented, the type for all fragments in > a message MUST be either text or binary, or one of the reserved > opcodes. > 4.5. Control Frames > Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03 > (Pong). Control frames are used to communicate state about the > websocket. Control frames can be interjected in the middle of a > fragmented message. > All control frames MUST be 125 bytes or less in length and MUST NOT > be fragmented. > 4.5.1. Close > The Close message contains an opcode of 0x01. > The Close message MAY contain a body (the "application data" portion > of the frame) that indicates a reason for closing, such as an > endpoint shutting down, an endpoint having received a message too > large, or an endpoint having received a message that does not conform > to the format expected by the other endpoint. If there is a body, > the first two bytes of the body MUST be a 2-byte integer (in network > byte order) representing a status code defined in Section 7.4. > Following the 2-byte integer the body MAY contain UTF-8 encoded data, > the interpretation of which is not defined by this specification. > The application MUST NOT send any more data messages after sending a > close message. What are 'data messages'? I see data frames, but not data messages. Are control frames allowed to be sent after close? > If an endpoint receives a Close message and that endpoint did not > previously send a Close message, the endpoint MUST send a Close > message in response. It SHOULD do so as soon as is practical. > After both sending and receiving a close message, an endpoint > considers the websocket connection closed, and SHOULD close the > underlying TCP connection. > If a client and server both send a Close message at the same time, > both endpoints will have sent and received a Close message and should > consider the websocket connection closed and close the underlying TCP > connection. > 4.5.2. Ping > The Ping message contains an opcode of 0x02. > Upon receipt of a Ping message, an endpoint MUST send a Pong message > in response. It SHOULD do so as soon as is practical. The message > bodies of the Ping and Pong MUST be the same. > 4.5.3. Pong > The Pong message contains an opcode of 0x03. > Upon receipt of a Ping message, an endpoint MUST send a Pong message > in response. It SHOULD do so as soon as is practical. The message > bodies of the Ping and Pong MUST be the same. A Pong is issued only > in response to the most recent Ping. This text is identical to the text in the previous section, except for the last sentence. I suggest stating the requirements only once, and making the last sentence normative by including a MUST. > 4.6. Data Frames > All frame types not listed in Section 4.5 are data frames, which > transport application-layer data. The opcode determines the > interpretation of the application data: > Text > The payload data is text data encoded as UTF-8. > Binary > The payload data is arbitrary binary data whose interpretation is > solely up to the application layer. > 4.7. Examples > _This section is non-normative._ > o A single-frame text message > * 0x84 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello") > o A fragmented text message > * 0x04 0x03 0x48 0x65 0x6c (contains "Hel") > * 0x80 0x02 0x6c 0x6f (contains "lo") > o Ping request and response > * 0x82 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", > but the contents of the body are arbitrary) > * 0x83 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", > matching the body of the ping) > o 256 bytes binary message in a single frame > * 0x85 0x7E 0x0100 [256 bytes of binary data] > o 64KiB binary message in a single frame > * 0x85 0x7F 0x0000000000010000 [65536 bytes of binary data] > 4.8. Extensibility > The protocol is designed to allow for extensions, which will add > capabilities to the base protocols. The endpoints of a connection > MUST negotiate the use of any extensions during the handshake. This > specification provides opcodes 0x6 through 0xF, the extension data > field, and the frame-rsv1, frame-rsv2, frame-rsv3, and frame-rsv4 > bits of the frame header for use by extensions. The negotiation of > extensions is discussed in further detail in Section 8.1. Below are > some anticipated uses of extensions. This list is neither complete > nor proscriptive. > o Extension data may be placed in the payload before the application > data. > o Reserved bits can be allocated for per-frame needs. > o Reserved opcode values can be defined. > o Reserved bits can be allocated to the opcode field if more opcode > values are needed. > o A reserved bit or an "extension" opcode can be defined which > allocates additional bits out of the payload area to define larger > opcodes or more per-frame bits. > 5. Opening Handshake > 5.1. Client Requirements > User agents running in controlled environments, e.g. browsers on > mobile handsets tied to specific carriers, may offload the management > of the connection to another agent on the network. In such a > situation, the user agent for the purposes of conformance is > considered to include both the handset software and any such agents. > When the user agent is to *establish a WebSocket connection* to a > WebSocket URI /uri/, it must meet the following requirements. In the > following text, we will use terms from Section 3 such as "/host/" and > "/secure/ flag" as defined in that section. Section 11 says that specifications are to feed this algorithm with /host/, /port/, /resource name/, /secure/, /origin/ and /subprotocol/. Not /uri/. The WebSocket API invokes this algorithm in accordance with section 11. Please make this text closer to what it is in -00. Actually the WebSocket API also has a /defer cookies/ flag. It seems this has not been incorporated into the spec, or has been dropped at some point. Please take in the defer cookies stuff from http://www.whatwg.org/specs/web-socket-protocol/ (the opening paragraph in section 5, step 46 and 47 in the algorithm, and the *apply the cookies* definition. > 1. The WebSocket URI and its components MUST be valid according to > Section 3.3. If any of the requirements are not met, the client > MUST fail the WebSocket connection and abort these steps. Checking this is the responsibility of the API spec, by invoking "parse a WebSocket URI's components" defined in this specification. If it fails to parse, this algorithm is not invoked to begin with. > 2. If the user agent already has a WebSocket connection to the > remote host (IP address) identified by /host/, even if known by > another name, the user agent MUST wait until that connection has > been established or for that connection to have failed. There > MUST be no more than one connection in a CONNECTING state. If Regardless of host? So we serialize tabs as well? > multiple connections to the same IP address are attempted > simultaneously, the user agent MUST serialize them so that there > is no more than one connection at a time running through the > following steps. > If the user agent cannot determine the IP address of the remote > host (for example because all communication is being done through > a proxy server that performs DNS queries itself), then the user > agent MUST assume for the purposes of this step that each host > name refers to a distinct remote host, but should instead limit > the total number of simultaneous connections that are not > established to a reasonably low number (e.g., in a Web browser, > to the number of tabs the user has open). > NOTE: This makes it harder for a script to perform a denial of > service attack by just opening a large number of WebSocket > connections to a remote host. A server can further reduce the > load on itself when attacked by making use of this by pausing > before closing the connection, as that will reduce the rate at > which the client reconnects. > NOTE: There is no limit to the number of established WebSocket > connections a user agent can have with a single remote host. No upper limit? > Servers can refuse to connect users with an excessive number of > connections, or disconnect resource-hogging users when suffering > high load. > 3. _Proxy Usage_: If the user agent is configured to use a proxy > when using the WebSocket protocol to connect to host /host/ > and/or port /port/, then the user agent SHOULD connect to that > proxy and ask it to open a TCP connection to the host given by > /host/ and the port given by /port/. > EXAMPLE: For example, if the user agent uses an HTTP proxy for > all traffic, then if it was to try to connect to port 80 on > server example.com, it might send the following lines to the > proxy server: > CONNECT example.com:80 HTTP/1.1 > Host: example.com > If there was a password, the connection might look like: > CONNECT example.com:80 HTTP/1.1 > Host: example.com > Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= > If the user agent is not configured to use a proxy, then a direct > TCP connection SHOULD be opened to the host given by /host/ and > the port given by /port/. > NOTE: Implementations that do not expose explicit UI for > selecting a proxy for WebSocket connections separate from other > proxies are encouraged to use a SOCKS proxy for WebSocket > connections, if available, or failing that, to prefer the proxy > configured for HTTPS connections over the proxy configured for > HTTP connections. > For the purpose of proxy autoconfiguration scripts, the URI to > pass the function must be constructed from /host/, /port/, > /resource name/, and the /secure/ flag using the steps to > construct a WebSocket URI. > NOTE: The WebSocket protocol can be identified in proxy > autoconfiguration scripts from the scheme ("ws:" for unencrypted > connections and "wss:" for encrypted connections). > 4. If the connection could not be opened, either because a direct > connection failed or because any proxy used returned an error, > then the user agent MUST fail the WebSocket connection and abort > the connection attempt. > 5. If /secure/ is true, the user agent MUST perform a TLS handshake > over the connection. If this fails (e.g. the server's > certificate could not be verified), then the user agent MUST fail What about popping open a dialogue if the cert is self signed? > the WebSocket connection and abort the connection. Otherwise, > all further communication on this channel MUST run through the > encrypted tunnel. [RFC2246] > User agents MUST use the Server Name Indication extension in the > TLS handshake. [RFC4366] > Once a connection to the server has been established (including a > connection via a proxy or over a TLS-encrypted tunnel), the client > MUST send a handshake to the server. The handshake consists of an > HTTP upgrade request, along with a list of required and optional > headers. The requirements for this handshake are as follows. > 1. The handshake must be a valid HTTP request as specified by > [RFC2616]. > 2. The Method of the request MUST be GET and the HTTP version MUST > be at least 1.1. > For example, if the WebSocket URI is "ws://example.com/chat", > The first line sent SHOULD be "GET /chat HTTP/1.1" Please don't use SHOULD in an example, since examples are non-normative. > 3. The request must contain a "Request-URI" as part of the GET > method. This MUST match the /resource name/ Section 3. > 4. The request MUST contain a "Host" header whose value is equal to > the authority component of the WebSocket URI. Make it equal to /host/ since parsing a WebSocket URI's components will convert it to lowercase. > 5. The request MUST contain an "Upgrade" header whose value is > equal to "websocket". > 6. The request MUST contain a "Connection" header whose value MUST > include the "Upgrade" token. > 7. The request MUST include a header with the name "Sec-WebSocket- > Key". The value of this header MUST be a nonce consisting of a > randomly selected 16-byte value that has been base64-encoded > [RFC3548]. The nonce MUST be randomly selected randomly for > each connection. Double randomly. > NOTE: As an example, if the randomly selected value was the > sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 > 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header > would be "AQIDBAUGBwgJCgsMDQ4PEC==" > 8. The request MUST include a header with the name "Sec-WebSocket- > Origin" if the request is coming from a browser client. If the Maybe the conformance section should have different conformance classes for browesr clients and non-browser clients. > connection is from a non-browser client, the request MAY include > this header if the semantics of that client match the use-case > described here for browser clients. The value of this header > MUST be the ASCII serialization of origin of the context in > which the code establishing the connection is running, and MUST > be lower-case. The value MUST NOT contain letters in the range > U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL > LETTER Z) [I-D.ietf-websec-origin]. > As an example, if code is running on www.example.com attempting > to establish a connection to ww2.example.com, the value of the > header would be "http://www.example.com". > 9. The request MUST include a header with the name "Sec-WebSocket- > Version". The value of this header must be 6. > 10. The request MAY include a header with the name "Sec-WebSocket- > Protocol". If present, this value indicates the subprotocol(s) > the client wishes to speak. The elements that comprise this > value MUST be non-empty strings with characters in the range > U+0021 to U+007E and MUST all be unique. The ABNF for the value and MUST all be unique strings. (just to make sure you don't think the characters must be unique) > of this header is 1#(token | quoted-string), where the > definitions of constructs and rules are as given in [RFC2616]. I'd like this to say that, at least for browser clients, if the algorithm was invoked with a non-empty list of /subprotocols/ then the header MUST be included, with the values of /subprotocols/ joined by a comma and a space, and otherwise MUST NOT be included. Otherwise a browser would be conforming for requesting subprotocols at random. > 11. The request MAY include a header with the name "Sec-WebSocket- > Extensions". If present, this value indicates the protocol- > level extension(s) the client wishes to speak. The > interpretation and format of this header is described in > Section 8.1. > 12. The request MAY include headers associated with sending cookies, > as defined by the appropriate specifications > [I-D.ietf-httpstate-cookie]. Any cookies at random? I'd like, at least for browser clients, for this to be tighter, as it was in -00. > Once the client's opening handshake has been sent, the client MUST > wait for a response from the server before sending any further data. > The client MUST validate the server's response as follows: > o If the status code received from the server is not 101, the client > MUST fail the WebSocket connection. > o If the response lacks an Upgrade header or the Upgrade header > contains a value that is not an ASCII case-insensitive match for > the value "websocket", the client MUST fail the WebSocket > connection. > o If the response lacks a Connection header or the Connection header > contains a value that is not an ASCII case-insensitive match for > the value "Upgrade", the client MUST fail the WebSocket > connection. > o If the response lacks a Sec-WebSocket-Accept header or the Sec- > WebSocket-Accept contains a value other than the base64-encoded > SHA-1 of the concatenation of the Sec-WebSocket-Key (as a string, > not base64-decoded) with the string "258EAFA5-E914-47DA-95CA- > C5AB0DC85B11", the client MUST fail the WebSocket connection. -00 had rules for failing the websocket connection if the response had certain other errors, like the wrong type of linebreaks. What's the deal now? I haven't reviewed the security implications, but there may be some if clients are tolerant in their parsing of the server's handshake. > Where the algorithm above requires that a user agent fail the > WebSocket connection, the user agent may first read an arbitrary > number of further bytes from the connection (and then discard them) > before actually *failing the WebSocket connection*. Similarly, if a > user agent can show that the bytes read from the connection so far > are such that there is no subsequent sequence of bytes that the > server can send that would not result in the user agent being > required to *fail the WebSocket connection*, the user agent may > immediately *fail the WebSocket connection* without waiting for those > bytes. > NOTE: The previous paragraph is intended to make it conforming for > user agents to implement the algorithm in subtly different ways that > are equivalent in all ways except that they terminate the connection > at earlier or later points. For example, it enables an > implementation to buffer the entire handshake response before > checking it, or to verify each field as it is received rather than > collecting all the fields and then checking them as a block. It seems these two paragraphs aren't needed anymore when you don't have a detailed algorithm but just some bullet points. > 5.2. Server-side requirements > _This section only applies to servers._ > Servers may offload the management of the connection to other agents > on the network, for example load balancers and reverse proxies. In > such a situation, the server for the purposes of conformance is > considered to include all parts of the server-side infrastructure > from the first device to terminate the TCP connection all the way to > the server that processes requests and sends responses. > EXAMPLE: For example, a data center might have a server that responds > to WebSocket requests with an appropriate handshake, and then passes > the connection to another server to actually process the data frames. > For the purposes of this specification, the "server" is the > combination of both computers. > 5.2.1. Reading the client's opening handshake > When a client starts a WebSocket connection, it sends its part of the > opening handshake. The server must parse at least part of this > handshake in order to obtain the necessary information to generate > the server part of the handshake. > The client handshake consists of the following parts. If the server, > while reading the handshake, finds that the client did not send a > handshake that matches the description below, the server must abort > the WebSocket connection. > 1. An HTTP/1.1 or higher GET request, including a "Request-URI" > [RFC2616] that should be interpreted as a /resource name/ > Section 3. > 2. A "Host" header containing the server's authority. > 3. A "Sec-WebSocket-Key" header with a base64-encoded value that, > when decoded, is 16 bytes in length. > 4. A "Sec-WebSocket-Version" header, with a value of 6. > 5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent > by all browser clients. A connection attempt lacking this header > SHOULD NOT be interpreted as coming from a browser client. > 6. Optionally, a "Sec-WebSocket-Protocol header, with a list of > values indicating which protocols the client would like to speak, > ordered by preference. Missing quote. -00 was stricter about the Sec-WebSocket-Protocol header: if the algorithm was fed with an empty /subprotocols/ then the header must not be included, else the header must be included with the values of /subprotocols/. I prefer that over anything-goes "optinally". > 7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of > values indicating which extensions the client would like to > speak. The interpretation of this header is discussed in > Section 8.1. > 8. Optionally, other headers, such as those used to send cookies to > a server. Unknown headers MUST be ignored. > 5.2.2. Sending the server's opening handshake > When a client establishes a WebSocket connection to a server, the > server must complete the following steps to accept the connection and > send the server's opening handshake. > 1. If the server supports encryption, perform a TLS handshake over > the connection. If this fails (e.g. the client indicated a host If the server supports encryption? A bit unclear... if can support encryption but the requested URL might be ws: > name in the extended client hello "server_name" extension that > the server does not host), then close the connection; otherwise, > all further communication for the connection (including the > server handshake) must run through the encrypted tunnel. > [RFC2246] > 2. Establish the following information: > /origin/ > The |Sec-WebSocket-Origin| header in the client's handshake > indicates the origin of the script establishing the > connection. The origin is serialized to ASCII and converted > to lowercase. The server MAY use this information as part of > a determination of whether to accept the incoming connection. I'd like a warning here that if the server doesn't validate the origin, it means that it will accept connections from anywhere. Normally it's the browser's responsibility to enforce same-origin restrictions, but with websockets it's the server application developer's responsibility, and this needs to be pointed out explicitly IMHO. I see now that there's a paragraph discussing this in security considerations. I'd be happy with a pointer to security considerations here. > /key/ > The |Sec-WebSocket-Key| header in the client's handshake > includes a base64-encoded value that, if decoded, is 16 bytes > in length. This (encoded) value is used in the creation of > the server's handshake to indicate an acceptance of the > connection. It is not necessary for the server to base64- > decode the Sec-WebSocket-Key value. > /version/ > The |Sec-WebSocket-Version| header in the client's handshake > includes the version of the WebSocket protocol the client is > attempting to communicate with. If this version does not > match a version understood by the server, the server MUST > abort the WebSocket connection. The server MAY send a non-200 > response code with a |Sec-WebSocket-Version| header indicating > the version(s) the server is capable of understanding along > with this non-200 response code. > /resource name/ > An identifier for the service provided by the server. If the > server provides multiple services, then the value should be > derived from the resource name given in the client's handshake > from the Request-URI [RFC2616] of the GET method. > /subprotocol/ > A (possibly empty) list representing the subprotocol the > server is ready to use. If the server supports multiple > subprotocols, then the value should be derived from the > client's handshake, specifically by selecting one of the > values from the "Sec-WebSocket-Protocol" field. The absence > of such a field is equivalent to the null value. The empty > string is not the same as the null value for these purposes. > /extensions/ > A (possibly empty) list representing the protocol-level > extensions the server is ready to use. If the server supports > multiple extensions, then the value should be derived from the > client's handshake, specifically by selecting one or more of > the values from the "Sec-WebSocket-Extensions" field. The > absence of such a field is equivalent to the null value. The > empty string is not the same as the null value for these > purposes. Extensions not listed by the client MUST NOT be > listed. The method by which these values should be selected > and interpreted is discussed in Section 8.1. > 3. If the server chooses to accept the incoming connection, it must > reply with a valid HTTP response indicating the following. > 1. A 101 response code. Such a response could look like > "HTTP/1.1 101 Switching Protocols" > 2. A "Sec-WebSocket-Accept" header. The value of this header is > constructed by concatenating /key/, defined above in > Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914- > 47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this > concatenated value to obtain a 20-byte value, and base64- > encoding this 20-byte hash. > NOTE: As an example, if the value of the "Sec-WebSocket-Key" > header in the client's handshake were > "dGhlIHNhbXBsZSBub25jZQ==", the server would append the > string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the > string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- > C5AB0DC85B11". The server would then take the SHA-1 hash of > this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 > 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe > 0xc4 0xea. This value is then base64-encoded, to give the > value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned > in the "Sec-WebSocket-Accept" header. > 3. Optionally, a "Sec-WebSocket-Protocol" header, with a value > /subprotocol/ as defined in Paragraph 2 of Section 5.2.2. > 4. Optionally, a "Sec-WebSocket-Extensions" header, with a value > /extensions/ as defined in Paragraph 2 of Section 5.2.2. > This completes the server's handshake. If the server finishes these > steps without aborting the WebSocket connection, and if the client > does not then fail the WebSocket connection, then the connection is > established and the server may begin sending and receiving data, as > described in the next section. The next section doesn't describe sending and receiving data. > 6. Error Handling > 6.1. Handling errors in UTF-8 from the server > When a client is to interpret a byte stream as UTF-8 but finds that > the byte stream is not in fact a valid UTF-8 stream, then any bytes > or sequences of bytes that are not valid UTF-8 sequences must be > interpreted as a U+FFFD REPLACEMENT CHARACTER. Maybe use the HTML spec's definition of UTF-8 with error handling: http://www.whatwg.org/specs/web-apps/current-work/complete/infrastructure.html#decoded-as-utf-8,-with-error-handling > 6.2. Handling errors in UTF-8 from the client > When a server is to interpret a byte stream as UTF-8 but finds that > the byte stream is not in fact a valid UTF-8 stream, behavior is > undefined. A server could close the connection, convert invalid byte > sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim, > or perform application-specific processing. Subprotocols layered on > the WebSocket protocol might define specific behavior for servers. > 7. Closing the connection > 7.1. Definitions > 7.1.1. Close the WebSocket Connection > To _Close the WebSocket Connection_, an endpoint closes the > underlying TCP connection. An endpoint SHOULD use a method that > cleanly closes the TCP connection, discarding any trailing bytes that > may be received. And endpoint MAY close the connection via any means s/And/An/ > available when necessary, such as when under attack. > As an example of how to obtain a clean closure in C using Berkeley > sockets, one would call shutdown() with SHUT_WR on the socket, call > recv() until obtaining a return value of 0 indicating that the peer > has also performed an orderly shutdown, and finally calling close() > on the socket. Hmm, this example seems a bit out of place. > 7.1.2. Start the WebSocket Closing Handshake > To _start the WebSocket closing handshake_, and endpoint MUST send a s/and/an/ > Close control frame, as described in Section 4.5.1. Upon receiving a > Close control frame, the other party sends a Close control frame in > response. Once an endpoint has both sent and received a Close > control frame, that endpoint should _Close the WebSocket Connection_ > as defined in Section 7.1.1. Again this repeats the same requirements from 4.5.1, but subtly different, such that it's not clear which to follow. Please only have the same requirement once. > 7.1.3. The WebSocket Connection Is Closed > When the underlying TCP connection is closed, it is said that _the > WebSocket connection is closed_. If the tcp connection was closed > after the WebSocket closing handshake was completed, the WebSocket > connection is said to have been closed _cleanly_. > 7.1.4. Fail the WebSocket Connection > Certain algorithms and specifications require a user agent to _fail > the WebSocket connection_. To do so, the user agent must _Close the > WebSocket Connection_, and MAY report the problem to the user (which > would be especially useful for developers) in an appropriate manner. > Except as indicated above or as specified by the application layer > (e.g. a script using the WebSocket API), user agents SHOULD NOT close > the connection. > 7.2. Abnormal closures > 7.2.1. Client-initiated closure > Certain algorithms, namely during the initial handshake, require the > user agent to *fail the WebSocket connection*. To do so, the user > agent must _Close the WebSocket connection_ as previously defined, > and may report the problem to the user via an appropriate mechanism > (which would be especially useful for developers). > Except as indicated above or as specified by the application layer > (e.g. a script using the WebSocket API), user agents should not close > the connection. > 7.2.2. Server-initiated closure > Certain algorithms require or recommend that the server _abort the > WebSocket connection_ during the opening handshake. To do so, the > server must simply _close the WebSocket connection_ (Section 7.1.1). > 7.3. Normal closure of connections > Servers MAY close the WebSocket connection whenever desired. User > agents SHOULD NOT close the WebSocket connection arbitrarily. In > either case, an endpoint initiates a closure by following the > procedures to _start the WebSocket closing handshake_ > (Section 7.1.2). > 7.4. Status codes > When closing an established connection (e.g. when sending a Close > frame, after the handshake has completed), an endpoint MAY indicate a > reason for closure. The interpretation of this reason by an > endpoint, and the action an endpoint should take given this reason, > are left undefined by this specification. This specification defines > a set of pre-defined status codes, and specifies which ranges may be > used by extensions, frameworks, and end applications. The status > code and any associated textual message are optional components of a > Close frame. > 7.4.1. Defined Status Codes > Endpoints MAY use the following pre-defined status codes when sending > a Close frame. > 1000 > 1000 indicates a normal closure, meaning whatever purpose the > connection was established for has been fulfilled. > 1001 > 1001 indicates that an endpoint is "going away", such as a server > going down, or a browser having navigated away from a page. > 1002 > 1002 indicates that an endpoint is terminating the connection due > to a protocol error. > 1003 > 1003 indicates that an endpoint is terminating the connection > because it has received a type of data it cannot accept (e.g. an > endpoint that understands only text data may send this if it > receives a binary message.) > 1004 > 1004 indicates that an endpoint is terminating the connection > because it has received a message that is too large. > 7.4.2. Reserved status code ranges > 0-999 > Status codes in the range 0-999 are not used. > 1000-1999 > Status codes in the range 1000-1999 are reserved for definition by > this protocol. > 2000-2999 > Status codes in the range 2000-2999 are reserved for use by > extensions. > 3000-3999 > Status codes in the range 3000-3999 MAY be used by libraries and > frameworks. The interpretation of these codes is undefined by > this protocol. End applications MUST NOT use status codes in this > range. > 4000-4999 > Status codes in the range 4000-4999 MAY be used by application > code. The interpretaion of these codes is undefined by this > protocol. > 8. Extensions > WebSocket clients MAY request extensions to this specification, and > WebSocket servers MAY accept some or all extensions requested by the > client. A server MUST NOT respond with any extension not requested > by the client. If extension parameters are included in negotiations > between the client and the server, those parameters MUST be chosen in > accordance with the specification of the extension to which the > parameters apply. > 8.1. Negotiating extensions > A client requests extensions by including a "Sec-WebSocket- > Extensions" header, which follows the normal rules for HTTP headers > (see [RFC2616] section 4.2) and the value of the header is defined by > the following ABNF: > extension-list = 1#extension > extension = extension-token *( ";" extension-param ) > extension-token = registered-token | private-use-token > registered-token = token > private-use-token = "x-" token > extension-param = token [ "=" ( token | quoted-string ) ] > Note that like other HTTP headers, this header may be split or > combined across multiple lines. Ergo, the following are equivalent: > Sec-WebSocket-Extensions: foo > Sec-WebSocket-Extensions: bar; baz=2 > is exactly equivalent to > Sec-WebSocket-Extensions: foo, bar; baz=2 > Any extension-token used must either be a registered token > (registration TBD), or have a prefix of "x-" to indicate a private- > use token. The parameters supplied with any given extension MUST be > defined for that extension. Note that the client is only offering to > use any advertised extensions, and MUST NOT use them unless the > server accepts the extension. > Note that the order of extensions is significant. Any interactions > between multiple extensions MAY be defined in the documents defining > the extensions. In the absence of such definition, the > interpretation is that the headers listed by the client in its > request represent a preference of the headers it wishes to use, with > the first options listed being most preferable. The extensions > listed by the server in response represent the extensions actually in > use. Should the extensions modify the data and/or framing, the order > of operations on the data should be assumed to be the same as the > order in which the extensions are listed in the server's response in > the opening handshake. > For example, if there are two extensions "foo" and "bar", if the > header |Sec-WebSocket-Extensions| sent by the server has the value > "foo, bar" then operations on the data will be made as > bar(foo(data)), be those changes to the data itself (such as > compression) or changes to the framing thay may "stack". > Non-normative examples of acceptable extension headers: > Sec-WebSocket-Extensions: deflate-stream > Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, > deflate-stream > Sec-WebSocket-Extensions: x-private-extension > A server accepts one or more extensions by including a |Sec- > WebSocket-Extensions| header containing one or more extensions which > were requested by the client. The interpretation of any extension > parameters, and what constitutes a valid response by a server to a > requested set of parameters by a client, will be defined by each such > extension. > 8.2. Known extensions > Extensions provide a mechanism for implementations to opt-in to > additional protocol features. This section defines the meaning of > well-known extensions but implementations may use extensions defined > separately as well. > 8.2.1. Compression > The registered extension token for this compression extension is > "deflate-stream". > The extension does not have any per message extension data and it > does not define the use of any WebSocket reserved bits or op codes. > Senders using this extension MUST apply RFC 1951 encodings to all > bytes of the data stream following the handshake including both data > and control messages. The data stream MAY include multiple blocks of > both compressed and uncompressed types as defined by RFC 1951. > [RFC1951] > Senders MUST NOT delay the transmission of any portion of a WebSocket > message because the deflate encoding of the message does not end on a > byte boundary. The encodings for adjacent messages MAY appear in the > same byte if no delay in transmission is occurred by doing so. > 9. Security considerations > While this protocol is intended to be used by scripts in Web pages, > it can also be used directly by hosts. Such hosts are acting on > their own behalf, and can therefore send fake "Origin" fields, > misleading the server. Servers should therefore be careful about > assuming that they are talking directly to scripts from known > origins, and must consider that they might be accessed in unexpected > ways. In particular, a server should not trust that any input is > valid. > EXAMPLE: For example, if the server uses input as part of SQL > queries, all input text should be escaped before being passed to the > SQL server, lest the server be susceptible to SQL injection. > Servers that are not intended to process input from any Web page but > only for certain sites should verify the "Origin" field is an origin > they expect, and should only respond with the corresponding "Sec- > WebSocket-Origin" if it is an accepted origin. Servers that only > accept input from one origin can just send back that value in the > "Sec-WebSocket-Origin" field, without bothering to check the client's > value. > > If at any time a server is faced with data that it does not > understand, or that violates some criteria by which the server > determines safety of input, or when the server sees a handshake that > does not correspond to the values the server is expecting (e.g. > incorrect path or origin), the server should just disconnect. It is > always safe to disconnect. > The biggest security risk when sending text data using this protocol > is sending data using the wrong encoding. If an attacker can trick > the server into sending data encoded as ISO-8859-1 verbatim (for > instance), rather than encoded as UTF-8, then the attacker could > inject arbitrary frames into the data stream. > In addition to endpoints being the target of attacks via WebSockets, > other parts of web infrastructure, such as proxies, may be the > subject of an attack. In particular, an intermediary may interpret a > WebSocket message from a client as a request, and a message from the > server as a response to that request. For instance, an attacker > could get a browser to establish a connection to its server, get the > browser to send a message that looks to an intermediary like a GET > request for a common piece of JavaScript on another domain, and send > back a message that is interpreted as a cacheable response to that > request, thus poisioning the cache for other users. To prevent this > attack, messages sent from clients are masked on the wire with a 32- > bit value, to prevent an attacker from controlling the bits on the > wire and thus lessen the probability of an attacker being able to > construct a message that can be misinterpreted by a proxy as a non- > WebSocket request. > 10. IANA considerations > 10.1. Registration of ws: scheme > A |ws:| URI identifies a WebSocket server and resource name. > URI scheme name. > ws > Status. > Permanent. > URI scheme syntax. > In ABNF terms using the terminals from the URI specifications: > [RFC5234] [RFC3986] > "ws" ":" hier-part [ "?" query ] > The path and query components form the resource name sent to the > server to identify the kind of service desired. Other components > have the meanings described in RFC3986. > URI scheme semantics. > The only operation for this scheme is to open a connection using > the WebSocket protocol. > Encoding considerations. > Characters in the host component that are excluded by the syntax > defined above must be converted from Unicode to ASCII by applying > the IDNA ToASCII algorithm to the Unicode host name, with both the > AllowUnassigned and UseSTD3ASCIIRules flags set, and using the > result of this algorithm as the host in the URI. [RFC3490] > Characters in other components that are excluded by the syntax > defined above must be converted from Unicode to ASCII by first > encoding the characters as UTF-8 and then replacing the > corresponding bytes using their percent-encoded form as defined in > the URI and IRI specification. [RFC3986] [RFC3987] > Applications/protocols that use this URI scheme name. > WebSocket protocol. > Interoperability considerations. > None. > Security considerations. > See "Security considerations" section above. > Contact. > Ian Hickson > Author/Change controller. > Ian Hickson > References. > This document. > 10.2. Registration of wss: scheme > A |wss:| URI identifies a WebSocket server and resource name, and > indicates that traffic over that connection is to be encrypted. > URI scheme name. > wss > Status. > Permanent. > URI scheme syntax. > In ABNF terms using the terminals from the URI specifications: > [RFC5234] [RFC3986] > "wss" ":" hier-part [ "?" query ] > The path and query components form the resource name sent to the > server to identify the kind of service desired. Other components > have the meanings described in RFC3986. > URI scheme semantics. > The only operation for this scheme is to open a connection using > the WebSocket protocol, encrypted using TLS. > Encoding considerations. > Characters in the host component that are excluded by the syntax > defined above must be converted from Unicode to ASCII by applying > the IDNA ToASCII algorithm to the Unicode host name, with both the > AllowUnassigned and UseSTD3ASCIIRules flags set, and using the > result of this algorithm as the host in the URI. [RFC3490] > Characters in other components that are excluded by the syntax > defined above must be converted from Unicode to ASCII by first > encoding the characters as UTF-8 and then replacing the > corresponding bytes using their percent-encoded form as defined in > the URI and IRI specification. [RFC3986] [RFC3987] > Applications/protocols that use this URI scheme name. > WebSocket protocol over TLS. > Interoperability considerations. > None. > Security considerations. > See "Security considerations" section above. > Contact. > Ian Hickson > Author/Change controller. > Ian Hickson > References. > This document. > 10.3. Registration of the "WebSocket" HTTP Upgrade keyword > Name of token. > WebSocket > Author/Change controller. > Ian Hickson > Contact. > Ian Hickson > References. > This document. > 10.4. Sec-WebSocket-Key > This section describes a header field for registration in the > Permanent Message Header Field Registry. [RFC3864] > Header field name > Sec-WebSocket-Key > Applicable protocol > http > Status > reserved; do not use outside WebSocket handshake > Author/Change controller > IETF > Specification document(s) > This document is the relevant specification. > Related information > None. > The |Sec-WebSocket-Key| header is used in the WebSocket handshake. > It is sent from the client to the server to provide part of the > information used by the server to prove that it received a valid > WebSocket handshake. This helps ensure that the server does not > accept connections from non-WebSocket clients (e.g. HTTP clients) > that are being abused to send data to unsuspecting WebSocket servers. > 10.5. Sec-WebSocket-Extensions > This section describes a header field for registration in the > Permanent Message Header Field Registry. [RFC3864] > Header field name > Sec-WebSocket-Extensions > Applicable protocol > http > Status > reserved; do not use outside WebSocket handshake > Author/Change controller > IETF > Specification document(s) > This document is the relevant specification. > Related information > None. > The |Sec-WebSocket-Extensions| header is used in the WebSocket > handshake. It is initially sent from the client to the server, and > then subsequently sent from the servver to the client, to agree on a > set of protocol-level extensions to use during the connection. > 10.6. Sec-WebSocket-Accept > This section describes a header field for registration in the > Permanent Message Header Field Registry. [RFC3864] > Header field name > Sec-WebSocket-Accept > Applicable protocol > http > Status > reserved; do not use outside WebSocket handshake > Author/Change controller > IETF > Specification document(s) > This document is the relevant specification. > Related information > None. > The |Sec-WebSocket-Accept| header is used in the WebSocket handshake. > It is sent from the server to the client to confirm that the server > is willing to initiate the connection. > 10.7. Sec-WebSocket-Origin > This section describes a header field for registration in the > Permanent Message Header Field Registry. [RFC3864] > Header field name > Sec-WebSocket-Origin > Applicable protocol > http > Status > reserved; do not use outside WebSocket handshake > Author/Change controller > IETF > Specification document(s) > This document is the relevant specification. > Related information > None. > The |Sec-WebSocket-Origin| header is used in the WebSocket handshake. > It is sent from the server to the client to confirm the origin of the > script that opened the connection. This enables user agents to > verify that the server is willing to serve the script that opened the > connection. > 10.8. Sec-WebSocket-Protocol > This section describes a header field for registration in the > Permanent Message Header Field Registry. [RFC3864] > Header field name > Sec-WebSocket-Protocol > Applicable protocol > http > Status > reserved; do not use outside WebSocket handshake > Author/Change controller > IETF > Specification document(s) > This document is the relevant specification. > Related information > None. > The |Sec-WebSocket-Protocol| header is used in the WebSocket > handshake. It is sent from the client to the server and back from > the server to the client to confirm the subprotocol of the > connection. This enables scripts to both select a subprotocol and be > sure that the server agreed to serve that subprotocol. > 10.9. Sec-WebSocket-Version > This section describes a header field for registration in the > Permanent Message Header Field Registry. [RFC3864] > Header field name > Sec-WebSocket-Version > Applicable protocol > http > Status > reserved; do not use outside WebSocket handshake > Author/Change controller > IETF > Specification document(s) > This document is the relevant specification. > Related information > None. > The |Sec-WebSocket-Version| header is used in the WebSocket > handshake. It is sent from the client to the server to indicate the > protocol version of the connection. This enables servers to > correctly interpret the handshake and subsequent data being sent from > the data, and close the connection if the server cannot interpret > that data in a safe manner. > 11. Using the WebSocket protocol from other specifications > The WebSocket protocol is intended to be used by another > specification to provide a generic mechanism for dynamic author- > defined content, e.g. in a specification defining a scripted API. > Such a specification first needs to "establish a WebSocket > connection", providing that algorithm with: > o The destination, consisting of a /host/ and a /port/. > o A /resource name/, which allows for multiple services to be > identified at one host and port. > o A /secure/ flag, which is true if the connection is to be > encrypted, and false otherwise. > o An ASCII serialization of an origin that is being made responsible > for the connection. [I-D.ietf-websec-origin] > o Optionally a string identifying a protocol that is to be layered > over the WebSocket connection. > The /host/, /port/, /resource name/, and /secure/ flag are usually > obtained from a URI using the steps to parse a WebSocket URI's > components. These steps fail if the URI does not specify a > WebSocket. > If a connection can be established, then it is said that the > "WebSocket connection is established". > If at any time the connection is to be closed, then the specification > needs to use the "close the WebSocket connection" algorithm. > When the connection is closed, for any reason including failure to > establish the connection in the first place, it is said that the > "WebSocket connection is closed". > While a connection is open, the specification will need to handle the > cases when "a WebSocket message has been received" with text /data/. > To send some text /data/ to an open connection, the specification > needs to "send /data/ using the WebSocket". -- Simon Pieters Opera Software From julian.reschke@gmx.de Mon Apr 4 06:05:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCA63A69EB for ; Mon, 4 Apr 2011 06:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 rYNz-OIQ7dTC for ; Mon, 4 Apr 2011 06:05:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 0F1D83A69EA for ; Mon, 4 Apr 2011 06:05:19 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2011 13:06:59 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.131]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 04 Apr 2011 15:06:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+usZY6Lheu4T895Vh66FJG9PdW8/8PKx3GPGul5U vvW2yQ4TzF4VFK Message-ID: <4D99C272.6070201@gmx.de> Date: Mon, 04 Apr 2011 15:06:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Simon Pieters References: 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] Opera's Pre-Last Call review of websocket -06 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, 04 Apr 2011 13:05:27 -0000 On 04.04.2011 14:42, Simon Pieters wrote: > ... >> The term "URI" is used in this section in a manner consistent with >> the terminology used in HTML, namely, to denote a string that might >> or might not be a valid URI or IRI and to which certain error >> handling behaviors will be applied when the string is parsed. >> [RFC3986] > > HTML calls it "URL", so doesn't seem particularly consistent. > ... All remaining references to how HTML5 uses URIs should simply be removed; including the specific text about parsing and resolving. > ... >> 6. Error Handling >> 6.1. Handling errors in UTF-8 from the server >> When a client is to interpret a byte stream as UTF-8 but finds that >> the byte stream is not in fact a valid UTF-8 stream, then any bytes >> or sequences of bytes that are not valid UTF-8 sequences must be >> interpreted as a U+FFFD REPLACEMENT CHARACTER. > > Maybe use the HTML spec's definition of UTF-8 with error handling: > http://www.whatwg.org/specs/web-apps/current-work/complete/infrastructure.html#decoded-as-utf-8,-with-error-handling I recommend avoiding any normative reference to HTML5. The text above appears to be simple enough standalone. > ... Best regards, Julian From salvatore.loreto@ericsson.com Mon Apr 4 06:21:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359A33A69F0 for ; Mon, 4 Apr 2011 06:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.003, 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 0VnAIidUJKY1 for ; Mon, 4 Apr 2011 06:21:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 292F13A693B for ; Mon, 4 Apr 2011 06:21:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-da-4d99c62902f2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.AA.11171.926C99D4; Mon, 4 Apr 2011 15:22:49 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Apr 2011 15:22:49 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5D0CA262C; Mon, 4 Apr 2011 16:22:49 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 558A0503B1; Mon, 4 Apr 2011 16:22:49 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F2F8E4F983; Mon, 4 Apr 2011 16:22:48 +0300 (EEST) Message-ID: <4D99C628.8090409@ericsson.com> Date: Mon, 4 Apr 2011 16:22:48 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------070206070101000207080104" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: SM Subject: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 13:21:17 -0000 --------------070206070101000207080104 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit (as HyBi wg co-chair) Hi there, Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed the masking issue. Based on that discussion, the decision is **only between two alternatives**: whether to (1) mask the entire frame, as in the current 06 spec, or to (2) mask only after the op codes and length. In the wire format for (1), the 32-bit masking-key appears first, and then the entire frame masked (as in 06): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | Masking-key | +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|R| Payload len | Extended payload length | |I|S|S|S| (4) |S| (7) | (16/63) | |N|V|V|V| |V| | (if payload len==126/127) | | |1|2|3| |4| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | | Extension data | +-------------------------------+ - - - - - - - - - - - - - - - + : : +---------------------------------------------------------------+ : Application data : +---------------------------------------------------------------+ In the wire format for (2), the masking-key appears after the op codes and length fields. This is where 06 shows the "Extension data". The extension data and the rest of the frame would be shifted 32 bits and it would all be masked. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|R| Payload len | Extended payload length | |I|S|S|S| (4) |S| (7) | (16/63) | |N|V|V|V| |V| | (if payload len==126/127) | | |1|2|3| |4| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | | Masking-key | +---------------------------------------------------------------+ | Masking-key (continued) | Extension data | +-------------------------------+ - - - - - - - - - - - - - - - + : : +---------------------------------------------------------------+ : Application data : +---------------------------------------------------------------+ In both cases, everything after the Masking-key is masked. Several folks have already expressed themselves on this issue either recently on the mailing list, or in person at the IETF meeting this week. Gabriel and I, as HyBi wg chairs, would like to solicit only those who have not yet expressed themselves on this issue, to do so now. We will wait for additional feedback **until Friday April 8**, and based on the feedback will make a decision shortly afterward. cheers /Sal -- Salvatore Loreto www.sloreto.com --------------070206070101000207080104 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit (as HyBi wg co-chair)


Hi there,

Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed the masking issue.

Based on that discussion, the decision is *only between two alternatives*:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.
 
In the wire format for (1), the 32-bit masking-key appears first, and then the entire frame masked (as in 06):
 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------------------------------------------------------+
     |                       Masking-key                             |
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|R| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
     |N|V|V|V|       |V|             |   (if payload len==126/127)   |
     | |1|2|3|       |4|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |         Extension data        |
     +-------------------------------+ - - - - - - - - - - - - - - - +
     :                                                               :
     +---------------------------------------------------------------+
     :                       Application data                        :
     +---------------------------------------------------------------+
 
 
In the wire format for (2), the masking-key appears after the op codes and length fields.
This is where 06 shows the "Extension data". The extension data and the rest of the frame would be shifted 32 bits and it would all be masked.
 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|R| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
     |N|V|V|V|       |V|             |   (if payload len==126/127)   |
     | |1|2|3|       |4|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |         Masking-key           |
    +---------------------------------------------------------------+
     |    Masking-key (continued)    |         Extension data        |
     +-------------------------------+ - - - - - - - - - - - - - - - +
     :                                                               :
     +---------------------------------------------------------------+
     :                       Application data                        :
     +---------------------------------------------------------------+
 
In both cases, everything after the Masking-key is masked.
 
Several folks have already expressed themselves on this issue either recently on the mailing list, or in person at the IETF meeting this week.
 
Gabriel and I, as HyBi wg chairs, would like to solicit only those who have not yet expressed themselves on this issue, to do so now. 

We will wait for additional feedback *until Friday April 8*, and based on the feedback will make a decision shortly afterward.

cheers
/Sal
 
-- 
Salvatore Loreto
www.sloreto.com
--------------070206070101000207080104-- From dendicott@gmail.com Mon Apr 4 06:42:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CED43A69F1 for ; Mon, 4 Apr 2011 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl-ksMDtjdYz for ; Mon, 4 Apr 2011 06:42:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0359B3A69F0 for ; Mon, 4 Apr 2011 06:42:24 -0700 (PDT) Received: by wwa36 with SMTP id 36so4492520wwa.13 for ; Mon, 04 Apr 2011 06:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HGzfbPGIZOK4Qvs5s8OL7T9CIhZW8VsiGVSbnqUgTwk=; b=xbU7GJQh49idO1P0fAsLV3e7u3Ckj8dNFMEu3aYujWxkOfYdMU055ajuMN3vQsv4ql 1CK416L04akIvYfnoMzztLnJPP59OvsMuR32Nyoyzqy2Fgp+EuSAnI7ikh+d4iWcyTEX mkO/SFziLfmHxsE3VwEnuTIin9eQEvCpjKRO8= 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=jw3GmafgsAJLT5aBAZaDIXTNLZQTwyJ4Az9BD67WCD50kHb8DaeQhF8m0rDVxyPIEC Zo/ZNOHUerNfHK+8h9H9NMK/z+6pe14LLh2nh9BaMkffC0DGD66RXh3XVesjGELt5d4X gWMfPJr5cUW92669BFvOZpDB3vxY8tE608d5Y= MIME-Version: 1.0 Received: by 10.216.65.142 with SMTP id f14mr803399wed.2.1301924646872; Mon, 04 Apr 2011 06:44:06 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Mon, 4 Apr 2011 06:44:06 -0700 (PDT) In-Reply-To: <4D989FC5.4090407@warmcat.com> References: <4D989304.9080802@warmcat.com> <4D989FC5.4090407@warmcat.com> Date: Mon, 4 Apr 2011 09:44:06 -0400 Message-ID: From: David Endicott To: Andy Green Content-Type: multipart/alternative; boundary=000e0cdf8db019eabe04a017f4df Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 04 Apr 2011 13:42:26 -0000 --000e0cdf8db019eabe04a017f4df Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 3, 2011 at 12:26 PM, Andy Green wrote: > On 04/03/2011 04:44 PM, Somebody in the thread at some point said: > >> 2011/4/3 Andy Green: >> >>> Unfortunatelly I think it's too late for a new approach of the >>>> WebSocket protocol, even if it would be really a much better design >>>> (IMHO). >>>> >>> >>> It's not any new approach, you're just suggesting splitting off the >>> handshake and the websocket transport definition into separate documents. >>> The end result is the same, who cares. >>> >> >> Instead of a HTTP handshake, I just suggest (as the first mail in this >> thread) the usage of a Websocket control frame to establish the WS >> "connection". >> > > I assume this means running websocket on a different port altogether then. > > To clarify: No. I was only suggesting that WebSocket be divorced from HTTP Upgrade as part of the specification. Yes, I think in many many cases people will use HTTP Upgrade as the gateway to establishing a WS connection. That makes good sense for many environments. There are many good reasons to provide it over standard HTTP ports. But, there are also many good reasons to not *insist* that it is done that way. I don't believe WS is a sub-set of HTTP. WS is a different transport than HTTP and there are (should be) numerous other ways to get it connected. Many of us have deployment situations where the firewall situation isn't a concern and we already have customers opening specific ports for us. I perceive HTTP and WS as apples and oranges^H^H^H^H pork chops...they work well together but are different entities. --000e0cdf8db019eabe04a017f4df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Apr 3, 2011 at 12:26 PM, Andy Gr= een <andy@warmcat.= com> wrote:
On 04/03/2011 04:44 PM, Somebody in the t= hread at some point said:
2011/4/3 Andy Green<andy@warmcat.com>:
Unfortunatelly I think it's too late for a new approach of the
WebSocket protocol, even if it would be really a much better design
(IMHO).

It's not any new approach, you're just suggesting splitting off the=
handshake and the websocket transport definition into separate documents. =A0The end result is the same, who cares.

Instead of a HTTP handshake, I just suggest (as the first mail in this
thread) the usage of a Websocket control frame to establish the WS
"connection".

I assume this means running websocket on a different port altogether then.<= br>


To clarify: =A0No. =A0 = I was only suggesting that WebSocket be divorced from HTTP Upgrade as part = of the=A0specification. =A0=A0

Yes, I think in man= y many cases people will use HTTP Upgrade as the gateway to establishing a = WS connection. =A0That makes good sense for many=A0environments. =A0 There = are many good reasons to provide it over standard HTTP ports.

But, there are also many good reasons to not *insist* t= hat it is done that way. =A0 =A0I don't believe WS is a sub-set of HTTP= . =A0 WS is a different transport than HTTP and there are (should be) numer= ous other ways to get it connected. =A0 =A0Many of us have deployment situa= tions where the firewall situation isn't a concern and we already have = customers opening specific ports for us. =A0=A0

I perceive HTTP and WS as apples and oranges^H^H^H^H po= rk chops...they work well together but are different entities. =A0=A0
=


--000e0cdf8db019eabe04a017f4df-- From dendicott@gmail.com Mon Apr 4 06:48:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5806828C118 for ; Mon, 4 Apr 2011 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VntUo+KNmAj for ; Mon, 4 Apr 2011 06:48:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 441C128C100 for ; Mon, 4 Apr 2011 06:48:12 -0700 (PDT) Received: by wyb29 with SMTP id 29so5265368wyb.31 for ; Mon, 04 Apr 2011 06:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m9Gc5DmRRpquKnHlHqWvlW6kpYFsnT+R3Bz7BvPjaGI=; b=cDMOhL+ecJ216G4Ys16uEJ3bFoxhoD2pNyVyWqEj+H5rrqKLTwMlsBLdiAReqGEHOb W+0PMDVh8mrnIUTMdl+Rsfa9YsvdnjemDAyFOgwAMpDh0QtKGWYPijI7yUv3p+fCydYK amyHMBy/DQ8JFl6X4cpg8PbfRAdqrQXadHd2c= 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=ZCjy80LStea0IQ6dRnd+h4h8P0XeTRLV9rqvcJaB4HfkjcHIIgICx66IVvWutLSo2X 5owMOddV6TkyHVK28/tW2GlAmkmn6x64WfmcLRSyUI2qsRPgg7aQvclMsBGdoYWywPF1 mJYk56DOlv/EAXIA8Wje2l1NY6tbbHjKn/ahU= MIME-Version: 1.0 Received: by 10.216.168.82 with SMTP id j60mr3895284wel.47.1301924993871; Mon, 04 Apr 2011 06:49:53 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Mon, 4 Apr 2011 06:49:53 -0700 (PDT) In-Reply-To: <4D99C628.8090409@ericsson.com> References: <4D99C628.8090409@ericsson.com> Date: Mon, 4 Apr 2011 09:49:53 -0400 Message-ID: From: David Endicott To: Salvatore Loreto Content-Type: multipart/alternative; boundary=0016e65b40e0c8b10404a0180821 Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 13:48:20 -0000 --0016e65b40e0c8b10404a0180821 Content-Type: text/plain; charset=ISO-8859-1 To be officially on record: +1 for alternative: (2) mask only after the op codes and length. On Mon, Apr 4, 2011 at 9:22 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > (as HyBi wg co-chair) > > > Hi there, > > Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed > the masking issue. > > Based on that discussion, the decision is **only between two alternatives* > *: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. > > In the wire format for (1), the 32-bit masking-key appears first, and then > the entire frame masked (as in 06): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------------------------------------------------------+ > | Masking-key | > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|R| Payload len | Extended payload length | > |I|S|S|S| (4) |S| (7) | (16/63) | > |N|V|V|V| |V| | (if payload len==126/127) | > | |1|2|3| |4| | | > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > | Extended payload length continued, if payload len == 127 | > + - - - - - - - - - - - - - - - +-------------------------------+ > | | Extension data | > +-------------------------------+ - - - - - - - - - - - - - - - + > : : > +---------------------------------------------------------------+ > : Application data : > +---------------------------------------------------------------+ > > > In the wire format for (2), the masking-key appears after the op codes and > length fields. > This is where 06 shows the "Extension data". The extension data and the > rest of the frame would be shifted 32 bits and it would all be masked. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|R| Payload len | Extended payload length | > |I|S|S|S| (4) |S| (7) | (16/63) | > |N|V|V|V| |V| | (if payload len==126/127) | > | |1|2|3| |4| | | > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > | Extended payload length continued, if payload len == 127 | > + - - - - - - - - - - - - - - - +-------------------------------+ > | | Masking-key | > +---------------------------------------------------------------+ > | Masking-key (continued) | Extension data | > +-------------------------------+ - - - - - - - - - - - - - - - + > : : > +---------------------------------------------------------------+ > : Application data : > +---------------------------------------------------------------+ > > In both cases, everything after the Masking-key is masked. > > Several folks have already expressed themselves on this issue either > recently on the mailing list, or in person at the IETF meeting this week. > > Gabriel and I, as HyBi wg chairs, would like to solicit only those who have > not yet expressed themselves on this issue, to do so now. > > We will wait for additional feedback **until Friday April 8**, and based > on the feedback will make a decision shortly afterward. > > cheers > /Sal > > -- > Salvatore Loretowww.sloreto.com > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --0016e65b40e0c8b10404a0180821 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To be officially on record:

+1 =A0for alternative: =A0(2) mask only after the op codes a= nd length.=A0



On Mon, Apr 4,= 2011 at 9:22 AM, Salvatore Loreto <salvatore.loreto@ericsson.com>= wrote:
=20 =20 =20
(as HyBi wg co-chair)


Hi there,

Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed the masking issue.

Based on that discussion, the decision is *only between two alternatives*:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.
=A0
In the wire format for (1), the 32-bit masking-key appears first, and then the entire frame masked (as in 06):
=A0
=A0= =A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 3
=A0= =A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
=A0= =A0=A0=A0 +---------------------------------------------------------------+
=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M= asking-key=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0|
=A0= =A0=A0=A0 +-+-+-+-+-------+-+-------------+-------------------------------+
=A0= =A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Extended payload length=A0= =A0=A0 |
=A0= =A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 (16/63)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0= =A0=A0=A0 |N|V|V|V| =A0=A0=A0=A0=A0=A0|V|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0=A0 (if payload len=3D=3D126/127)=A0=A0 |
=A0= =A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |
=A0= =A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
=A0= =A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued, if payload len =3D= =3D 127=A0 |
=A0= =A0=A0=A0 + - - - - - - - - - - - - - - - +-------------------------------+
=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Extension data=A0=A0=A0= =A0=A0=A0=A0 |
=A0= =A0=A0=A0 +-------------------------------+ - - - - - - - - - - - - - - - +
=A0= =A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:
=A0= =A0=A0=A0 +---------------------------------------------------------------+
=A0= =A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A= pplication data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 :
=A0= =A0=A0=A0 +---------------------------------------------------------------+
=A0
=A0
In the wire format for (2), the masking-key appears after the op codes and length fields.
This is where 06 shows the "Extension data". The extension = data and the rest of the frame would be shifted 32 bits and it would all be masked.
=A0
=A0= =A0=A0=A0=A0 0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A01=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 3
=A0= =A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
=A0= =A0=A0=A0 +-+-+-+-+-------+-+-------------+-------------------------------+
=A0= =A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Extended payload length=A0= =A0=A0 |
=A0= =A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 (16/63)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0= =A0=A0=A0 |N|V|V|V|=A0=A0=A0=A0=A0=A0 |V|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0=A0 (if payload len=3D=3D126/127)=A0=A0 |
=A0= =A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |
=A0= =A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
=A0= =A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued, if payload len =3D= =3D 127=A0 |
=A0= =A0=A0=A0 + - - - - - - - - - - - - - - - +-------------------------------+
=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Masking-key=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |
=A0= =A0=A0=A0+---------------------------------------------------------------+<= /span>
=A0= =A0=A0=A0 |=A0=A0=A0 Masking-key (continued)=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= Extension data=A0=A0=A0=A0=A0=A0=A0 |
=A0= =A0=A0=A0 +-------------------------------+ - - - - - - - - - - - - - - - +
=A0= =A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:
=A0= =A0=A0=A0 +---------------------------------------------------------------+
=A0= =A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A= pplication data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 :
=A0= =A0=A0=A0 +---------------------------------------------------------------+
=A0
In both cases, everything after the Masking-key is masked.
=A0
Several folks have already expressed themselves on this issue either recently on the mailing list, or in person at the IETF meeting this week.
=A0
Gabriel and I, as HyBi wg chairs, would like to solicit only those who have not yet expressed themselves on this issue, to do so now.=A0

We will wait for additional feedback *until Friday April 8*, and based on the feedback will make a decision shortly afterward.

cheers
/Sal
 
--=20
Salvatore Loreto
www.sloreto.com

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


--0016e65b40e0c8b10404a0180821-- From godjonez@codepad.info Mon Apr 4 08:37:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD9128C12E for ; Mon, 4 Apr 2011 08:37:53 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKZys76F+RGC for ; Mon, 4 Apr 2011 08:37:52 -0700 (PDT) Received: from smtpout.kotinet.com (smtpout.kotinet.com [212.50.215.76]) by core3.amsl.com (Postfix) with ESMTP id 7ECB528C100 for ; Mon, 4 Apr 2011 08:37:52 -0700 (PDT) Received: from codepad.info (codepad.info [62.240.71.135]) by smtpout.kotinet.com (Postfix) with ESMTP id 9BB0E479F8; Mon, 4 Apr 2011 18:39:33 +0300 (EEST) Received: from overwatchnexus.combinet (overwatchnexus.combinet [192.168.2.7]) by codepad.info (Postfix) with ESMTPSA id F2C916400FA; Mon, 4 Apr 2011 18:39:32 +0300 (EEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "hybi@ietf.org" , "Salvatore Loreto" References: <4D99C628.8090409@ericsson.com> Date: Mon, 04 Apr 2011 18:39:33 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Joonas Lehtolahti" Message-ID: In-Reply-To: <4D99C628.8090409@ericsson.com> User-Agent: Opera Mail/11.10 (Win32) Cc: SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 15:37:53 -0000 Personally I can live with either approach but I have preference for format (2). Cheers, Joonas On Mon, 04 Apr 2011 16:22:48 +0300, Salvatore Loreto wrote: > (as HyBi wg co-chair) > > > Hi there, > > Last Tuesday, during the HyBi wg session at the IETF meeting, we > discussed the masking issue. > > Based on that discussion, the decision is **only between two > alternatives**: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. From jat@google.com Mon Apr 4 08:41:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B6428C137 for ; Mon, 4 Apr 2011 08:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.846 X-Spam-Level: X-Spam-Status: No, score=-105.846 tagged_above=-999 required=5 tests=[AWL=0.130, 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 8QBo-bCHTDKm for ; Mon, 4 Apr 2011 08:41:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5AEBB28C135 for ; Mon, 4 Apr 2011 08:41:35 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p34FhGJE021861 for ; Mon, 4 Apr 2011 08:43:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301931797; bh=NHPv9kTJssU8vrlvoHKmWcDSjLE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=OrbVBmEpjgxRr+4+jcx4mlyXoHvx3mQQLMfjSZL9K2jTdJru8qwylZBu7IdHwl1Va +3uGCzlt3QVCsybJDoDgg== Received: from yxe1 (yxe1.prod.google.com [10.190.2.1]) by hpaq6.eem.corp.google.com with ESMTP id p34FhB2C016982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 08:43:12 -0700 Received: by yxe1 with SMTP id 1so5059903yxe.25 for ; Mon, 04 Apr 2011 08:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CvBymCXu4JOrmu74IWv6aRue/XBQaaGuXl3nQtGMe98=; b=jRmG3knp8v/Z+RnnfSbPNSlQmuiPrjIG+liuvbYFY7FPl2Zs6S+1Xj/Pq+gf5g5EI3 c3sI7tN/NnCanasfBM8g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=vSMlkRgSP+3X9VbBNKEvfqIiOeMib03kElX4LqedsWavxBlQC/tQTkbS+PVYCsvKbX xh+DPMONjqczlMPQetjw== Received: by 10.150.61.9 with SMTP id j9mr6916148yba.238.1301931791103; Mon, 04 Apr 2011 08:43:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Mon, 4 Apr 2011 08:42:51 -0700 (PDT) In-Reply-To: <4D99C628.8090409@ericsson.com> References: <4D99C628.8090409@ericsson.com> From: John Tamplin Date: Mon, 4 Apr 2011 11:42:51 -0400 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=000e0cd4c0e0ee36ae04a0199dbc X-System-Of-Record: true Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 15:41:37 -0000 --000e0cd4c0e0ee36ae04a0199dbc Content-Type: text/plain; charset=UTF-8 > > Based on that discussion, the decision is **only between two alternatives* > *: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. > I personally am fine with either - to me the pros and cons for either option seem balanced. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4c0e0ee36ae04a0199dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on that disc= ussion, the decision is *only between two alternatives*:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.

I personally am fine with either - to me the pro= s and cons for either option seem balanced.=C2=A0

--
Joh= n A. Tamplin
Software Engineer (GWT), Google
--000e0cd4c0e0ee36ae04a0199dbc-- From julian.reschke@gmx.de Mon Apr 4 09:19:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D13F28C104 for ; Mon, 4 Apr 2011 09:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=-2.371, BAYES_40=-0.185, 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 IenzwTcmvSri for ; Mon, 4 Apr 2011 09:19:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id EF93A3A6843 for ; Mon, 4 Apr 2011 09:19:40 -0700 (PDT) Received: (qmail invoked by alias); 04 Apr 2011 16:21:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.131]) [217.91.35.233] by mail.gmx.net (mp065) with SMTP; 04 Apr 2011 18:21:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+YCRQ3lJSYQR+Pi9vmrfbVmZcYgi/2PDacNa7PTX uWDJBX4K3A6Mow Message-ID: <4D99F000.8090001@gmx.de> Date: Mon, 04 Apr 2011 18:21:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [hybi] Robert Gezelter on the current spec 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, 04 Apr 2011 16:19:51 -0000 FYI: http://www.rlgsc.com/blog/ruminations/websocket-rediscovered-travails.html From ferg@caucho.com Mon Apr 4 09:30:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7333A69C8 for ; Mon, 4 Apr 2011 09:30:34 -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=[AWL=0.000, 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 tpHyAIGw9xEs for ; Mon, 4 Apr 2011 09:30:22 -0700 (PDT) Received: from nm17-vm0.bullet.mail.bf1.yahoo.com (nm17-vm0.bullet.mail.bf1.yahoo.com [98.139.213.157]) by core3.amsl.com (Postfix) with SMTP id 5831A28C118 for ; Mon, 4 Apr 2011 09:30:21 -0700 (PDT) Received: from [98.139.212.153] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2011 16:32:00 -0000 Received: from [98.139.212.240] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 04 Apr 2011 16:32:00 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 04 Apr 2011 16:32:00 -0000 X-Yahoo-Newman-Id: 803752.15454.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 32901 invoked from network); 4 Apr 2011 16:32:00 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp105.biz.mail.bf1.yahoo.com with SMTP; 04 Apr 2011 09:32:00 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: tkDcoCQVM1kgOwmJBPQt_K21_9hhPhVfBLrmuC.LsIb0Q11 .U2mOCijbPZG0VBp6PL8cf.WgczleTC145n.cAC6LrgnphNIZCwTr6Dxb5az bV7BVmNziRItChJ1MFJYxfemYh.qmq9YqXekeP42U2jnrKxUciLdjcsbfz7f xzkQu.aTOqdqQvx58kinO0z1PJV9eyi258A692PxrOxp3033f0v59I5sD0h0 JXRKNtp_jvBgPiTN559RS8hsY7pXnyvuPIg3ncpT6VDGP5m8s0Aar4sxH08f 26ymTaJxYEJhGH6k_MRzA X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D99F275.40303@caucho.com> Date: Mon, 04 Apr 2011 09:31:49 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D99C628.8090409@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 16:30:35 -0000 On 04/04/2011 08:39 AM, Joonas Lehtolahti wrote: > Personally I can live with either approach but I have preference for > format (2). +1 same here -- Scott > > Cheers, > > Joonas > > > On Mon, 04 Apr 2011 16:22:48 +0300, Salvatore Loreto > wrote: > >> (as HyBi wg co-chair) >> >> >> Hi there, >> >> Last Tuesday, during the HyBi wg session at the IETF meeting, we >> discussed the masking issue. >> >> Based on that discussion, the decision is **only between two >> alternatives**: >> whether to (1) mask the entire frame, as in the current 06 spec, >> or to (2) mask only after the op codes and length. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > From w@1wt.eu Mon Apr 4 11:24:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A433A63D2 for ; Mon, 4 Apr 2011 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 aMf5qZO5UxY5 for ; Mon, 4 Apr 2011 11:24:48 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 34C863A63CB for ; Mon, 4 Apr 2011 11:24:47 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p34IQPrq020896; Mon, 4 Apr 2011 20:26:25 +0200 Date: Mon, 4 Apr 2011 20:26:25 +0200 From: Willy Tarreau To: Julian Reschke Message-ID: <20110404182625.GD20671@1wt.eu> References: <4D99F000.8090001@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D99F000.8090001@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 04 Apr 2011 18:24:49 -0000 On Mon, Apr 04, 2011 at 06:21:20PM +0200, Julian Reschke wrote: > FYI: > http://www.rlgsc.com/blog/ruminations/websocket-rediscovered-travails.html Interesting. The guy did not understand all the goals which led to the current draft, reason why I'm regularly repeating that points that look strange must be at least argumented a bit, otherwise people will poorly deal with them instead of getting the right thing. It seems the guy did not understand the goal of the closing handshake. He understood that it was in order to replace the TCP closing handshake while the real goal was to let the remote side know if the close was expected or not (TCP close without WS close indicates it comes from an intermediary, and automatic reconnection might be desirable in some cases). He makes some points about the text/binary distinction. I remember we had valid reasons for this, which apparently became unclear to some people with time since I don't clearly remember all the use cases now. He came to the conclusion that we need multiplexing, fortunately we left provisions for that, too bad we never reached the point we can implement it, as I think it will appear by itself and we'll have to retro-document it later. His pause/resume mechanism is what I normally call flow control. It might be nice to study the idea, though it can have huge security impacts as it has on Ethernet and TCP (easy DoSes). The guy is apparently not used to TCP, as he believes that it's not possible to open more than 64k connections on a machine due to the 16-bit port numbering, as he assumes a 1:1 socket-port relation. Fortunately this is not true, or the internet would be much more congested ! Not only does the server run all its incoming sockets on one port, but even the clients can initiate more than 64k sockets from less than 64k ports! FTP servers open all their data connections from the same port 20 ;-) Nevertheless, the fact that people start reviewing the whole draft and publicly post their comments and feelings is a sign that we're on the last mile and that the protocol is starting to drain interest. Regards, Willy From w@1wt.eu Mon Apr 4 11:25:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8261C3A63EC for ; Mon, 4 Apr 2011 11:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-1.515, BAYES_20=-0.74, 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 niEJmPqJvrsh for ; Mon, 4 Apr 2011 11:25:42 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id B33933A63D2 for ; Mon, 4 Apr 2011 11:25:41 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p34IRM45020906; Mon, 4 Apr 2011 20:27:22 +0200 Date: Mon, 4 Apr 2011 20:27:22 +0200 From: Willy Tarreau To: Scott Ferguson Message-ID: <20110404182722.GE20671@1wt.eu> References: <4D99C628.8090409@ericsson.com> <4D99F275.40303@caucho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D99F275.40303@caucho.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 18:25:42 -0000 On Mon, Apr 04, 2011 at 09:31:49AM -0700, Scott Ferguson wrote: > On 04/04/2011 08:39 AM, Joonas Lehtolahti wrote: > >Personally I can live with either approach but I have preference for > >format (2). > > +1 > > same here +1 same here too. Willy From jat@google.com Mon Apr 4 11:48:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F1A3A66B4 for ; Mon, 4 Apr 2011 11:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.127, 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 6rNlh9IPV3Ef for ; Mon, 4 Apr 2011 11:48:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A4B3D3A659C for ; Mon, 4 Apr 2011 11:48:19 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p34Io0Eb008395 for ; Mon, 4 Apr 2011 11:50:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301943001; bh=tpco4aG1o0XjZalbGQAxHpdVpQM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cTMwmSXdPo0r5+uhyYXJaR8eev0obeIxpQm7bPZ2rxDi5tA3O/C65nhURtCwHYBRR oYi6HD4um3He5JSvkWC1g== Received: from gyd8 (gyd8.prod.google.com [10.243.49.200]) by wpaz13.hot.corp.google.com with ESMTP id p34Inv3k020940 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 11:49:59 -0700 Received: by gyd8 with SMTP id 8so2561617gyd.28 for ; Mon, 04 Apr 2011 11:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=y3fE4NRRktnobYjQ61j1Q1iPxhxwxP8Y9aBz2tJKXqM=; b=LQeswb5Edij/w7iz0Zq4MfJn9mHp5NWr3sZ+NSJltTEXKUkgyhfyN45dyvJsePRId4 +rOK0XRPYtXGbcTEguCA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=COLJFPoCRvFo5ImUwqb0CBgssaRDE8HzJCpvcWmonjXJcWSCNBocWKsts7qV0Pju94 Y0IPmPHIFAV9/O7Mp+qA== Received: by 10.150.69.30 with SMTP id r30mr2854372yba.124.1301942999211; Mon, 04 Apr 2011 11:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Mon, 4 Apr 2011 11:49:39 -0700 (PDT) In-Reply-To: <20110404182625.GD20671@1wt.eu> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> From: John Tamplin Date: Mon, 4 Apr 2011 14:49:39 -0400 Message-ID: To: Willy Tarreau Content-Type: multipart/alternative; boundary=000e0cd59196fc60ea04a01c39b4 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 04 Apr 2011 18:48:21 -0000 --000e0cd59196fc60ea04a01c39b4 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2011 at 2:26 PM, Willy Tarreau wrote: > He came to the conclusion that we need multiplexing, fortunately we left > provisions for that, too bad we never reached the point we can implement > it, > as I think it will appear by itself and we'll have to retro-document it > later. > There seemed to be plenty of people that didn't want the complication of multiplexing in the base spec, there were disagreements over exactly how it should be implemented, and we made sure the extensions mechanisms was sufficient to implement multiplexing as an extension. I am working on a multiplexing extension that I hope to have a sample implementation for in the next week or two -- email me offlist if you are interested in participating. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd59196fc60ea04a01c39b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2011 at 2:26 PM, Willy Tarreau <w@1wt.eu> wro= te:
He came to the conclusion that we need multiplexing, fort= unately we left
provisions for that, too bad we never reached the point we can implement it= ,
as I think it will appear by itself and we'll have to retro-document it= later.

There seemed to be plenty= of people that didn't want the complication of multiplexing in the bas= e spec, there were disagreements over exactly how it should be implemented,= and we made sure the extensions mechanisms was sufficient to implement mul= tiplexing as an extension.

I am working on a multiplexing extension that I hope to= have a sample implementation for in the next week or two -- email me offli= st if you are interested in participating.

--
John A. Tamplin<= br> Software Engineer (GWT), Google
--000e0cd59196fc60ea04a01c39b4-- From andy.warmcat.com@googlemail.com Mon Apr 4 12:08:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E936B3A67A2 for ; Mon, 4 Apr 2011 12:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbR0WrnBytoF for ; Mon, 4 Apr 2011 12:08:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D72613A6452 for ; Mon, 4 Apr 2011 12:08:03 -0700 (PDT) Received: by wwa36 with SMTP id 36so4757988wwa.13 for ; Mon, 04 Apr 2011 12:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=It8/jXsHAK8aqz0dJBYo1i5TbV+WnqDu5ER3hg2GfEc=; b=vpIrTr1zuk5euWbW6xjAtIO+BNY2XWgiJ8olA/bgcLmaEodIzJuFeXC05NtMVtUefp 15IAsR6aqaD/Fu8EPUOFEu4ST1iM8Pm53yJYz9DgXgwWIXANLSnYQKi12nKpWgYRZi57 6SYFJQVA5uHF80jus0EuMm85sgf3MVh8i8vsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VT2ogpqrcdJIFoGZdN6Wd6hZBp61pxYe9rD5wiSc9qhkVubthqqrzeZIm1tkoG/V11 sugi8ntoP6uNmJdyUBOFxYXuo9FsCWb2uq4ZLb5LqLq/CZOhS8lvYV5Zs3wVoyKLSYJx 1B/o5DWkV7k7qlFBn5z6APyD57kbEGlFRo1Gw= Received: by 10.227.100.212 with SMTP id z20mr7852791wbn.27.1301944185115; Mon, 04 Apr 2011 12:09:45 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id e13sm3088596wbi.57.2011.04.04.12.09.42 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:09:43 -0700 (PDT) Sender: Andy Green Message-ID: <4D9A1775.9090602@warmcat.com> Date: Mon, 04 Apr 2011 20:09:41 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Tamplin References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 04 Apr 2011 19:08:05 -0000 On 04/04/2011 07:49 PM, Somebody in the thread at some point said: > On Mon, Apr 4, 2011 at 2:26 PM, Willy Tarreau > wrote: > > He came to the conclusion that we need multiplexing, fortunately we left > provisions for that, too bad we never reached the point we can > implement it, > as I think it will appear by itself and we'll have to retro-document > it later. > > > There seemed to be plenty of people that didn't want the complication of > multiplexing in the base spec, there were disagreements over exactly how > it should be implemented, and we made sure the extensions mechanisms was > sufficient to implement multiplexing as an extension. > > I am working on a multiplexing extension that I hope to have a sample > implementation for in the next week or two -- email me offlist if you > are interested in participating. FWIW I am halfway through a libwebsockets implementation too based on John's draft. -Andy From w@1wt.eu Mon Apr 4 12:27:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E8B3A67AA for ; Mon, 4 Apr 2011 12:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.563, 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 SnQp84E1rfPG for ; Mon, 4 Apr 2011 12:27:27 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id B53403A67A8 for ; Mon, 4 Apr 2011 12:27:26 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p34JT0lI021315; Mon, 4 Apr 2011 21:29:00 +0200 Date: Mon, 4 Apr 2011 21:29:00 +0200 From: Willy Tarreau To: Andy Green Message-ID: <20110404192900.GA21300@1wt.eu> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <4D9A1775.9090602@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9A1775.9090602@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 04 Apr 2011 19:27:27 -0000 Hi guys, On Mon, Apr 04, 2011 at 08:09:41PM +0100, Andy Green wrote: > On 04/04/2011 07:49 PM, Somebody in the thread at some point said: > >On Mon, Apr 4, 2011 at 2:26 PM, Willy Tarreau >> wrote: > > > > He came to the conclusion that we need multiplexing, fortunately we > > left > > provisions for that, too bad we never reached the point we can > > implement it, > > as I think it will appear by itself and we'll have to retro-document > > it later. > > > > > >There seemed to be plenty of people that didn't want the complication of > >multiplexing in the base spec, there were disagreements over exactly how > >it should be implemented, and we made sure the extensions mechanisms was > >sufficient to implement multiplexing as an extension. > > > >I am working on a multiplexing extension that I hope to have a sample > >implementation for in the next week or two -- email me offlist if you > >are interested in participating. > > FWIW I am halfway through a libwebsockets implementation too based on > John's draft. That's excellent news! I really don't have time to spend on this unfortunately, still I'm interested in putting my nose on whatever you'll publish ! Cheers, Willy From dave@cridland.net Mon Apr 4 13:30:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E48C28C0E5 for ; Mon, 4 Apr 2011 13:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.286, 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 GWqWRFbtanSn for ; Mon, 4 Apr 2011 13:30:01 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 0714228C0E2 for ; Mon, 4 Apr 2011 13:30:01 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 0070C116808D; Mon, 4 Apr 2011 21:31:40 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fscpjQSpP1yL; Mon, 4 Apr 2011 21:31:37 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 380161168067; Mon, 4 Apr 2011 21:31:37 +0100 (BST) References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> In-Reply-To: <20110404182625.GD20671@1wt.eu> MIME-Version: 1.0 Message-Id: <15466.1301949097.229241@puncture> Date: Mon, 04 Apr 2011 21:31:37 +0100 From: Dave Cridland To: Willy Tarreau , Server-Initiated HTTP , Julian Reschke Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 04 Apr 2011 20:30:05 -0000 On Mon Apr 4 19:26:25 2011, Willy Tarreau wrote: > He makes some points about the text/binary distinction. I remember > we had > valid reasons for this, which apparently became unclear to some > people with > time since I don't clearly remember all the use cases now. > > The basic reasoning behind the distinction is reliant on the understanding of the WebSocket Protocol as part of your complete breakfast, ie, WebSockets. In particular, WebSockets consists of a JavaScript API, which currently passes String objects to an event handler on each new message. Very early on, provision was made to have binary frames within the protocol; what we did here was unify the two frame types, but leave an indicator as to which they were. This allows - ultimately - the event handler in the JavaScript to be passed either a String or a ByteArray object, and avoids any UTF-8 decoding within the JavaScript. > His pause/resume mechanism is what I normally call flow control. It > might > be nice to study the idea, though it can have huge security impacts > as it > has on Ethernet and TCP (easy DoSes). No, his pause/resume involved disconnect/reconnect; it's akin to session resumption. Pasi Eironen, as I recall, wrote a lovely paper on how to do this generically with TLS. Similar options exist in XMPP, with XEP-0198. > The guy is apparently not used to TCP, as he believes that it's not > possible > to open more than 64k connections on a machine due to the 16-bit > port > numbering, as he assumes a 1:1 socket-port relation. Fortunately > this is not > true, or the internet would be much more congested ! Not only does > the server > run all its incoming sockets on one port, but even the clients can > initiate > more than 64k sockets from less than 64k ports! FTP servers open > all their > data connections from the same port 20 ;-) > > You can't open more than 64k connections from one IP address to another IP address and port. His concern is that this may occur: 1) Outbound, on enterprise NATs. This would involve 64k connections from within the enterprise - I don't think this is too likely through a single NAT, but his argument is that you need fewer clients because of people running multiple scripts with websocket connections to the same host. 2) In server farms, where you have reverse NAT. I've not seen this deployed, actually, in the manner he describes. I don't want to rubbish his arguments entirely, but I think they're limited to case (1), and I suspect that it would be mitigated in various ways. Firstly, if this genuinely became a problem, then this would drive IPv6, and I'm all in favour of that. Secondly, multihoming either end of the session increases the number of potential connections, and if both ends are multihomed across two IP addresses, it's already up to 256k. I would note that SRV support would allow usage of multiple ports on a single machine for this, although frankly, once you reach 64k sessions you probably want to consider a second machine anyway. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From bruce@callenish.com Mon Apr 4 16:26:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E213A6813 for ; Mon, 4 Apr 2011 16:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Xgj0HWHlLMSS for ; Mon, 4 Apr 2011 16:26:39 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id C0D383A6805 for ; Mon, 4 Apr 2011 16:26:39 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q6tBy-0006jj-6A; Mon, 04 Apr 2011 16:28:18 -0700 Message-ID: <4D9A5412.9040307@callenish.com> Date: Mon, 04 Apr 2011 16:28:18 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Salvatore Loreto References: <4D99C628.8090409@ericsson.com> In-Reply-To: <4D99C628.8090409@ericsson.com> Content-Type: multipart/alternative; boundary="------------010101090802020200030300" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 04 Apr 2011 23:26:40 -0000 This is a multi-part message in MIME format. --------------010101090802020200030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have a strong +1 preference for option 2, though if option 1 won out I could live with it. I hate how I have masking coded now and really want to recode it to look like an extension, even though it isn't really one. With the second option to the machine that is a difference that isn't a difference. On 04/04/2011 6:22 AM, Salvatore Loreto wrote: > > Based on that discussion, the decision is **only between two > alternatives**: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. > > --------------010101090802020200030300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have a strong +1 preference for option 2, though if option 1 won out I could live with it.

I hate how I have masking coded now and really want to recode it to look like an extension, even though it isn't really one. With the second option to the machine that is a difference that isn't a difference.

On 04/04/2011 6:22 AM, Salvatore Loreto wrote:

Based on that discussion, the decision is *only between two alternatives*:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.
 


--------------010101090802020200030300-- From duerst@it.aoyama.ac.jp Mon Apr 4 19:59:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760E43A6866 for ; Mon, 4 Apr 2011 19:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.044 X-Spam-Level: X-Spam-Status: No, score=-100.044 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 U36O3cnCOWpn for ; Mon, 4 Apr 2011 19:59:12 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by core3.amsl.com (Postfix) with ESMTP id 3E03F3A6840 for ; Mon, 4 Apr 2011 19:59:12 -0700 (PDT) Received: from acmse01.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p3530l17030610 for ; Tue, 5 Apr 2011 12:00:47 +0900 Received: from (unknown [133.2.206.133]) by acmse01.acbb.aoyama.ac.jp with smtp id 3a80_9f73_e7e34802_5f30_11e0_a1c1_001d096c5b62; Tue, 05 Apr 2011 12:00:47 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44450) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 5 Apr 2011 12:00:46 +0900 Message-ID: <4D9A85DC.50702@it.aoyama.ac.jp> Date: Tue, 05 Apr 2011 12:00:44 +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.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Joonas Lehtolahti References: <4D99C628.8090409@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 02:59:13 -0000 Same here. Regards, Martin. On 2011/04/05 0:39, Joonas Lehtolahti wrote: > Personally I can live with either approach but I have preference for > format (2). > > Cheers, > > Joonas > > > On Mon, 04 Apr 2011 16:22:48 +0300, Salvatore Loreto > wrote: > >> (as HyBi wg co-chair) >> >> >> Hi there, >> >> Last Tuesday, during the HyBi wg session at the IETF meeting, we >> discussed the masking issue. >> >> Based on that discussion, the decision is **only between two >> alternatives**: >> whether to (1) mask the entire frame, as in the current 06 spec, >> or to (2) mask only after the op codes and length. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From tyoshino@google.com Mon Apr 4 20:12:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916503A6860 for ; Mon, 4 Apr 2011 20:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.786 X-Spam-Level: X-Spam-Status: No, score=-105.786 tagged_above=-999 required=5 tests=[AWL=0.190, 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 sZWTaMZuQmF7 for ; Mon, 4 Apr 2011 20:12:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E20903A6840 for ; Mon, 4 Apr 2011 20:12:33 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p353EDXU017163 for ; Mon, 4 Apr 2011 20:14:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301973256; bh=OLJNBc6kujSgI7ASu+aJZMMfKFU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=JoGOFh9gm1fr7ObgnvRdKeDbgBzYT3lA1avIQek4cuJ4pAXAOgrls6HIIaAYilYHZ DiBxmB/gGexkCi1DIQrlQ== Received: from iyb39 (iyb39.prod.google.com [10.241.49.103]) by hpaq7.eem.corp.google.com with ESMTP id p353EBlv014207 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 20:14:12 -0700 Received: by iyb39 with SMTP id 39so10218294iyb.22 for ; Mon, 04 Apr 2011 20:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0my3RGNYlcDQvi0V0nXlgtAR5r0dlTg5fwH68A37shk=; b=MUympGO6czJwJqWDa53M1pq9qvJFKiTI/wdC0oFuKrsZHPz5JLvn3gEIUInZ620uDB zYu6+Cg/nOHqd3ArZInA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sdJpil51aCXDQtBn7hy2Ko91CLif/ZkKpjZS5dHrVUiShAG0l2P3UtCL/vNHo6QoFn 94IUbKlzBMYuolnkg8uA== Received: by 10.43.61.20 with SMTP id wu20mr12003149icb.371.1301973251115; Mon, 04 Apr 2011 20:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.141 with HTTP; Mon, 4 Apr 2011 20:13:50 -0700 (PDT) In-Reply-To: <4D99C628.8090409@ericsson.com> References: <4D99C628.8090409@ericsson.com> From: Takeshi Yoshino Date: Tue, 5 Apr 2011 12:13:50 +0900 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=bcaec51a833823cb4e04a0234533 X-System-Of-Record: true Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 03:12:34 -0000 --bcaec51a833823cb4e04a0234533 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 4, 2011 at 22:22, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > (as HyBi wg co-chair) > > > Hi there, > > Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed > the masking issue. > > Based on that discussion, the decision is **only between two alternatives* > *: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. > > I can live with either. Takeshi --bcaec51a833823cb4e04a0234533 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2011 at 22:22, Salvatore Lor= eto <= salvatore.loreto@ericsson.com> wrote:
=20 =20 =20
(as HyBi wg co-chair)


Hi there,

Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed the masking issue.

Based on that discussion, the decision is *only between two alternatives*:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.
=A0
<= br>
I can live with either.

Takeshi

--bcaec51a833823cb4e04a0234533-- From gregw@intalio.com Mon Apr 4 22:17:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14EF3A68AA for ; Mon, 4 Apr 2011 22:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iahs0ePQNFtd for ; Mon, 4 Apr 2011 22:17:50 -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 4AFED3A688A for ; Mon, 4 Apr 2011 22:17:50 -0700 (PDT) Received: by vws12 with SMTP id 12so14334vws.31 for ; Mon, 04 Apr 2011 22:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.18.11 with SMTP id s11mr3258334vdd.269.1301980772969; Mon, 04 Apr 2011 22:19:32 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Mon, 4 Apr 2011 22:19:32 -0700 (PDT) In-Reply-To: <4D99C628.8090409@ericsson.com> References: <4D99C628.8090409@ericsson.com> Date: Tue, 5 Apr 2011 15:19:32 +1000 Message-ID: From: Greg Wilkins To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 05:17:51 -0000 +1 for option (2) From w@1wt.eu Mon Apr 4 22:25:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9AC3A68AA for ; Mon, 4 Apr 2011 22:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.854, 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 e7zVMEgARcpM for ; Mon, 4 Apr 2011 22:25:17 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 55F1A3A6857 for ; Mon, 4 Apr 2011 22:25:15 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p355QqUB023762; Tue, 5 Apr 2011 07:26:52 +0200 Date: Tue, 5 Apr 2011 07:26:52 +0200 From: Willy Tarreau To: Dave Cridland Message-ID: <20110405052652.GF21300@1wt.eu> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <15466.1301949097.229241@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15466.1301949097.229241@puncture> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] Robert Gezelter on the current spec 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, 05 Apr 2011 05:25:18 -0000 Hi Dave, On Mon, Apr 04, 2011 at 09:31:37PM +0100, Dave Cridland wrote: (...) > This allows - ultimately - the event handler in the JavaScript to be > passed either a String or a ByteArray object, and avoids any UTF-8 > decoding within the JavaScript. OK, thanks for the details. > >His pause/resume mechanism is what I normally call flow control. It > >might > >be nice to study the idea, though it can have huge security impacts > >as it > >has on Ethernet and TCP (easy DoSes). > > No, his pause/resume involved disconnect/reconnect; it's akin to > session resumption. Pasi Eironen, as I recall, wrote a lovely paper > on how to do this generically with TLS. Similar options exist in > XMPP, with XEP-0198. In this case, it can indeed be nice for some uses. (...) > You can't open more than 64k connections from one IP address to > another IP address and port. I agree with that statement, though it's not what he was saying. > His concern is that this may occur: > > 1) Outbound, on enterprise NATs. This would involve 64k connections > from within the enterprise - I don't think this is too likely through > a single NAT, but his argument is that you need fewer clients because > of people running multiple scripts with websocket connections to the > same host. You already have the same issue with outbound proxies with HTTP keep-alive, and enterprises who need more than 64k concurrent connections generally have a number of users who are a large part of this, and will not restrict themselves to a single IP address, at least because they'll do some load balancing between multiple outbound proxies. And clearly, 64k conns to the same target IP:port is not something we'll see soon from enterprises, because it will probably be social networking and an employer who sees 64k of his employees chat all the day on social networks will surely take some actions :-) Last, many sites already run with multiple IP addresses for various reasons, there is no reason this will not be done with WS. > 2) In server farms, where you have reverse NAT. I've not seen this > deployed, actually, in the manner he describes. On the server side, the point does not exist because you're not limited by the number of ports, you can accept up to 64k connections per source IP address and per destination address. > I don't want to rubbish his arguments entirely, but I think they're > limited to case (1), and I suspect that it would be mitigated in > various ways. Exactly. > Firstly, if this genuinely became a problem, then this would drive > IPv6, and I'm all in favour of that. Secondly, multihoming either end > of the session increases the number of potential connections, and if > both ends are multihomed across two IP addresses, it's already up to > 256k. > > I would note that SRV support would allow usage of multiple ports on > a single machine for this, although frankly, once you reach 64k > sessions you probably want to consider a second machine anyway. Indeed. Cheers, Willy From dave@cridland.net Tue Apr 5 01:08:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267D43A681D for ; Tue, 5 Apr 2011 01:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, 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 5uXJag1492lT for ; Tue, 5 Apr 2011 01:08:43 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 63ECF3A68E9 for ; Tue, 5 Apr 2011 01:08:42 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id C0FC2116808D; Tue, 5 Apr 2011 09:10:23 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eRabq1ImS22; Tue, 5 Apr 2011 09:10:13 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 15A351168067; Tue, 5 Apr 2011 09:10:13 +0100 (BST) References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <15466.1301949097.229241@puncture> <20110405052652.GF21300@1wt.eu> In-Reply-To: <20110405052652.GF21300@1wt.eu> MIME-Version: 1.0 Message-Id: <2714.1301991013.050661@puncture> Date: Tue, 05 Apr 2011 09:10:13 +0100 From: Dave Cridland To: Willy Tarreau , Server-Initiated HTTP , Julian Reschke Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 05 Apr 2011 08:08:50 -0000 On Tue Apr 5 06:26:52 2011, Willy Tarreau wrote: > > No, his pause/resume involved disconnect/reconnect; it's akin to > > session resumption. Pasi Eironen, as I recall, wrote a lovely > paper > > on how to do this generically with TLS. Similar options exist in > > XMPP, with XEP-0198. > > In this case, it can indeed be nice for some uses. > > Can be, but I'd note that it's reliant on storing the state for the session on the server cluster in such a way that it can be fully recovered. That involves a lot of state, and to implement it perfectly, relies on a lot of shared state within a cluster. This tradeoff makes sense in XMPP, where there is substantial state in a session which takes time to build up. Equally, though, XMPP is a clear demonstration that it's possible to achieve this purely in the application layer. (And I note in passing that this statement characterises WebSockets as a transport layer by inference, but I've never been big on trying to shoehorn protocols onto explicitly named layers within a theoretical model). > > You can't open more than 64k connections from one IP address to > > another IP address and port. > > I agree with that statement, though it's not what he was saying. > > It's how I read it; it doesn't make sense otherwise. I have to admit I found the text somewhat impenetrable in parts. > > 1) Outbound, on enterprise NATs. This would involve 64k > connections > > from within the enterprise - I don't think this is too likely > through > > a single NAT, but his argument is that you need fewer clients > because > > of people running multiple scripts with websocket connections to > the > > same host. > > You already have the same issue with outbound proxies with HTTP > keep-alive, > and enterprises who need more than 64k concurrent connections > generally > have a number of users who are a large part of this, and will not > restrict > themselves to a single IP address, at least because they'll do some > load > balancing between multiple outbound proxies. And clearly, 64k conns > to the > same target IP:port is not something we'll see soon from > enterprises, > because it will probably be social networking and an employer who > sees > 64k of his employees chat all the day on social networks will > surely take > some actions :-) We do see this for IM, but I'd note the mitigation can be very different - they can just deploy their own XMPP service which drastically reduces outbound connections. > > 2) In server farms, where you have reverse NAT. I've not seen this > > deployed, actually, in the manner he describes. > > On the server side, the point does not exist because you're not > limited > by the number of ports, you can accept up to 64k connections per > source > IP address and per destination address. > > Right. As I say, he posits a case where there is a SNAT at the server farm on inbound connections. Or, possibly, a DNAT performing IP-level load balancing. I have to admit I found this text confusing as well - the latter seems much more likely to exist, so I can only assume that's what he meant. The overall synopsis of much of his text might read "different network protocols have different effects on the network, and some of these effects may be bad", which I note is similar to what Roy Fielding comments. I don't dispute that there will be unforseen complications with running the WebSocket protocol over a collection of (often "interesting") network equipment that expects only, but the ones that Gezelter lists are, I feel, not the ones to be concerned with. Besides which, they're not unforseen anymore. ;-) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From simonp@opera.com Tue Apr 5 01:40:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8243A68EE for ; Tue, 5 Apr 2011 01:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 g-JcSNkGMj7u for ; Tue, 5 Apr 2011 01:40:43 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 8A3BC3A68E9 for ; Tue, 5 Apr 2011 01:40:43 -0700 (PDT) Received: from simon-pieterss-macbook.local ([87.253.73.138]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p358ft4x015467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2011 08:41:55 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "hybi@ietf.org" , "Salvatore Loreto" References: <4D99C628.8090409@ericsson.com> Date: Tue, 05 Apr 2011 10:41:53 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: <4D99C628.8090409@ericsson.com> User-Agent: Opera Mail/11.10 (MacIntel) Cc: SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 08:40:44 -0000 On Mon, 04 Apr 2011 15:22:48 +0200, Salvatore Loreto wrote: > (as HyBi wg co-chair) > > > Hi there, > > Last Tuesday, during the HyBi wg session at the IETF meeting, we > discussed the masking issue. > > Based on that discussion, the decision is **only between two > alternatives**: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. > > In the wire format for (1), the 32-bit masking-key appears first, and > then the entire frame masked (as in 06): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------------------------------------------------------+ > | Masking-key | > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|R| Payload len | Extended payload length | > |I|S|S|S| (4) |S| (7) | (16/63) | > |N|V|V|V| |V| | (if payload len==126/127) | > | |1|2|3| |4| | | > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > | Extended payload length continued, if payload len == 127 | > + - - - - - - - - - - - - - - - +-------------------------------+ > | | Extension data | > +-------------------------------+ - - - - - - - - - - - - - - - + > : : > +---------------------------------------------------------------+ > : Application data : > +---------------------------------------------------------------+ > > > In the wire format for (2), the masking-key appears after the op codes > and length fields. > This is where 06 shows the "Extension data". The extension data and the > rest of the frame would be shifted 32 bits and it would all be masked. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|R| Payload len | Extended payload length | > |I|S|S|S| (4) |S| (7) | (16/63) | > |N|V|V|V| |V| | (if payload len==126/127) | > | |1|2|3| |4| | | > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > | Extended payload length continued, if payload len == 127 | > + - - - - - - - - - - - - - - - +-------------------------------+ > | | Masking-key | > +---------------------------------------------------------------+ > | Masking-key (continued) | Extension data | > +-------------------------------+ - - - - - - - - - - - - - - - + > : : > +---------------------------------------------------------------+ > : Application data : > +---------------------------------------------------------------+ > > In both cases, everything after the Masking-key is masked. > > Several folks have already expressed themselves on this issue either > recently on the mailing list, or in person at the IETF meeting this week. > > Gabriel and I, as HyBi wg chairs, would like to solicit only those who > have not yet expressed themselves on this issue, to do so now. > > We will wait for additional feedback **until Friday April 8**, and based > on the feedback will make a decision shortly afterward. I prefer option 1 on the basis that an attacker has less control over the bits that go over the wire. It's not enough bytes to pull off the cache poison attack, but it might be enough to pull off a different attack that we are unware of today. However, I can live with option 2 if the WG decides to go with that. (If we find that option 2 has a security problem in the future because the attacker can contorl the length bytes, we can always require that browser clients always fragment at into two fragments at a random position when length is greater than 64k or so.) -- Simon Pieters Opera Software From fenix@google.com Tue Apr 5 01:55:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5963A3A68F1 for ; Tue, 5 Apr 2011 01:55:59 -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 F5gOalPdQQe5 for ; Tue, 5 Apr 2011 01:55:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id C59413A68F5 for ; Tue, 5 Apr 2011 01:55:51 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p358vX0P003791 for ; Tue, 5 Apr 2011 01:57:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301993853; bh=qdXCFO4CdXoW2/RJSkiH7sThRtg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RrT3rGdLYN/0unmzzYTrtnd1CyNzI4FR9TER9wmq8Fo6NdhrlIL2tRlb4XXlYH0Qo ICHw6OUJDkKERAplkK4kg== Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by hpaq7.eem.corp.google.com with ESMTP id p358vV4E002342 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 5 Apr 2011 01:57:32 -0700 Received: by yxs7 with SMTP id 7so58288yxs.5 for ; Tue, 05 Apr 2011 01:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=10bv5z+yTVdiD6Gz9lKQ+r2fIqamQNrofORIaiDjcaU=; b=XmInhyuDGQGTxl7d5WSuYYFCrmbR6iOeUpgHtmnDAP8bKn9/mQrLNKU5+mIBnI+ipy elVnfukyA2lWMiF+mOew== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lWodCV0RIdv4jETpQ3J5jEkC7UBItHMAM/s+7ZC/ar+eGM8BXN3KVAg4ZmxB9iW25+ 1JddGED5IUeGUIWiteLg== MIME-Version: 1.0 Received: by 10.150.72.7 with SMTP id u7mr299547yba.75.1301993851265; Tue, 05 Apr 2011 01:57:31 -0700 (PDT) Received: by 10.150.182.9 with HTTP; Tue, 5 Apr 2011 01:57:31 -0700 (PDT) Received: by 10.150.182.9 with HTTP; Tue, 5 Apr 2011 01:57:31 -0700 (PDT) In-Reply-To: References: <4D99C628.8090409@ericsson.com> Date: Tue, 5 Apr 2011 01:57:31 -0700 Message-ID: From: Roberto Peon To: Simon Pieters Content-Type: multipart/alternative; boundary=000e0cd58e680122f304a0281149 X-System-Of-Record: true Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 08:55:59 -0000 --000e0cd58e680122f304a0281149 Content-Type: text/plain; charset=ISO-8859-1 I prefer option 2. -=R On Apr 5, 2011 1:42 AM, "Simon Pieters" wrote: > On Mon, 04 Apr 2011 15:22:48 +0200, Salvatore Loreto > wrote: > >> (as HyBi wg co-chair) >> >> >> Hi there, >> >> Last Tuesday, during the HyBi wg session at the IETF meeting, we >> discussed the masking issue. >> >> Based on that discussion, the decision is **only between two >> alternatives**: >> whether to (1) mask the entire frame, as in the current 06 spec, >> or to (2) mask only after the op codes and length. >> >> In the wire format for (1), the 32-bit masking-key appears first, and >> then the entire frame masked (as in 06): >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +---------------------------------------------------------------+ >> | Masking-key | >> +-+-+-+-+-------+-+-------------+-------------------------------+ >> |F|R|R|R| opcode|R| Payload len | Extended payload length | >> |I|S|S|S| (4) |S| (7) | (16/63) | >> |N|V|V|V| |V| | (if payload len==126/127) | >> | |1|2|3| |4| | | >> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + >> | Extended payload length continued, if payload len == 127 | >> + - - - - - - - - - - - - - - - +-------------------------------+ >> | | Extension data | >> +-------------------------------+ - - - - - - - - - - - - - - - + >> : : >> +---------------------------------------------------------------+ >> : Application data : >> +---------------------------------------------------------------+ >> >> >> In the wire format for (2), the masking-key appears after the op codes >> and length fields. >> This is where 06 shows the "Extension data". The extension data and the >> rest of the frame would be shifted 32 bits and it would all be masked. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-------+-+-------------+-------------------------------+ >> |F|R|R|R| opcode|R| Payload len | Extended payload length | >> |I|S|S|S| (4) |S| (7) | (16/63) | >> |N|V|V|V| |V| | (if payload len==126/127) | >> | |1|2|3| |4| | | >> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + >> | Extended payload length continued, if payload len == 127 | >> + - - - - - - - - - - - - - - - +-------------------------------+ >> | | Masking-key | >> +---------------------------------------------------------------+ >> | Masking-key (continued) | Extension data | >> +-------------------------------+ - - - - - - - - - - - - - - - + >> : : >> +---------------------------------------------------------------+ >> : Application data : >> +---------------------------------------------------------------+ >> >> In both cases, everything after the Masking-key is masked. >> >> Several folks have already expressed themselves on this issue either >> recently on the mailing list, or in person at the IETF meeting this week. >> >> Gabriel and I, as HyBi wg chairs, would like to solicit only those who >> have not yet expressed themselves on this issue, to do so now. >> >> We will wait for additional feedback **until Friday April 8**, and based >> on the feedback will make a decision shortly afterward. > > I prefer option 1 on the basis that an attacker has less control over the > bits that go over the wire. It's not enough bytes to pull off the cache > poison attack, but it might be enough to pull off a different attack that > we are unware of today. However, I can live with option 2 if the WG > decides to go with that. (If we find that option 2 has a security problem > in the future because the attacker can contorl the length bytes, we can > always require that browser clients always fragment at into two fragments > at a random position when length is greater than 64k or so.) > > -- > Simon Pieters > Opera Software > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --000e0cd58e680122f304a0281149 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I prefer option 2.
-=3DR

On Apr 5, 2011 1:42 AM, "Simon Pieters"= ; <simonp@opera.com> wrote:> On Mon, 04 Apr 2011 15:22:48 +0200, Salvatore L= oreto
> <salvatore.loreto@= ericsson.com> wrote:
>
>> (as HyBi wg co-chair)
&= gt;>
>>
>> Hi there,
>>
>> Last Tues= day, during the HyBi wg session at the IETF meeting, we
>> discussed the masking issue.
>>
>> Based on that= discussion, the decision is **only between two
>> alternatives*= *:
>> whether to (1) mask the entire frame, as in the current 06 s= pec,
>> or to (2) mask only after the op codes and length.
>>
= >> In the wire format for (1), the 32-bit masking-key appears first, = and
>> then the entire frame masked (as in 06):
>>
>> 0 1 2 = 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1
>> +---------------------------------------------= ------------------+
>> | Masking-key = |
>> +-+-+-+-+-------+-+-------------+------------------= -------------+
>> |F|R|R|R| opcode|R| Payload len | Exten= ded payload length |
>> |I|S|S|S| (4) |S| (7) | (16/63) = |
>> |N|V|V|V| |V| | (if payload len= =3D=3D126/127) |
>> | |1|2|3| |4| | = |
>> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - = - - +
>> | Extended payload length continued, if payload= len =3D=3D 127 |
>> + - - - - - - - - - - - - - - - +-----= --------------------------+
>> | | Extension data = |
>> +-------------------------------+ - - - - - - - - -= - - - - - - +
>> : = :
>> +-----------------------------------------------------------= ----+
>> : Application data = :
>> +-----------------------------------------= ----------------------+
>>
>>
>> In the wire format for (2), the masking-ke= y appears after the op codes
>> and length fields.
>> Thi= s is where 06 shows the "Extension data". The extension data and = the
>> rest of the frame would be shifted 32 bits and it would all be mas= ked.
>>
>> 0 1 = 2 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-------+-+-------------+---------------------------= ----+
>> |F|R|R|R| opcode|R| Payload len | Extended paylo= ad length |
>> |I|S|S|S| (4) |S| (7) | = (16/63) |
>> |N|V|V|V| |V| | (if payload len=3D=3D126= /127) |
>> | |1|2|3| |4| | = |
>> +-+-+-+-+-------+-+-------------+ - - = - - - - - - - - - - - - - +
>> | Extended payload length continued, if payload len =3D= =3D 127 |
>> + - - - - - - - - - - - - - - - +-------------= ------------------+
>> | | = Masking-key |
>> +------------------------------------------------------------= ---+
>> | Masking-key (continued) | Extension = data |
>> +-------------------------------+ - - - - -= - - - - - - - - - - +
>> : = :
>> +--------------------------------------------------= -------------+
>> : Application data = :
>> +-----------------------------------------------------------= ----+
>>
>> In both cases, everything after the Masking-k= ey is masked.
>>
>> Several folks have already expressed = themselves on this issue either
>> recently on the mailing list, or in person at the IETF meeting thi= s week.
>>
>> Gabriel and I, as HyBi wg chairs, would lik= e to solicit only those who
>> have not yet expressed themselves o= n this issue, to do so now.
>>
>> We will wait for additional feedback **until Friday Ap= ril 8**, and based
>> on the feedback will make a decision shortly= afterward.
>
> I prefer option 1 on the basis that an attacke= r has less control over the
> bits that go over the wire. It's not enough bytes to pull off the = cache
> poison attack, but it might be enough to pull off a differe= nt attack that
> we are unware of today. However, I can live with o= ption 2 if the WG
> decides to go with that. (If we find that option 2 has a security prob= lem
> in the future because the attacker can contorl the length byt= es, we can
> always require that browser clients always fragment at= into two fragments
> at a random position when length is greater than 64k or so.)
> <= br>> --
> Simon Pieters
> Opera Software
> __________= _____________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.iet= f.org/mailman/listinfo/hybi
--000e0cd58e680122f304a0281149-- From ietf@meetecho.com Tue Apr 5 09:38:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3C83A695F for ; Tue, 5 Apr 2011 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 F8-YRUqlNcaj for ; Tue, 5 Apr 2011 09:38:24 -0700 (PDT) Received: from smtpw2.aruba.it (smtpa1.aruba.it [62.149.128.210]) by core3.amsl.com (Postfix) with SMTP id 00E0B3A6960 for ; Tue, 5 Apr 2011 09:38:23 -0700 (PDT) Received: (qmail 19974 invoked by uid 89); 5 Apr 2011 16:40:05 -0000 Received: from unknown (HELO aruba.it) (62.149.158.91) by smtpw2.ad.aruba.it with SMTP; 5 Apr 2011 16:40:05 -0000 Date: Tue, 5 Apr 2011 18:40:05 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1302021605.2A.945033.42.2602.52.42.007.359543992" From: "ietf@meetecho.com" To: hybi@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.199 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: [hybi] HYBI recording available -- 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: Tue, 05 Apr 2011 16:38:25 -0000 --_=__=_XaM3_.1302021605.2A.945033.42.2602.52.42.007.359543992 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,the full recording (synchronized video, audio, slides and jabber= room) of the HYBI session at IETF80 is available at the following URL:ht= tp://ietf.conf.meetecho.comYou can either choose to watch it online (two = different approaches are available) or download and replay it whenever yo= u want.In case of problems with the playout, just drop an e-mail to ietf-= support@meetecho.com.For the chair(s): please feel free to put the link t= o the recording in the minutes, if you think this might be useful.Cheers,= the Meetecho Team --_=__=_XaM3_.1302021605.2A.945033.42.2602.52.42.007.359543992 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,

the full recording (synchronized v= ideo, audio, slides and jabber room) of the HYBI session at IETF80 is ava= ilable at the following URL:
http://ietf.conf.meetecho.com

You = can either choose to watch it online (two different approaches are availa= ble) or download and replay it whenever you want.

In case of probl= ems with the playout, just drop an e-mail to ietf-support@meetecho.com.
For the chair(s): please feel free to put the link to the recording= in the minutes, if you think this might be useful.

Cheers,
the= Meetecho Team
=0A
=0A --_=__=_XaM3_.1302021605.2A.945033.42.2602.52.42.007.359543992-- From jlee@antwerkz.com Tue Apr 5 10:10:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5129E28C12C for ; Tue, 5 Apr 2011 10:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlRDJ-wyaWCS for ; Tue, 5 Apr 2011 10:10: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 CD2AA28C11F for ; Tue, 5 Apr 2011 10:10:56 -0700 (PDT) Received: by fxm15 with SMTP id 15so488282fxm.31 for ; Tue, 05 Apr 2011 10:12:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.124.7 with SMTP id s7mr98093far.123.1302023469237; Tue, 05 Apr 2011 10:11:09 -0700 (PDT) Received: by 10.223.111.131 with HTTP; Tue, 5 Apr 2011 10:11:08 -0700 (PDT) In-Reply-To: References: <4D99C628.8090409@ericsson.com> Date: Tue, 5 Apr 2011 13:11:08 -0400 Message-ID: From: Justin Lee To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001636c5b5925f86aa04a02ef6e9 Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 17:10:59 -0000 --001636c5b5925f86aa04a02ef6e9 Content-Type: text/plain; charset=ISO-8859-1 I prefer option 2 as well. On Tue, Apr 5, 2011 at 4:57 AM, Roberto Peon wrote: > I prefer option 2. > -=R > On Apr 5, 2011 1:42 AM, "Simon Pieters" wrote: > > On Mon, 04 Apr 2011 15:22:48 +0200, Salvatore Loreto > > wrote: > > > >> (as HyBi wg co-chair) > >> > >> > >> Hi there, > >> > >> Last Tuesday, during the HyBi wg session at the IETF meeting, we > >> discussed the masking issue. > >> > >> Based on that discussion, the decision is **only between two > >> alternatives**: > >> whether to (1) mask the entire frame, as in the current 06 spec, > >> or to (2) mask only after the op codes and length. > >> > >> In the wire format for (1), the 32-bit masking-key appears first, and > >> then the entire frame masked (as in 06): > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +---------------------------------------------------------------+ > >> | Masking-key | > >> +-+-+-+-+-------+-+-------------+-------------------------------+ > >> |F|R|R|R| opcode|R| Payload len | Extended payload length | > >> |I|S|S|S| (4) |S| (7) | (16/63) | > >> |N|V|V|V| |V| | (if payload len==126/127) | > >> | |1|2|3| |4| | | > >> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > >> | Extended payload length continued, if payload len == 127 | > >> + - - - - - - - - - - - - - - - +-------------------------------+ > >> | | Extension data | > >> +-------------------------------+ - - - - - - - - - - - - - - - + > >> : : > >> +---------------------------------------------------------------+ > >> : Application data : > >> +---------------------------------------------------------------+ > >> > >> > >> In the wire format for (2), the masking-key appears after the op codes > >> and length fields. > >> This is where 06 shows the "Extension data". The extension data and the > >> rest of the frame would be shifted 32 bits and it would all be masked. > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-------+-+-------------+-------------------------------+ > >> |F|R|R|R| opcode|R| Payload len | Extended payload length | > >> |I|S|S|S| (4) |S| (7) | (16/63) | > >> |N|V|V|V| |V| | (if payload len==126/127) | > >> | |1|2|3| |4| | | > >> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > >> | Extended payload length continued, if payload len == 127 | > >> + - - - - - - - - - - - - - - - +-------------------------------+ > >> | | Masking-key | > >> +---------------------------------------------------------------+ > >> | Masking-key (continued) | Extension data | > >> +-------------------------------+ - - - - - - - - - - - - - - - + > >> : : > >> +---------------------------------------------------------------+ > >> : Application data : > >> +---------------------------------------------------------------+ > >> > >> In both cases, everything after the Masking-key is masked. > >> > >> Several folks have already expressed themselves on this issue either > >> recently on the mailing list, or in person at the IETF meeting this > week. > >> > >> Gabriel and I, as HyBi wg chairs, would like to solicit only those who > >> have not yet expressed themselves on this issue, to do so now. > >> > >> We will wait for additional feedback **until Friday April 8**, and based > >> on the feedback will make a decision shortly afterward. > > > > I prefer option 1 on the basis that an attacker has less control over the > > > bits that go over the wire. It's not enough bytes to pull off the cache > > poison attack, but it might be enough to pull off a different attack that > > > we are unware of today. However, I can live with option 2 if the WG > > decides to go with that. (If we find that option 2 has a security problem > > > in the future because the attacker can contorl the length bytes, we can > > always require that browser clients always fragment at into two fragments > > > at a random position when length is greater than 64k or so.) > > > > -- > > Simon Pieters > > Opera Software > > _______________________________________________ > > 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 > > -- You can find me on the net at: http://antwerkz.com http://www.linkedin.com/in/justinlee http://www.twitter.com/evanchooly --001636c5b5925f86aa04a02ef6e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I prefer option 2 as well.

On Tue, Apr 5,= 2011 at 4:57 AM, Roberto Peon <fenix@google.com> wrote:

I prefer option 2.
-=3DR

On Apr 5, 2011 1:42 AM, "Simon Pieters"= ; <simonp@opera.co= m> wrote:
> On Mon, 04 Apr 2011 15:22:48 = +0200, Salvatore Loreto
> <salvatore.loreto@ericsson.com> wrote:
>
>> (as HyBi= wg co-chair)
>>
>>
>> Hi there,
>>
>> Last Tuesday, during the HyBi wg session at the IETF meeting, we >> discussed the masking issue.
>>
>> Based on that= discussion, the decision is **only between two
>> alternatives*= *:
>> whether to (1) mask the entire frame, as in the current 06 s= pec,
>> or to (2) mask only after the op codes and length.
>>
= >> In the wire format for (1), the 32-bit masking-key appears first, = and
>> then the entire frame masked (as in 06):
>>
>> 0 1 2 = 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1
>> +---------------------------------------------= ------------------+
>> | Masking-key = |
>> +-+-+-+-+-------+-+-------------+------------------= -------------+
>> |F|R|R|R| opcode|R| Payload len | Exten= ded payload length |
>> |I|S|S|S| (4) |S| (7) | (16/63) = |
>> |N|V|V|V| |V| | (if payload len= =3D=3D126/127) |
>> | |1|2|3| |4| | = |
>> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - = - - +
>> | Extended payload length continued, if payload= len =3D=3D 127 |
>> + - - - - - - - - - - - - - - - +-----= --------------------------+
>> | | Extension data = |
>> +-------------------------------+ - - - - - - - - -= - - - - - - +
>> : = :
>> +-----------------------------------------------------------= ----+
>> : Application data = :
>> +-----------------------------------------= ----------------------+
>>
>>
>> In the wire format for (2), the masking-ke= y appears after the op codes
>> and length fields.
>> Thi= s is where 06 shows the "Extension data". The extension data and = the
>> rest of the frame would be shifted 32 bits and it would all be mas= ked.
>>
>> 0 1 = 2 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-------+-+-------------+---------------------------= ----+
>> |F|R|R|R| opcode|R| Payload len | Extended paylo= ad length |
>> |I|S|S|S| (4) |S| (7) | = (16/63) |
>> |N|V|V|V| |V| | (if payload len=3D=3D126= /127) |
>> | |1|2|3| |4| | = |
>> +-+-+-+-+-------+-+-------------+ - - = - - - - - - - - - - - - - +
>> | Extended payload length continued, if payload len =3D= =3D 127 |
>> + - - - - - - - - - - - - - - - +-------------= ------------------+
>> | | = Masking-key |
>> +------------------------------------------------------------= ---+
>> | Masking-key (continued) | Extension = data |
>> +-------------------------------+ - - - - -= - - - - - - - - - - +
>> : = :
>> +--------------------------------------------------= -------------+
>> : Application data = :
>> +-----------------------------------------------------------= ----+
>>
>> In both cases, everything after the Masking-k= ey is masked.
>>
>> Several folks have already expressed = themselves on this issue either
>> recently on the mailing list, or in person at the IETF meeting thi= s week.
>>
>> Gabriel and I, as HyBi wg chairs, would lik= e to solicit only those who
>> have not yet expressed themselves o= n this issue, to do so now.
>>
>> We will wait for additional feedback **until Friday Ap= ril 8**, and based
>> on the feedback will make a decision shortly= afterward.
>
> I prefer option 1 on the basis that an attacke= r has less control over the
> bits that go over the wire. It's not enough bytes to pull off the = cache
> poison attack, but it might be enough to pull off a differe= nt attack that
> we are unware of today. However, I can live with o= ption 2 if the WG
> decides to go with that. (If we find that option 2 has a security prob= lem
> in the future because the attacker can contorl the length byt= es, we can
> always require that browser clients always fragment at= into two fragments
> at a random position when length is greater than 64k or so.)
> <= br>> --
> Simon Pieters
> Opera Software
> __________= _____________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

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




--
You can find me on = the net at:
--001636c5b5925f86aa04a02ef6e9-- From alexey.melnikov@isode.com Tue Apr 5 10:24:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8711828C12B for ; Tue, 5 Apr 2011 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUlQsdQj2FgB for ; Tue, 5 Apr 2011 10:24:39 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 670B528C11D for ; Tue, 5 Apr 2011 10:24:38 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 5 Apr 2011 18:26:20 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D9B5091.1020008@isode.com> Date: Tue, 05 Apr 2011 18:25:37 +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: Salvatore Loreto References: <4D99C628.8090409@ericsson.com> In-Reply-To: <4D99C628.8090409@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 17:24:40 -0000 Salvatore Loreto wrote: > (as HyBi wg co-chair) > > > Hi there, > > Last Tuesday, during the HyBi wg session at the IETF meeting, we > discussed the masking issue. > > Based on that discussion, the decision is *only between two alternatives*: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. I prefer option 1. From stpeter@stpeter.im Tue Apr 5 12:20:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19AB3A67DA for ; Tue, 5 Apr 2011 12:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAhpSk0sYSEo for ; Tue, 5 Apr 2011 12:20:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DC81C3A67AE for ; Tue, 5 Apr 2011 12:20:39 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1B20F40022; Tue, 5 Apr 2011 13:24:40 -0600 (MDT) Message-ID: <4D9B6BEB.8070405@stpeter.im> Date: Tue, 05 Apr 2011 13:22:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dave Cridland References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <15466.1301949097.229241@puncture> <20110405052652.GF21300@1wt.eu> <2714.1301991013.050661@puncture> In-Reply-To: <2714.1301991013.050661@puncture> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050704010901050804080902" Cc: Server-Initiated HTTP Subject: Re: [hybi] Robert Gezelter on the current spec 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, 05 Apr 2011 19:20:41 -0000 This is a cryptographically signed message in MIME format. --------------ms050704010901050804080902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/5/11 2:10 AM, Dave Cridland wrote: > (And I > note in passing that this statement characterises WebSockets as a > transport layer by inference, but I've never been big on trying to > shoehorn protocols onto explicitly named layers within a theoretical > model). This was noted during the HYBI WG session last week. Your ADs will be pinging the Transport ADs about getting an early review from a relevant expert in the Transport Area... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050704010901050804080902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQw NTE5MjIxOVowIwYJKoZIhvcNAQkEMRYEFPuiq9k1YuJ7nI6c6+AH+D39EBQnMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAFaYuOr/vtZsn/FBHnRfuXSrJjvu+/K2uByrvWM6OuLsXqAKjVamp52vB9 0WbX9S4h8YyjWRgPYvvDWoeqpmCnrm13tySsGllwepX0Gux8N1orJ8sEFjx3ykymEZH53h2y cTaX6vJPEqRBTsmLbaPztgozyRgG/ASEg04o7t9FqEsAYBNkwwfCeQ8kXjGZnHo9ACVdlb2Z IhbwghZfDF2/LEbvzhyenvJ+6WqU9QBD/a+e+yNdKApNnOP7v/ZW+b8JCZNuwkUU3Qhfe2Kn /Fa6KWDF8IKuL1g6go5flhiIU24aKaBxJa/86kfkZ3C+KigqzWrAuxpkHU67MiScLByIAAAA AAAA --------------ms050704010901050804080902-- From Greg@ChampionEnt.net Tue Apr 5 15:31:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BA428C133 for ; Tue, 5 Apr 2011 15:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eASvopTbJdcZ for ; Tue, 5 Apr 2011 15:31:54 -0700 (PDT) Received: from smtpout-1.iphouse.net (smtpout-1.iphouse.net [209.240.70.140]) by core3.amsl.com (Postfix) with ESMTP id 6FC6428C108 for ; Tue, 5 Apr 2011 15:31:53 -0700 (PDT) Received: from smtpout-1.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 8994A1CCB5 for ; Tue, 5 Apr 2011 17:33:35 -0500 (CDT) Received: from GJL8710w (office1.championent.net [216.160.45.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-1.iphouse.net (Postfix) with ESMTPSA id 1F2F01CCA4 for ; Tue, 5 Apr 2011 17:33:35 -0500 (CDT) From: "Greg Longtin" To: "hybi" References: <4D99C628.8090409@ericsson.com> In-Reply-To: <4D99C628.8090409@ericsson.com> Date: Tue, 5 Apr 2011 17:33:34 -0500 Message-ID: <001f01cbf3e1$801dd120$80597360$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvyy22Gcz9DcZRFT6KLmm9Sn4A8tABFXCkw Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 22:31:55 -0000 > Based on that discussion, the decision is *only between two alternatives*: > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. I vote for #1 Based on 1. The (possibly unfounded) belief that it may improve security. 2. My server code (and other's also) works with #1. Yes, selfish. Greg Longtin From theturtle32@gmail.com Tue Apr 5 15:35:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0647728C15A for ; Tue, 5 Apr 2011 15:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFPVGLQ1dVky for ; Tue, 5 Apr 2011 15:35:45 -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 372D828C151 for ; Tue, 5 Apr 2011 15:35:45 -0700 (PDT) Received: by iwn39 with SMTP id 39so1048141iwn.31 for ; Tue, 05 Apr 2011 15:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=uLPurCBpDhR3pk1GOt6CXxEQ5KYtV/Q5FqiEV/BYYhg=; b=Jxfgd9nPfixFX7mZoxLlHYtwCWpCU5jLTr7L6SobsQMNVsROzE3YuWPrAI+XKHUYXv W1KEYe8ghP/8+30sSz6KextC+4MngnD5wf8a5T8xUd5ds4kVPS5SWrR2BrJ/itNgrwbs GynpobsOEDyObqJTmrO+ultL3NNsng9RMefMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=bgCnr80jZ4YIE++NSp0dkjGDKLViC3v1zlIaPhcMkre3nu+FZbDAQZmHl6rWAf+X65 279YBADdM5hHuq8xj/MVh2x91Gexs9goC7ciVX2IPPl/wn3udwKHyec87/E1+cOlYDWV yG4rOc4VgVptHqnF+XDFuY6PK0sF8ByA58MOE= Received: by 10.42.168.198 with SMTP id x6mr365441icy.273.1302043048621; Tue, 05 Apr 2011 15:37:28 -0700 (PDT) Received: from [10.83.93.187] ([166.205.137.229]) by mx.google.com with ESMTPS id o3sm4737300ibd.10.2011.04.05.15.37.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 15:37:28 -0700 (PDT) References: <4D99C628.8090409@ericsson.com> <001f01cbf3e1$801dd120$80597360$@net> In-Reply-To: <001f01cbf3e1$801dd120$80597360$@net> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Tue, 5 Apr 2011 15:37:22 -0700 To: Greg Longtin Cc: hybi Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 22:35:46 -0000 I'm implementing my server to support #1 to comply with the current draft bu= t I can't wait until I can modify it to use #2. :) Brian Sent from my iPhone On Apr 5, 2011, at 3:33 PM, "Greg Longtin" wrote: >> Based on that discussion, the decision is *only between two alternatives*= : >> whether to (1) mask the entire frame, as in the current 06 spec, >> or to (2) mask only after the op codes and length.=20 >=20 > I vote for #1 >=20 > Based on >=20 > 1. The (possibly unfounded) belief that it may improve security. >=20 > 2. My server code (and other's also) works with #1. Yes, selfish. >=20 > Greg Longtin >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From a.catel@weelya.com Tue Apr 5 15:40:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6173A6809 for ; Tue, 5 Apr 2011 15:40: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 6VaUw8UnbiLX for ; Tue, 5 Apr 2011 15:40:50 -0700 (PDT) Received: from mail.weelya.com (mail.weelya.com [91.121.234.81]) by core3.amsl.com (Postfix) with ESMTP id D94963A6804 for ; Tue, 5 Apr 2011 15:40:49 -0700 (PDT) Received: by mail.weelya.com (Postfix, from userid 65534) id 12C49BD8AC6; Wed, 6 Apr 2011 00:42:48 +0200 (CEST) Received: from [192.168.1.239] (g231208079.adsl.alicedsl.de [92.231.208.79]) by mail.weelya.com (Postfix) with ESMTPA id A10C7BD8A6F for ; Wed, 6 Apr 2011 00:42:47 +0200 (CEST) Message-ID: <4D9B9AD3.2020101@weelya.com> Date: Wed, 06 Apr 2011 00:42:27 +0200 From: Anthony Catel User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: <4D99C628.8090409@ericsson.com> <001f01cbf3e1$801dd120$80597360$@net> In-Reply-To: <001f01cbf3e1$801dd120$80597360$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 22:40:50 -0000 I also vote for #1 because I'm too lazy to rewrite my code ;) and see no reason to favor #2 Le 06/04/2011 00:33, Greg Longtin a écrit : >> Based on that discussion, the decision is *only between two alternatives*: >> whether to (1) mask the entire frame, as in the current 06 spec, >> or to (2) mask only after the op codes and length. > I vote for #1 > > Based on > > 1. The (possibly unfounded) belief that it may improve security. > > 2. My server code (and other's also) works with #1. Yes, selfish. > > Greg Longtin > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From derhoermi@gmx.net Tue Apr 5 15:49:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34EF53A6811 for ; Tue, 5 Apr 2011 15:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, MANGLED_EXTNSN=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RqzR-KuEZT7 for ; Tue, 5 Apr 2011 15:49:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A7A0E3A6810 for ; Tue, 5 Apr 2011 15:49:13 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2011 22:50:55 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp032) with SMTP; 06 Apr 2011 00:50:55 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19FBjhCOgpF3smWcLkiZBdj/LGOyPUznLeXvdbI6Y UX9PvW6wBiR24F From: Bjoern Hoehrmann To: hybi@ietf.org Date: Wed, 06 Apr 2011 00:51:11 +0200 Message-ID: <385np69jlv63dp4sppebgrf7u9coamkqjt@hive.bjoern.hoehrmann.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [hybi] Connection-level extensions 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, 05 Apr 2011 22:49:15 -0000 Hi, I gather from the threads on how masking makes the deflate-stream ex- tension perform much worse that the extension is essentially a deflate- tunnel that wraps around the Websocket frames. I am not sure people are aware this kind of extension is even possible and there are problems with them, for instance, the current draft does not really mention this as a possibility and you can't write intermediaries that need to under- stand parts of the protocol without having to upgrade them for each new extension. For `deflate-stream` in particular it's not even very useful to work in this manner due to masking, and since masking does not actually random- ize the content that is sent, it would also seem to defeat masking. De- flation compresses by replacing repeated sequences with references, and the chosen masking scheme allows attackers to produce repeated sequences so it may be quite possible to generate messages deflation turns into a desired sequence of bytes, if the deflate implementation is predictable. It seems odd to me that everybody is okay with having connection-level extensions at all, and having the `deflate-stream` extension designed in this manner in particular. In any case, this should be mentioned promi- nently in the specification. regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From Greg@ChampionEnt.net Tue Apr 5 15:54:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7A53A67F4 for ; Tue, 5 Apr 2011 15:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md6Onk72LAfR for ; Tue, 5 Apr 2011 15:54:38 -0700 (PDT) Received: from smtpout-1.iphouse.net (smtpout-1.iphouse.net [209.240.70.140]) by core3.amsl.com (Postfix) with ESMTP id D1A563A66B4 for ; Tue, 5 Apr 2011 15:54:38 -0700 (PDT) Received: from smtpout-1.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id 26A2E1CD33 for ; Tue, 5 Apr 2011 17:56:22 -0500 (CDT) Received: from GJL8710w (office1.championent.net [216.160.45.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-1.iphouse.net (Postfix) with ESMTPSA id B00A61CD32 for ; Tue, 5 Apr 2011 17:56:21 -0500 (CDT) From: "Greg Longtin" To: "hybi" References: <4D99C628.8090409@ericsson.com> <001f01cbf3e1$801dd120$80597360$@net> In-Reply-To: Date: Tue, 5 Apr 2011 17:56:20 -0500 Message-ID: <002001cbf3e4$aea19830$0be4c890$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvz4g02qKzZn5T3Sv6rqTH2MrAaaQAAYGSg Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 22:54:39 -0000 Brian, > > I'm implementing my server to support #1 It's trivial for a packet with one message, gets a little worse for a packet with multiple messages. Using Minefield on v06, and Safari and Chrome 11 on v76 (v00?), I get very few 'combined' messages. Using IE9 with Silverlight, a fair number of packets combining two messages. I'm testing with clients sending messages at a rate of about 30 per second. Thanks, Greg Longtin From gregw@intalio.com Tue Apr 5 16:08:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52663A681B for ; Tue, 5 Apr 2011 16:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 P34zvxh10O7S for ; Tue, 5 Apr 2011 16:08:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 144F53A67F7 for ; Tue, 5 Apr 2011 16:08:27 -0700 (PDT) Received: by vxg33 with SMTP id 33so853938vxg.31 for ; Tue, 05 Apr 2011 16:10:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.65.34 with SMTP id u2mr410377vds.189.1302045010243; Tue, 05 Apr 2011 16:10:10 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Tue, 5 Apr 2011 16:10:10 -0700 (PDT) Date: Wed, 6 Apr 2011 09:10:10 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] WebSocket API 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, 05 Apr 2011 23:08:28 -0000 There is a new draft of the HTML 5 Websocket API available http://dev.w3.org/html5/websockets/ I'm sorry if this is a repeat, but I for one missed any announcement of it. It appears that the work we have done on closing and errors is well reflected in this draft. Does anybody know the browser vendors plans for supporting this API update? cheers From gregw@intalio.com Tue Apr 5 16:22:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4163A69A0 for ; Tue, 5 Apr 2011 16:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mWAAwTA5iwz for ; Tue, 5 Apr 2011 16:22:57 -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 5A4863A699F for ; Tue, 5 Apr 2011 16:22:57 -0700 (PDT) Received: by vws12 with SMTP id 12so876757vws.31 for ; Tue, 05 Apr 2011 16:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.175 with SMTP id dl15mr474004vdb.69.1302045880610; Tue, 05 Apr 2011 16:24:40 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Tue, 5 Apr 2011 16:24:40 -0700 (PDT) In-Reply-To: <385np69jlv63dp4sppebgrf7u9coamkqjt@hive.bjoern.hoehrmann.de> References: <385np69jlv63dp4sppebgrf7u9coamkqjt@hive.bjoern.hoehrmann.de> Date: Wed, 6 Apr 2011 09:24:40 +1000 Message-ID: From: Greg Wilkins To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] Connection-level extensions 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, 05 Apr 2011 23:22:58 -0000 On 6 April 2011 08:51, Bjoern Hoehrmann wrote: > It seems odd to me that everybody is okay with having connection-level > extensions at all, and having the `deflate-stream` extension designed in > this manner in particular. In any case, this should be mentioned promi- > nently in the specification. I'm not OK with it. I think that we should not have anything that changes the framing - not masking, not deflate-stream and certainly not arbitrary x-my-hack extensions. If we want websockets to be a success then we need to encourage a rich eco system in tools, aggregators, offloaders, debuggers, etc. etc. Having non-fixed framing is not helpful for that and will just result in websockets being treated as an opaque stream or blocked. cheers From theturtle32@gmail.com Tue Apr 5 16:24:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8183A67F1 for ; Tue, 5 Apr 2011 16:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoqiGdISsimf for ; Tue, 5 Apr 2011 16:24:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 367723A68D4 for ; Tue, 5 Apr 2011 16:24:31 -0700 (PDT) Received: by iye19 with SMTP id 19so1079603iye.31 for ; Tue, 05 Apr 2011 16:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=ppsXlc3zDD2hdm40xAMYpMh9qAW8tBSjabqQmIMk3D4=; b=jlyxZYZYk+wGxa9Jp3+LKu/1pl3SUeHK8gtrmOLvIdHtu+YqBvHU0WI0cWq4ruQXtp FmF3Mlj1P/SEEznTueriRJvI6623u/OfTylN7wOkJHxVWQuXuAnQmk4WThykGbkM8Cdm 1mXuTZZFcglDU3DfM85l/vq4mIakXe340cbnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=Jazt9NT3VJFOlMU8nPAFOh3tUREqX4A5sqLOmzF5Cl5y1yeUCN3FBwt6IBTmJJy1t3 8IpIVfrOxlV82HTjW+m7mHhGov9gNJVHK7Fk2eCajuT6Onw///L86jMJPUm4jJjgeHgO wnHjieR4Jou09nZ6BZHwevVJsqhYDxM0g5tx8= Received: by 10.42.117.134 with SMTP id t6mr393665icq.459.1302045974516; Tue, 05 Apr 2011 16:26:14 -0700 (PDT) Received: from [10.83.93.187] ([166.205.137.229]) by mx.google.com with ESMTPS id he40sm4777522ibb.67.2011.04.05.16.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 16:26:13 -0700 (PDT) References: <4D99C628.8090409@ericsson.com> <001f01cbf3e1$801dd120$80597360$@net> <002001cbf3e4$aea19830$0be4c890$@net> In-Reply-To: <002001cbf3e4$aea19830$0be4c890$@net> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <353FBCC8-F088-45DE-B730-F13A4C8EDCFC@gmail.com> X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Tue, 5 Apr 2011 16:26:05 -0700 To: Greg Longtin Cc: hybi Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 23:24:32 -0000 =46rom my experience implementing this masking (I presume you're talking abo= ut #1, masking everything including the framing) I don't see any change in d= ifficulty whatsoever relating to handling multiple messages in a single pack= et. I wrote my code to handle that from the beginning. And handling multip= le messages per packet or handling single messages that span multiple packet= s isn't related to the masking in the first place. Have I misunderstood you= ? Brian Sent from my iPhone On Apr 5, 2011, at 3:56 PM, "Greg Longtin" wrote: > Brian, >=20 >>> I'm implementing my server to support #1 >=20 > It's trivial for a packet with one message, gets a little worse for a pack= et > with multiple messages. >=20 > Using Minefield on v06, and Safari and Chrome 11 on v76 (v00?), I get very= > few 'combined' messages. Using IE9 with Silverlight, a fair number of > packets combining two messages. >=20 > I'm testing with clients sending messages at a rate of about 30 per second= . >=20 > Thanks, >=20 > Greg Longtin >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From theturtle32@gmail.com Tue Apr 5 16:25:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493333A68D4 for ; Tue, 5 Apr 2011 16:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMZtHJYFyfWR for ; Tue, 5 Apr 2011 16:25:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 683F73A67A7 for ; Tue, 5 Apr 2011 16:25:42 -0700 (PDT) Received: by iye19 with SMTP id 19so1080399iye.31 for ; Tue, 05 Apr 2011 16:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=tUTsF32Cd4OxmAG7DhJ9eev2S9L3sCmcu5H7EKlsXKg=; b=p2yMT4LHtnuzTGH71oSGXnZDmRLDf3rvJryI2nQEPq0jIPgeZE/Cx4lkwseRdwz5Is qNlvcmOcetHJBWpjfGSu8ni5CDaMUMXM2+dCzEZ+1ASnNxkC2/UNAREbqYRNc2dnUtN0 lsj6cTJWUbSPlgKhtCBBnKLSGfeLycla0BkcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=TxqKZlDygNP8er/YxecwxsJrlz8iCIlltNq+CGnWSOyGKpM7enQpkv+z9nZ7P8kqr3 6V0w794BLwI/EJFBMklamatO0+kyUj5X3H/nJh/TeG14Epx6UZDZm9gTo6kT/cmsiPal 6Dyqx/4zZjTC0L3NwoHd4LICrsbEdt1nWQSkA= Received: by 10.42.131.6 with SMTP id x6mr424820ics.30.1302046044969; Tue, 05 Apr 2011 16:27:24 -0700 (PDT) Received: from [10.83.93.187] ([166.205.137.229]) by mx.google.com with ESMTPS id e9sm1466211ibb.66.2011.04.05.16.27.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 16:27:22 -0700 (PDT) References: <385np69jlv63dp4sppebgrf7u9coamkqjt@hive.bjoern.hoehrmann.de> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <29CF9010-27EF-4748-950C-F61418F53C87@gmail.com> X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Tue, 5 Apr 2011 16:27:14 -0700 To: Greg Wilkins Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Connection-level extensions 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, 05 Apr 2011 23:25:43 -0000 I agree. Brian Sent from my iPhone On Apr 5, 2011, at 4:24 PM, Greg Wilkins wrote: > On 6 April 2011 08:51, Bjoern Hoehrmann wrote: >> It seems odd to me that everybody is okay with having connection-level >> extensions at all, and having the `deflate-stream` extension designed in >> this manner in particular. In any case, this should be mentioned promi- >> nently in the specification. > > I'm not OK with it. > > I think that we should not have anything that changes the framing - > not masking, not deflate-stream and certainly not arbitrary x-my-hack > extensions. > > If we want websockets to be a success then we need to encourage a rich > eco system in tools, aggregators, offloaders, debuggers, etc. etc. > Having non-fixed framing is not helpful for that and will just result > in websockets being treated as an opaque stream or blocked. > > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From gregw@intalio.com Tue Apr 5 16:34:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389FB3A67A7 for ; Tue, 5 Apr 2011 16:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 H8rFDq4CKy0t for ; Tue, 5 Apr 2011 16:34:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 95B103A698E for ; Tue, 5 Apr 2011 16:34:32 -0700 (PDT) Received: by vxg33 with SMTP id 33so867111vxg.31 for ; Tue, 05 Apr 2011 16:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.135 with SMTP id ei7mr435283vdb.229.1302046575851; Tue, 05 Apr 2011 16:36:15 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Tue, 5 Apr 2011 16:36:15 -0700 (PDT) Date: Wed, 6 Apr 2011 09:36:15 +1000 Message-ID: From: Greg Wilkins To: Brian McKelvey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi Subject: [hybi] Implementing masked framing. was: call for feedback on Masking alternatives 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, 05 Apr 2011 23:34:33 -0000 On 6 April 2011 09:26, Brian McKelvey wrote: > From my experience implementing this masking (I presume you're talking ab= out #1, masking everything including the framing) I don't see any change in= difficulty whatsoever relating to handling multiple messages in a single p= acket. =A0I wrote my code to handle that from the beginning. =A0And handlin= g multiple messages per packet or handling single messages that span multip= le packets isn't related to the masking in the first place. =A0Have I misun= derstood you? The main difference for me is that with option #1, the unmasking has to be done in the framing layer and thus has to be concerned with frames fragmented into multiple packets. Thus you have to handle pathological cases of a WS frame arriving asynchronously 1 byte at a time and maintain extra state and buffers accordingly. This is made slightly more complex by the fact that the parser/generators are asymmetric, so masking has to be optional in this code. OK, it is not rocket science and it not even that difficult to get right - but it does represent a blending of concerns and makes the code harder to understand and maintain - and test harnesses are also more complicated as a result. With option #2, masking can be treated like an extension. The parser can work symmetrically to obtain the entire frame and only once all the bytes have been received and parsed do we need to a) move the bytes to user-space b) unmask them. But my support for #2 is not determined by code complexity - rather having a known framing mechanism that is invariant so that we can encourage the development of a rich eco system of 3rd party tools and value add intermediaries. cheers From derhoermi@gmx.net Tue Apr 5 16:41:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAA13A67A7 for ; Tue, 5 Apr 2011 16:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 MeIH83hfCF4g for ; Tue, 5 Apr 2011 16:41:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E85F03A6767 for ; Tue, 5 Apr 2011 16:41:27 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2011 23:43:09 -0000 Received: from dslb-094-222-129-148.pools.arcor-ip.net (EHLO HIVE) [94.222.129.148] by mail.gmx.net (mp051) with SMTP; 06 Apr 2011 01:43:09 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+RgXJdEDqR4YFdoCXceEmy8B8TSUKKiKZMHMGI80 VnhCh6vp41EfhO From: Bjoern Hoehrmann To: Salvatore Loreto Date: Wed, 06 Apr 2011 01:43:26 +0200 Message-ID: References: <4D99C628.8090409@ericsson.com> In-Reply-To: <4D99C628.8090409@ericsson.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] call for feedback on Masking alternatives 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, 05 Apr 2011 23:41:29 -0000 * Salvatore Loreto wrote: >Gabriel and I, as HyBi wg chairs, would like to solicit only those who >have not yet expressed themselves on this issue, to do so now. We have masking to make it easy to explain how cross-protocol attacks are mitigated: attacker-controlled bits are unpredictably masked, so an attacker cannot force interesting byte sequences on the wire. That is the first option in the poll. The second option turns this into "well we kinda hope nothing can be done by letting attackers control some of the bytes, so we allow to control those, but allowing control over too many bytes is kinda bad, so other bytes we allow only very limited control over". There were some interesting discussion how masking interferes with a couple of things, but later this turned "bad protocol design", "lack of options to turn to stronger masking schemes" and a bag of other arguments that I found very uninteresting, to but it that way. My impression is that most people hate this whole masking business so given the chance to ease the pain they vote to do just that, but I do not find that supported by particularily good reasoning. (Others just now vote for the first option because that's what they implemented, which is also poor reasoning giving the effort required to change.) (I do not particularily like the frame layout and extension design in general and would be quite glad to look at ways to make things look less ugly, but I see little reason to consider this for masking in i- solation.) It seems to me that the odds of an attack working diminish with the length of the frame, as such the most crucial part to mask would seem to be the very first bytes, so I do not quite understand why there is no option, if you don't mask the "header" bits, to at least put the mask before the frame header. Well. The second option makes it harder to explain the security properties of the protocol, so, all else the same, that is not my preference. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From theturtle32@gmail.com Tue Apr 5 16:53:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14793A6812 for ; Tue, 5 Apr 2011 16:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlxUKRVyaorw for ; Tue, 5 Apr 2011 16:53:42 -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 EBC223A67E4 for ; Tue, 5 Apr 2011 16:53:41 -0700 (PDT) Received: by qyk7 with SMTP id 7so607034qyk.10 for ; Tue, 05 Apr 2011 16:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=585EkG++ADb1cOhgmxj2RVc67st5yzn9uKCdVYsn9A0=; b=ifVSnnbvbxaN/W8lfn0qEUUjYXaF33qn/nRKbIrFNTVMmXVD05NoGYkbELCrme/ctj UgXeVLbipTfRikmao+SXlo6lv83bCvLLZXc2Fdp+JhLA/WjbeTMyOmLUlMrHh53+I1be nXJOXUEHCegWd1bI07bTj4O+vC/B7NJXL1mn4= 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:content-transfer-encoding; b=rRWpeKIveaar1z2Cude+B/UiTyuQUW1DUmza6NRI+i8hgaSSMYtVHVbkYE60ze1OcL ecWiEH3GtCSKW8RivFIiUs4OigTc5vnMfITCqmZaMDcxb+ZTaXrM506PZWAPeh4kwECh NYmcBZJSnr9AkmsAA8mMZyj39TPx+gp4keZ5U= MIME-Version: 1.0 Received: by 10.224.187.199 with SMTP id cx7mr269694qab.108.1302047725155; Tue, 05 Apr 2011 16:55:25 -0700 (PDT) Received: by 10.224.6.70 with HTTP; Tue, 5 Apr 2011 16:55:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Apr 2011 16:55:25 -0700 Message-ID: From: Brian To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi Subject: Re: [hybi] Implementing masked framing. was: call for feedback on Masking alternatives 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, 05 Apr 2011 23:53:42 -0000 Yes, that's true. My state-based parser checks for the availability of the appropriate number of bytes on the stream buffer at each stage and returns, awaiting another socketData event with more bytes if there is insufficient data. I agree about the extra complexity with regard to having to integrate the masking into the framing parser, I just don't see how that relates to receiving multiple messages in a single packet. Brian On Tue, Apr 5, 2011 at 4:36 PM, Greg Wilkins wrote: > On 6 April 2011 09:26, Brian McKelvey wrote: >> From my experience implementing this masking (I presume you're talking a= bout #1, masking everything including the framing) I don't see any change i= n difficulty whatsoever relating to handling multiple messages in a single = packet. =A0I wrote my code to handle that from the beginning. =A0And handli= ng multiple messages per packet or handling single messages that span multi= ple packets isn't related to the masking in the first place. =A0Have I misu= nderstood you? > > The main difference for me is that with option #1, the unmasking has > to be done in the framing layer and thus has to be concerned with > frames fragmented into multiple packets. =A0Thus you have to handle > pathological cases of a WS frame arriving asynchronously 1 byte at a > time and maintain extra state and buffers accordingly. =A0 This is made > slightly more complex by the fact that the parser/generators are > asymmetric, so masking has to be optional in this code. =A0 =A0OK, it is > not rocket science and it not even that difficult to get right - but > it does represent a blending of concerns and makes the code harder to > understand and maintain - and test harnesses are also more complicated > as a result. > > With option #2, masking can be treated like an extension. =A0The parser > can work symmetrically to obtain the entire frame and only once all > the bytes have been received and parsed do we need to a) move the > bytes to user-space b) unmask them. > > But my support for #2 is not determined by code complexity - rather > having a known framing mechanism that is invariant so that we can > encourage the development of a rich eco system of 3rd party tools and > value add intermediaries. > > cheers > From gregw@intalio.com Tue Apr 5 22:30:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C2E3A6882 for ; Tue, 5 Apr 2011 22:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uq0Ekjv6Ay3 for ; Tue, 5 Apr 2011 22:30:54 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 681BC3A687B for ; Tue, 5 Apr 2011 22:30:53 -0700 (PDT) Received: by qyk29 with SMTP id 29so2117045qyk.10 for ; Tue, 05 Apr 2011 22:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.126.133 with SMTP id c5mr440997qcs.90.1302067956660; Tue, 05 Apr 2011 22:32:36 -0700 (PDT) Received: by 10.229.9.211 with HTTP; Tue, 5 Apr 2011 22:32:36 -0700 (PDT) In-Reply-To: References: <4D99C628.8090409@ericsson.com> Date: Wed, 6 Apr 2011 15:32:36 +1000 Message-ID: From: Greg Wilkins To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] call for feedback on Masking alternatives 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, 06 Apr 2011 05:30:55 -0000 On 6 April 2011 09:43, Bjoern Hoehrmann wrote: > My impression is that most people hate this whole masking business so > given the chance to ease the pain they vote to do just that, but I do > not find that supported by particularily good reasoning. Please don't make sweeping statements regarding the validity of how people have determined their preference in this poll. I think that we are all capable of weighing up the pros and cons of options and making reasoned decisions based on our own experiences and views. Just because somebody weighs the options and comes up with a different preference to you does not mean you should question the validity of their reasoning. > (Others just now vote for the first option because that's what they implemented, > which is also poor reasoning giving the effort required to change.) If somebody does not have strong preference one way or the other, then choosing the option that they have already implemented is an entirely valid and sensible preference. I fully accept that my preferred option is a little weaker with regards to protecting from attacks on intermediaries. But my judgement on all the information provided here is that is only a tiny weakness to a vanishingly small attack vector, which if it ever proves to be a problem can be addressed by numerous other mechanism and thus it is a reasonable price to pay for clear framing and the benefits that brings. Your judgement obviously is different to mine, but I'm not questioning your reasoning - I accept that it must only be because the reason I and others have given are not compelling enough for you. Extend us the same benefit. From julian.reschke@gmx.de Wed Apr 6 00:21:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51E33A68BB for ; Wed, 6 Apr 2011 00:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.459 X-Spam-Level: X-Spam-Status: No, score=-104.459 tagged_above=-999 required=5 tests=[AWL=-1.860, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kXIww4t9Zq9 for ; Wed, 6 Apr 2011 00:21:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 30A373A68C7 for ; Wed, 6 Apr 2011 00:21:16 -0700 (PDT) Received: (qmail invoked by alias); 06 Apr 2011 07:22:58 -0000 Received: from p508FA48F.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.164.143] by mail.gmx.net (mp036) with SMTP; 06 Apr 2011 09:22:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18zKJljWRgzUHiI8qgKOm3R/xf4i8jGMPGRz8hBwJ 1zecTbNo1J/WkO Message-ID: <4D9C14CC.2060308@gmx.de> Date: Wed, 06 Apr 2011 09:22:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: 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 API 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, 06 Apr 2011 07:21:18 -0000 On 06.04.2011 01:10, Greg Wilkins wrote: > There is a new draft of the HTML 5 Websocket API available > > http://dev.w3.org/html5/websockets/ > > I'm sorry if this is a repeat, but I for one missed any announcement > of it. It appears that the work we have done on closing and errors is It's the editor's copy. The latest published draft is from 2009: . > ... Best regards, Julian From andy.warmcat.com@googlemail.com Wed Apr 6 02:04:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE713A68E6 for ; Wed, 6 Apr 2011 02:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1uBshMSSyFQ for ; Wed, 6 Apr 2011 02:04:18 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 739F23A681D for ; Wed, 6 Apr 2011 02:04:18 -0700 (PDT) Received: by wwa36 with SMTP id 36so1018216wwa.13 for ; Wed, 06 Apr 2011 02:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8ykX+9VdDJIfZRYRJSvYW2on/8U24CQeSENAjI5G8N0=; b=nOOOj6559+cdbzkgdUP2pgp8tJuvcKUDFipM8WZ1jWIapyiXkdjf3RRGUTIb70kGOU aScsia0UZ0uOqwnAlwuit+yZWPiik0Ofj6VohmQg+3NshGRSqzv4LY191rzAQttLpMBd TpbQA32ahoj1axjJVhGCprpwwSrBY0BVhqB0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CTBEHTRsxfnfSubGCe74npuOtQz3tEnRWiP6/CK6z0frtxvIJ69o70iwKJJsfifuEr oYAuVMMbp11+UhEX932dDZXfA2Z1iopEp/ESLTQ3MfqGIc+GRAk9/XADNycPhWQDC7MB O7FqJU/dEH8WurFjNl/RxF6uhyrY9oGRvjJIs= Received: by 10.227.10.213 with SMTP id q21mr754782wbq.144.1302080761456; Wed, 06 Apr 2011 02:06:01 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id y12sm213788wby.42.2011.04.06.02.05.59 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 02:06:01 -0700 (PDT) Sender: Andy Green Message-ID: <4D9C2CF6.5020704@warmcat.com> Date: Wed, 06 Apr 2011 10:05:58 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Anthony Catel References: <4D99C628.8090409@ericsson.com> <001f01cbf3e1$801dd120$80597360$@net> <4D9B9AD3.2020101@weelya.com> In-Reply-To: <4D9B9AD3.2020101@weelya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] call for feedback on Masking alternatives 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, 06 Apr 2011 09:04:19 -0000 On 04/05/2011 11:42 PM, Somebody in the thread at some point said: > I also vote for #1 because I'm too lazy to rewrite my code ;) and see no > reason to favor #2 Well you're welcome to your opinion, but about reason to consider #2 you might like to think about what happens in the mux extension. Obviously, it has to put a mux uber-framing around existing websocket content to do the mux action. John's draft allows muxing of already-muxed streams. In the case the websocket framing about length is obscured and #1 stays, muxed content looks like [impenetrable randomness of unknown length unless fully and recursively parsed] -Andy From gezelter@rlgsc.com Wed Apr 6 04:29:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4201B3A691B for ; Wed, 6 Apr 2011 04:29:47 -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 nTr1AF+x48tY for ; Wed, 6 Apr 2011 04:29:45 -0700 (PDT) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id C5B493A685A for ; Wed, 6 Apr 2011 04:29:45 -0700 (PDT) Received: (qmail 22114 invoked from network); 6 Apr 2011 11:31:28 -0000 Received: from unknown (96.235.185.56) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 06 Apr 2011 11:31:28 -0000 Message-ID: <4D9C4F0C.5080504@rlgsc.com> Date: Wed, 06 Apr 2011 06:31:24 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Full Frame Masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:29:47 -0000 It is a measure intended to befuddle pre-existing intermediaries, to wit (from the -06 specification): "4. Data Framing 4.1. Overview In the WebSocket protocol, data is transmitted using a sequence of frames. Frames sent from the client to the server are masked to avoid confusing network intermediaries, such as intercepting proxies. Frames sent from the server to the client are not masked. ..." I see no differential advantage to limiting the masking. Since the key to unmasking the data is contained in the stream, clearly only those intermediaries not cognizant of the WebSocket protocol will be befuddled. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From andy.warmcat.com@googlemail.com Wed Apr 6 04:40:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F8D3A691F for ; Wed, 6 Apr 2011 04:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFMAWnYffsAW for ; Wed, 6 Apr 2011 04:40:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5B6C33A690F for ; Wed, 6 Apr 2011 04:40:50 -0700 (PDT) Received: by wwa36 with SMTP id 36so1128986wwa.13 for ; Wed, 06 Apr 2011 04:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C1QzfWcGTf8/rEUsq+tyLVOjNXooUxOE+Tr8NqhLmVk=; b=RkMQ2WwdN7026VncTuiorEbUGyMpa7t/NZWxrOuKgGWpIrBAfLBoXGkbZuBmMkGBzQ FK4tqbWshZih7UB//DoF+DucBlLWMD3+0BJU7gKqtcGY2yDr0YYYsnDSWvhd1eMmG0CA 416eYR1tiJwuv1ir1pJ89ydaMfoZPx/SzojVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=I+d4yHHUnydirUKGmEsoPZbmbdFb6aioTKBxPfAsaIeQKb2FztL3RfiEqhdiMfVI/R 96PaiPkNibR1IG5I5yx6YZwUos59g1Fx/cke3uj8oCifnV5wbL3ZfhmAkoT+kPV1Z7QL e56wE77KKumt7mG1NSOorMePX8iZjXJkpVW+Q= Received: by 10.227.163.133 with SMTP id a5mr929532wby.73.1302090153324; Wed, 06 Apr 2011 04:42:33 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id x1sm305863wbh.53.2011.04.06.04.42.32 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 04:42:32 -0700 (PDT) Sender: Andy Green Message-ID: <4D9C51A7.2060704@warmcat.com> Date: Wed, 06 Apr 2011 12:42:31 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: gezelter@rlgsc.com References: <4D9C4F0C.5080504@rlgsc.com> In-Reply-To: <4D9C4F0C.5080504@rlgsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 11:40:51 -0000 On 04/06/2011 12:31 PM, Somebody in the thread at some point said: Hi - > I see no differential advantage to limiting the masking. Since the key to > unmasking the data is contained in the stream, clearly only those > intermediaries not cognizant of the WebSocket protocol will be befuddled. You are right. However, that was the reasoning for the munging. The concept is there may exist http intermediaries that do a crappy job and do not understand websockets either. For these guys, it's claimed it may be possible to craft websocket traffic that is valid websocket traffic, but is understood by the broken intermediary to be http, thus poisioning its cache with whatever you like. Further in this scenario, clientside javascript is able to send the websocket traffic with the crafted content. Well, some people believe that and some people don't. The point become moot about what anyone believed when Mozilla pulled websocket support over this issue. Munging the packets so the javascript can't craft the content on the wire was the resulting workaround, really a workaround for getting support pulled from a major browser rather than directly any identifiable, reproducible technical issue. But that issue, Mozilla support, is very real. -Andy From Greg@ChampionEnt.net Wed Apr 6 06:17:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322E328C0F6 for ; Wed, 6 Apr 2011 06:17:47 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ+DVLVzPyLf for ; Wed, 6 Apr 2011 06:17:46 -0700 (PDT) Received: from smtpout-2.iphouse.net (smtpout-2.iphouse.net [209.240.70.141]) by core3.amsl.com (Postfix) with ESMTP id A97AE28C0EA for ; Wed, 6 Apr 2011 06:17:46 -0700 (PDT) Received: from smtpout-2.iphouse.net (localhost [127.0.0.1]) by outbound-clamsmtpd.iphouse.net (Postfix) with ESMTP id E2CDA1CD37 for ; Wed, 6 Apr 2011 08:19:27 -0500 (CDT) Received: from GJL8710w (67-6-89-244.mpls.qwest.net [67.6.89.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpout-2.iphouse.net (Postfix) with ESMTPSA id 7C1081CC86 for ; Wed, 6 Apr 2011 08:19:27 -0500 (CDT) From: "Greg Longtin" To: "hybi" References: <4D99C628.8090409@ericsson.com> In-Reply-To: Date: Wed, 6 Apr 2011 08:19:26 -0500 Message-ID: <000c01cbf45d$415f1f80$c41d5e80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvz6zwE0wUPrHOoSCe1f2zMWC5fKwAbe1YA Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [hybi] call for feedback on Masking alternatives 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, 06 Apr 2011 13:17:47 -0000 Bjoern, > (Others just now vote for the first option because that's what they > implemented, which is also poor reasoning giving the effort required > to change.) > It seems to me that the odds of an attack working I am not familiar with any of the possible attack vectors, nor am I familiar with masking's effect on intermediaries. As an aside, if anyone knows of any good links with 'introductory' material on those subjects, please let me know. My vote was not for "that's what they (I) implemented", but what I assume was a past decision based on good reasoning. Thanks, Greg Longtin From dendicott@gmail.com Wed Apr 6 06:58:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F182C3A69C9 for ; Wed, 6 Apr 2011 06:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKdcOC06Z7E5 for ; Wed, 6 Apr 2011 06:58:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0BFC83A69C5 for ; Wed, 6 Apr 2011 06:58:42 -0700 (PDT) Received: by wwa36 with SMTP id 36so1249487wwa.13 for ; Wed, 06 Apr 2011 07:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UXcfPEGtHDbpovzS/90UDdw64/tmm8R7a4ZHVrgPa6Q=; b=uQWJ4qr5RQn5X0NuxKrOqyOrmcJ6YiiiN6YR7ZweUvikdAhkcevwsOV37I2Bk/LRfi ParVrGOLBz3BV+eTmB6NIGuaNJWb0R/8TU5lc2aWgZ7AlFpwQpvaNfO0qPcOX3udd3Ez Ypo/PjG9acTLrGJYXwk8fyW1mgFdg4C0EC2PU= 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=V92/ppU3QFpUqHXuD2a0Esceg3F5UYXbY7BsDyCKHDSH80U4YyRbj+6j4aymU1nAOO zLLV5nJsJtV/FF8wzbw8ePxS9gGJfGzFcG3zI1D32dl7PqKlpY3amRL3mad/2MHiUuDI IZcabZ0FiahpQuiYKPDPa8Kzc/W2twGz9AeY8= MIME-Version: 1.0 Received: by 10.216.144.86 with SMTP id m64mr1105549wej.32.1302098426191; Wed, 06 Apr 2011 07:00:26 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Wed, 6 Apr 2011 07:00:26 -0700 (PDT) In-Reply-To: <4D9C51A7.2060704@warmcat.com> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> Date: Wed, 6 Apr 2011 10:00:26 -0400 Message-ID: From: David Endicott To: Andy Green Content-Type: multipart/alternative; boundary=0016e6d77f1b27e05604a0406a9a Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 13:58:44 -0000 --0016e6d77f1b27e05604a0406a9a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 7:42 AM, Andy Green wrote: > On 04/06/2011 12:31 PM, Somebody in the thread at some point said: > > Well, some people believe that and some people don't. The point become > moot about what anyone believed when Mozilla pulled websocket support over > this issue. > I thought Mozilla's concern was related to the -75/76 spec that had the "magic-key" in the HTTP body payload of the handshake, but didn't include a "Content-Length" field - thus intermediaries (proxies/firewalls) sometimes would hang, waiting for the HTTP connection to close and end the request. If I'm mistaken and it really was about WS payload masking (and please don't make me spelunk the archives again) then, well, I'll just have to shake my head sadly. In the absence of a demonstrated issue we should have pushed back a little harder. But I understand (and support) the need to get all the major client-agent vendors on board. If we really *are* trying to not upset intermediaries that are doing traffic inspection then we probably should mask in both directions, shouldn't we? (Of course, I stand by my opinion that once the TCP connection has been established via the HTTP Upgrade handshake, any intermediary that confuses itself with traffic on that pipe is a broken intermediary and not our concern.) --0016e6d77f1b27e05604a0406a9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 6, 2011 at 7:42 AM, Andy Green <= span dir=3D"ltr"><andy@warmcat.com> wrote:
On 04/06/2011 12:31 PM, Somebody in the thread at some point said:
=A0
Well, some people bel= ieve that and some people don't. =A0The point become moot about what an= yone believed when Mozilla pulled websocket support over this issue.

I thought Mozilla's concern was relate= d to the -75/76 spec that had the "magic-key" in the HTTP body pa= yload of the handshake, but didn't include a "Content-Length"= field - thus intermediaries (proxies/firewalls) sometimes would hang, wait= ing for the HTTP connection to close and end the request. =A0

If I'm mistaken and it really was about WS payload = masking (and please don't make me spelunk the archives again) then, wel= l, I'll just have to shake my head sadly. =A0 In the absence of a demon= strated issue we should have pushed back a little harder. =A0 But I underst= and (and support) the need to get all the major client-agent vendors on boa= rd.

If we really *are* trying to not upset intermediaries t= hat are doing traffic inspection then we probably should mask in both direc= tions, shouldn't we?

(Of course, I stand by my= opinion that once the TCP connection has been established via the HTTP Upg= rade handshake, any intermediary that confuses itself with traffic on that = pipe is a broken intermediary and not our concern.)


--0016e6d77f1b27e05604a0406a9a-- From andy.warmcat.com@googlemail.com Wed Apr 6 07:15:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369AC28C112 for ; Wed, 6 Apr 2011 07:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqaxAvFlThXH for ; Wed, 6 Apr 2011 07:15:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0A9EF28C0DB for ; Wed, 6 Apr 2011 07:15:30 -0700 (PDT) Received: by wyb29 with SMTP id 29so1480836wyb.31 for ; Wed, 06 Apr 2011 07:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=reeIyl75F3MIMOYMu+epysqo7LDvXVO3jKztoKeKJ/g=; b=Ch4t9fNuYvwZbYWO8SyfLH4ks91TvC7mgWoTm7daVoCjEZUT2iJIV7ZiJezFikre7Z 8IGnfgBbQb7zwp1poE8pw8ME4grp8LhqcAqIx6y9czaQOXHSKeJPrcvivT00f4BaUvXa V2XET63REsglF3BRYRHgo2p9rCfDvqQxs7ljQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wXB7WxMPNeEdzGBmZtVlVjpUa8aaZi1CejukA9ehAKisjMZB9WLKe5HBslRvw8vDmh lQBjemKT3YoFfRNPUcV1N4d8BFZW/CDV2Lb4mHS6Vyj7Ix0Dsftb4DeUsZki0WXvWZGU jwlfKAOH3CbE9CJJOnF/Wi/orbfYXgXeluJW0= Received: by 10.227.139.14 with SMTP id c14mr1131982wbu.55.1302099434185; Wed, 06 Apr 2011 07:17:14 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id h11sm402335wbc.9.2011.04.06.07.17.11 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 07:17:12 -0700 (PDT) Sender: Andy Green Message-ID: <4D9C75E6.5050604@warmcat.com> Date: Wed, 06 Apr 2011 15:17:10 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Endicott References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 14:15:32 -0000 On 04/06/2011 03:00 PM, Somebody in the thread at some point said: Hi - > I thought Mozilla's concern was related to the -75/76 spec that had the > "magic-key" in the HTTP body payload of the handshake, but didn't > include a "Content-Length" field - thus intermediaries > (proxies/firewalls) sometimes would hang, waiting for the HTTP > connection to close and end the request. > > If I'm mistaken and it really was about WS payload masking (and please > don't make me spelunk the archives again) then, well, I'll just have to > shake my head sadly. In the absence of a demonstrated issue we should > have pushed back a little harder. But I understand (and support) the > need to get all the major client-agent vendors on board. http://news.cnet.com/8301-30685_3-20025272-264.html Still waiting to hear which brand of proxy is meant to experience this or hear it is reproduced. Frankly it's a bit like it suits everyone to not to try to reproduce it in case the lack of results might be embarrassing. > If we really *are* trying to not upset intermediaries that are doing > traffic inspection then we probably should mask in both directions, > shouldn't we? The hysteria was all about the specific claim, so they only considered that a proxy might be fooled into seeing a GET from its client side. > (Of course, I stand by my opinion that once the TCP connection has been > established via the HTTP Upgrade handshake, any intermediary that > confuses itself with traffic on that pipe is a broken intermediary and > not our concern.) No argument from me. But what is clear is that this is now baked into the history of the protocol there is no point arguing against it once you realize it is not there for technical reasons. One way to look at it is we are better off reaching a successful conclusion of the spec with this 'spec parasite' thing in it than destabilizing the group pointlessly and delaying or destroying the whole effort to try to get rid of it. (At one point they wanted AES encryption which would have rendered the whole protocol out of reach of weak targets, but actually the recycling XOR frame key is just annoying, not deadly.) -Andy From dendicott@gmail.com Wed Apr 6 07:59:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1A228C11A for ; Wed, 6 Apr 2011 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBo2oHAOW7PC for ; Wed, 6 Apr 2011 07:59:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D8FCA28C0FD for ; Wed, 6 Apr 2011 07:59:43 -0700 (PDT) Received: by wwa36 with SMTP id 36so1307539wwa.13 for ; Wed, 06 Apr 2011 08:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5XKZ7OsWnSvLXHlfNvqGpBJVqwUN4EYe530Z70kOhJE=; b=t2ldWM1mSvuv9+fVFINF55i5mehUCKfv3p1/x9kxPn/eyWcMAumHhcSQvcLWKcIH/h zEGkYwMW3hUzkNZd9rek/BvZwFCDdf5lE1lRhwmMMo2utB0efmcz+xoJEbxyyqY4I51c k4ahEEMHAmpSHtdxn/CgLAEnXNfdXLCVe87Wc= 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=bIsMtc0+268GDALIkEffOfhC2gHfvjix+dGsF3U1mrBZ3dvERE0204PxIVIA63ZmZO bh/ec7RdSDwmujmbGWKUlPXsOlhtcSMTb3X6s/gpxE+CBeq8MVp6sZTZ6YdqzlGLYxx1 AcQ0IrABF4wpMNA2LUYtP5ffQd/S4yvNpTwz4= MIME-Version: 1.0 Received: by 10.216.143.134 with SMTP id l6mr6702317wej.2.1302102087159; Wed, 06 Apr 2011 08:01:27 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Wed, 6 Apr 2011 08:01:27 -0700 (PDT) In-Reply-To: <4D9C75E6.5050604@warmcat.com> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> Date: Wed, 6 Apr 2011 11:01:27 -0400 Message-ID: From: David Endicott To: Andy Green Content-Type: multipart/alternative; boundary=0016e6ddfee45dd0c704a041448c Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 14:59:45 -0000 --0016e6ddfee45dd0c704a041448c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 10:17 AM, Andy Green wrote: > On 04/06/2011 03:00 PM, Somebody in the thread at some point said: > > If I'm mistaken and it really was about WS payload masking (and please >> > > http://news.cnet.com/8301-30685_3-20025272-264.html > > Still waiting to hear which brand of proxy is meant to experience this or > hear it is reproduced. Frankly it's a bit like it suits everyone to not to > try to reproduce it in case the lack of results might be embarrassing. *"We don't demand solid facts. What we demand is a total absence of solid facts. I demand that I may, or may not, be Vroomfondel."* > > (Of course, I stand by my opinion that once the TCP connection has been... >> > > No argument from me. But what is clear is that this is now baked into the > history of the protocol there is no point arguing against it once you > realize it is not there for technical reasons. > > One way to look at it is we are better off reaching a successful conclusion > of the spec with this 'spec parasite' thing in it than destabilizing the > group pointlessly and delaying or destroying the whole effort to try to get > rid of it. (At one point they wanted AES encryption which would have > rendered the whole protocol out of reach of weak targets, but actually the > recycling XOR frame key is just annoying, not deadly.) > > Agreed. I'm highly motivated to have a workable final spec. completed, warts or no warts. I'm willing to let any aspect of the spec. pass if it doesn't impair functionality. (Hence my discomfort with the close commingling/overlap of HTTP Upgrade & WS handshake as I think it impairs functionality). On the other hand, things like Sec-Websocket-Key and frame masking are, in my opinion, useless. But since it's mostly harmless, I don't care and it's implementable easily enough. I have a young daughter and if she wants an asynchronous interactive Elmo, then gosh darn-it, I'm going to help make that happen. Oh, and ya, my employers have been waiting years for "server-push" to the browser, but whatever. --0016e6ddfee45dd0c704a041448c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 6, 2011 at 10:17 AM, Andy Gr= een <andy@warmcat.= com> wrote:
On 04/06/2011 03:00 PM, Somebody in the thread at some point said:

If I'm mistaken an= d it really was about WS payload masking (and please
=
=A0
http://news.cnet.com/8301-30685_3-20025272-264.html

Still waiting to hear which brand of proxy is meant to experience this or h= ear it is reproduced. =A0Frankly it's a bit like it suits everyone to n= ot to try to reproduce it in case the lack of results might be embarrassing= .

"We = don't demand solid facts. What we demand is a total absence of solid fa= cts. I demand that I may, or may not, be Vroomfondel."
=A0

(Of course, I stand by my opinion that once the TCP connection has been...<= br>
=A0
No argument from me. =A0But what is clear is that this is now baked into th= e history of the protocol there is no point arguing against it once you rea= lize it is not there for technical reasons.

One way to look at it is we are better off reaching a successful conclusion= of the spec with this 'spec parasite' thing in it than destabilizi= ng the group pointlessly and delaying or destroying the whole effort to try= to get rid of it. =A0(At one point they wanted AES encryption which would = have rendered the whole protocol out of reach of weak targets, but actually= the recycling XOR frame key is just annoying, not deadly.)

=
Agreed. =A0I'm highly motivated to have a workable final spec. com= pleted, warts or no warts.=A0

I'm willing to l= et any aspect of the spec. pass if it doesn't impair functionality. =A0= (Hence my discomfort with the close=A0commingling/overlap=A0of HTTP Upgrade= & WS handshake as I think it impairs functionality). =A0 =A0On the oth= er hand, things like Sec-Websocket-Key and frame masking are, in my=A0opini= on, useless. =A0 But since it's mostly harmless, I don't care and i= t's implementable easily enough.

I have a young daughter and if she wants an asynchronou= s interactive Elmo, then gosh=A0darn-it, I'm going to help make that ha= ppen. =A0 =A0Oh, and ya, my employers have been waiting years for "ser= ver-push" to the browser, but whatever.

--0016e6ddfee45dd0c704a041448c-- From jat@google.com Wed Apr 6 08:15:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6C528C0DB for ; Wed, 6 Apr 2011 08:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.928 X-Spam-Level: X-Spam-Status: No, score=-105.928 tagged_above=-999 required=5 tests=[AWL=0.048, 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 rynvZjtvs1ze for ; Wed, 6 Apr 2011 08:15:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 19DFC28B23E for ; Wed, 6 Apr 2011 08:15:09 -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 p36FGqNH000314 for ; Wed, 6 Apr 2011 08:16:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302103012; bh=obVT6MKK8VUK2bCBUipDR0GaFAE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GTpnWIgglTdBhPCUagj7K2ATFKlKi/rAjarAWQZrJYxRPM6qGi483KbA2CR5ouQ5P 57aNMFKb3zoEcYQf2bbdg== Received: from yie16 (yie16.prod.google.com [10.243.66.16]) by wpaz33.hot.corp.google.com with ESMTP id p36FGpMN024697 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 08:16:51 -0700 Received: by yie16 with SMTP id 16so636726yie.30 for ; Wed, 06 Apr 2011 08:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NOSJ7sTU59dMI7wXoJ4Do30J39hwfZQFAK8+r042I2s=; b=IOk5AimrbcRt2tc/IVVQKUwBeya7bnbb0lmdWomFtpJWp7MY0hBktLnwHSLjUfjUYX 1YszF6HFXvyOpctWYxvQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kSYpbndaxc8xbJGF5Dn3686Oy97hxxdm2T2nxw1xm05mnRr0gxuBnwH9X7miSXbS7O Wzt+kl7TTPWSq8yB4wKw== Received: by 10.150.69.30 with SMTP id r30mr1920534yba.124.1302103011155; Wed, 06 Apr 2011 08:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Wed, 6 Apr 2011 08:16:31 -0700 (PDT) In-Reply-To: <4D9C75E6.5050604@warmcat.com> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> From: John Tamplin Date: Wed, 6 Apr 2011 11:16:31 -0400 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=000e0cd5919670e1bf04a0417b78 X-System-Of-Record: true Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 15:15:09 -0000 --000e0cd5919670e1bf04a0417b78 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 6, 2011 at 10:17 AM, Andy Green wrote: > Still waiting to hear which brand of proxy is meant to experience this or > hear it is reproduced. Frankly it's a bit like it suits everyone to not to > try to reproduce it in case the lack of results might be embarrassing. The nature of a transparent proxy means it can be hard to even detect its presence, let alone what brand and software version it is. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5919670e1bf04a0417b78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 6, 2011 at 10:17 AM, Andy Green <andy@warmcat.com&= gt; wrote:
Still waiting to hear which brand of proxy is meant to experience this or h= ear it is reproduced. =C2=A0Frankly it's a bit like it suits everyone t= o not to try to reproduce it in case the lack of results might be embarrass= ing.

The nature of a transparent proxy means it can be hard = to even detect its presence, let alone what brand and software version it i= s.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), = Google
--000e0cd5919670e1bf04a0417b78-- From dendicott@gmail.com Wed Apr 6 08:44:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE3F3A68CF for ; Wed, 6 Apr 2011 08:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKon3192NWjV for ; Wed, 6 Apr 2011 08:44:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 013FD3A6819 for ; Wed, 6 Apr 2011 08:44:00 -0700 (PDT) Received: by ewy19 with SMTP id 19so586346ewy.31 for ; Wed, 06 Apr 2011 08:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4Vn2o3dGD/L1aJN/O6P+nbYLWGXJxReDwZL1L3nFmT0=; b=XEEI+1o4rmGijYZ/X/LPqPyBIu68MevZ9/2KkV/Ao1dH26dQpsLsRfHEVj4Q6LutP5 PvC74xOIBtmqeZi5z45Txbp5lEle2Bw+Z1gPwkr2TG96AS3S6tlz2Aq0GzN/+sL44HFV C/Fm4byHc+QouupTyopFdXref1QmGRvYq1DMU= 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=C0o9DQYrTITYt52jzOkPm2raxkWvrb6E+TC3icdsGiJULJFR6iXEI7Qrur9OrzpLdG 03/NxCW+V2kasWyLhgbx+3fc8GOgofER7NPrIHCR3hHfJZs9zrEeaxsPc462wH8L/0nm 15iNz2vTRHLbUP5Tcv8YA6E6WzMvZRBQQvfcE= MIME-Version: 1.0 Received: by 10.216.143.134 with SMTP id l6mr6753886wej.2.1302104743885; Wed, 06 Apr 2011 08:45:43 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Wed, 6 Apr 2011 08:45:43 -0700 (PDT) In-Reply-To: References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> Date: Wed, 6 Apr 2011 11:45:43 -0400 Message-ID: From: David Endicott To: John Tamplin Content-Type: multipart/alternative; boundary=0016e6ddfee4b83d5a04a041e2b9 Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 15:44:02 -0000 --0016e6ddfee4b83d5a04a041e2b9 Content-Type: text/plain; charset=ISO-8859-1 Has anyone demonstrated an actual instance of a problem so far, either as revealed during WS implementation testing or from targeted vulnerability assessment? Does anyone have a suspicion that a particular vendor's product might be at risk? (Not snark, just curiosity.) On Wed, Apr 6, 2011 at 11:16 AM, John Tamplin wrote: > On Wed, Apr 6, 2011 at 10:17 AM, Andy Green wrote: > >> Still waiting to hear which brand of proxy is meant to experience this or >> hear it is reproduced. Frankly it's a bit like it suits everyone to not to >> try to reproduce it in case the lack of results might be embarrassing. > > > The nature of a transparent proxy means it can be hard to even detect its > presence, let alone what brand and software version it is. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --0016e6ddfee4b83d5a04a041e2b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Has anyone demonstrated an actual instance of a problem so far, either as r= evealed during WS implementation testing or from targeted vulnerability=A0a= ssessment? =A0 =A0

Does anyone have a=A0suspicion=A0that= a particular vendor's product might be at risk? =A0 =A0

(Not snark, just curiosity.)


On Wed, Apr 6, 2011 at 11:16 AM, John Tamplin <= ;jat@google.com> wrote:
=
On Wed, Apr 6, 2011 at 10:17 A= M, Andy Green <andy@warmcat.com> wrote:
Still waiting to hear which brand of proxy is meant to experience this or h= ear it is reproduced. =A0Frankly it's a bit like it suits everyone to n= ot to try to reproduce it in case the lack of results might be embarrassing= .

The nature of a transparent proxy means it can be= hard to even detect its presence, let alone what brand and software versio= n it is.=A0

--
John A. Tamplin Software Engineer (GWT), Google

--0016e6ddfee4b83d5a04a041e2b9-- From bruce@callenish.com Wed Apr 6 10:35:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BE73A695C for ; Wed, 6 Apr 2011 10:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 r2Fi0bfPEC7N for ; Wed, 6 Apr 2011 10:35:54 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 0ABB43A6957 for ; Wed, 6 Apr 2011 10:35:54 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q7Wfh-0000Er-6E for hybi@ietf.org; Wed, 06 Apr 2011 10:37:37 -0700 Message-ID: <4D9CA4E1.70409@callenish.com> Date: Wed, 06 Apr 2011 10:37:37 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: [hybi] Arguments in the FAQ 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, 06 Apr 2011 17:35:54 -0000 I have an issue with the FAQ that I would appreciate some guidance from the WG on. I have noted at the top of the FAQ that it is intended that it describe the state of the protocol as it currently exists and how it got that way. I do not believe it is intended as a platform for debate concerning whether a particular choice is a good one. The FAQ is an extremely poor platform for that purpose. The people who can most likely respond to the issues raised and perhaps be persuaded by the arguments are unlikely to be the ones to read it. The ones who are most likely to want to read the FAQ are only going to be confused by arguments that are irrelevant to the protocol as it now exists. The FAQ is supposed to clarify the protocol for them. Given that, I intend to delete any such debating points that are raised in the FAQ unless the WG instructs me otherwise. I am about to do so now on the question asking why SHA-1 is used for hashing. IMNSHO contributions that more fully explain why SHA-1 was selected are welcome. Changes arguing for a different approach are ones that should be deleted. So that the argument can be given in its appropriate place, I will start another thread on the mailing list that includes the FAQ and the debating points that will be deleted. But this thread concerns whether there is support for my cleaning up the FAQ in this way. From bruce@callenish.com Wed Apr 6 10:38:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1041D3A69B4 for ; Wed, 6 Apr 2011 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.015, 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 m09LcAYPRjjX for ; Wed, 6 Apr 2011 10:38:43 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 1BBF53A6957 for ; Wed, 6 Apr 2011 10:38:43 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q7WiQ-0002gg-EP for hybi@ietf.org; Wed, 06 Apr 2011 10:40:26 -0700 Message-ID: <4D9CA58A.8010400@callenish.com> Date: Wed, 06 Apr 2011 10:40:26 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------030203030200080301070903" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: [hybi] Why was SHA-1 chosen as hashing method? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:38:44 -0000 This is a multi-part message in MIME format. --------------030203030200080301070903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit /Here is the question and original answer from the FAQ:/ *Why is SHA-1 necessary? How about simple math like multiplication or CRC* SHA-1 was deemed a reasonable approach to getting a hash value that is very unlikely to collide with another. Implementations are widely available in many languages, and since the calculation is done only at the beginning of the connection, the cost was seen as minimal enough not to cause any concerns especially compared to other elements of setting up a connection. See: Dave's comment [http://www.ietf.org/mail-archive/web/hybi/current/msg06598.html] Common, verifiable and very unlikely to clash /And here is the debate that was added:/ -- Follow-up question to this answer: is the plus operator uncommon? Unverifiable? Likely to clash? == Are you really arguing that for a simple web-socket implementation, the developer will HAVE to include a library implementing bignum types and SHA1 algorithm, instead of using simple math, such as addition ("+" operator), such as available in any computer language ? What languages does the "implementations are widely available in many languages" argument refer to? Is requirement of loading a crypto library in a websocket server just for the handshake considered "minimal cost"? == What "clash" is Dave talking about in the comment linked? Given number A from client and number B from server, check that the C=function(A,B) calculated on server matches with C=function(A,B) calculated on client. The function can be addition ("+" C operator), mod-multiplication ("*","%" C operators) or any other simple function. There's no requirement for hash-style one way functions. Why add complexity? --------------030203030200080301070903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is the question and original answer from the FAQ:

Why is SHA-1 necessary? How about simple math like multiplication or CRC

SHA-1 was deemed a reasonable approach to getting a hash value that is very unlikely to collide with another. Implementations are widely available in many languages, and since the calculation is done only at the beginning of the connection, the cost was seen as minimal enough not to cause any concerns especially compared to other elements of setting up a connection.

See:
    Dave's comment [http://www.ietf.org/mail-archive/web/hybi/current/msg06598.html]
        Common, verifiable and very unlikely to clash

And here is the debate that was added:

-- Follow-up question to this answer: is the plus operator uncommon? Unverifiable? Likely to clash?

== Are you really arguing that for a simple web-socket implementation, the developer will HAVE to include a library implementing bignum types and SHA1 algorithm, instead of using simple math, such as addition ("+" operator), such as available in any computer language ? What languages does the "implementations are widely available in many languages" argument refer to? Is requirement of loading a crypto library in a websocket server just for the handshake considered "minimal cost"?

== What "clash" is Dave talking about in the comment linked? Given number A from client and number B from server, check that the C=function(A,B) calculated on server matches with C=function(A,B) calculated on client. The function can be addition ("+" C operator), mod-multiplication ("*","%" C operators) or any other simple function. There's no requirement for hash-style one way functions. Why add complexity?

--------------030203030200080301070903-- From jamie@shareable.org Wed Apr 6 11:17:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCE428C10E for ; Wed, 6 Apr 2011 11:17: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 mty1yOZiLgbB for ; Wed, 6 Apr 2011 11:17:51 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id CF45228C0D6 for ; Wed, 6 Apr 2011 11:17:50 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7XK0-0005fN-4A; Wed, 06 Apr 2011 19:19:16 +0100 Date: Wed, 6 Apr 2011 19:19:16 +0100 From: Jamie Lokier To: Dave Cridland Message-ID: <20110406181915.GE26912@shareable.org> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <15466.1301949097.229241@puncture> <20110405052652.GF21300@1wt.eu> <2714.1301991013.050661@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2714.1301991013.050661@puncture> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Server-Initiated HTTP Subject: Re: [hybi] Robert Gezelter on the current spec 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, 06 Apr 2011 18:17:51 -0000 Dave Cridland wrote: > >On the server side, the point does not exist because you're not > >limited by the number of ports, you can accept up to 64k > >connections per source IP address and per destination address. > > > Right. As I say, he posits a case where there is a SNAT at the server > farm on inbound connections. Or, possibly, a DNAT performing IP-level > load balancing. I have to admit I found this text confusing as well - > the latter seems much more likely to exist, so I can only assume > that's what he meant. SNAT is needed when you have multiple entry points, typically for geographic or link diversity, such as 'anycasting' or multi-homing over more than one router, forwarding to shared server(s) behind. SNAT is needed so the outgoing reply packets go back through the same router, otherwise they're blocked by router-local NAT state. The 64k port limit can easily hit in that scenario, even with diverse web clients, but you can overcome it by SNATing from per-router pools of internal IP addressses. You may need rather large IP pools (hundreds/thousands) to handle large client numbers. -- Jamie From jamie@shareable.org Wed Apr 6 12:44:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242AE3A6774 for ; Wed, 6 Apr 2011 12:44:36 -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 6WHXaOaak3kt for ; Wed, 6 Apr 2011 12:44:35 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id E2E343A696F for ; Wed, 6 Apr 2011 12:44:34 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7Yfz-0005z0-2h; Wed, 06 Apr 2011 20:46:03 +0100 Date: Wed, 6 Apr 2011 20:46:03 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20110406194602.GF26912@shareable.org> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110404182625.GD20671@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 06 Apr 2011 19:44:36 -0000 Willy Tarreau wrote: > It seems the guy did not understand the goal of the closing handshake. He > understood that it was in order to replace the TCP closing handshake while > the real goal was to let the remote side know if the close was expected or > not (TCP close without WS close indicates it comes from an intermediary, > and automatic reconnection might be desirable in some cases). As I recall, your reason isn't the real goal either! I recall it being to prevent the TCP reset-on-close hazard, not to distinguish endpoint vs. intermediary closes. TCP implementations drop all buffered data, in _both_ directions, on receiving TCP RST, and TCP RST is sent when data is received to a closed socket. The WS close is to prevent that during normal error-free operation when one side closes an idle or finished connection. For example, when sending a message followed by WS close, the other end gets that message. With TCP close, there is a chance the message (or even multiple ones) before close will be lost or truncated before the other end sees them. And messages sent in the opposite direction at the wrong moment can also be lost or truncated, unexpected to the sender, and without it knowing how much the receiver got. Some HTTP servers use TCP half-close for a similar reason (even though it's not in the spec - see Apache code). That was considered for WS and discarded, as it's not reliable with HTTP intermediaries and symmetric protocols. The WS close also allows idle/finished close (normal operation) to be distinguished from network error (should be rare & referred upwards), so automatic retry decisions are easier - you would safely, quietly & *immediately* retry a WS message on idle close, and be confident the message won't be seen twice, but on network error you would be more cautious, retrying after a delay, trying a different server, checking for duplicates etc. Again this is because of TCP RST, which looks like a network error, but could arise from idle/finished close if there was no close handshake. The problem of detecting lost messages on idle receiver close also happens in HTTP, and is why HTTP clients generally avoid sending POST requests on a persistent or pipelined connection. It remains to be seen if the WS close mechanism proves dependable, especially if intermediaries cause the same TCP RST problem by randomly closing connections themselves anyway. If WS close works, great, if not, robust WS applications will need their own reliable messaging layer on top of WS anyway, and WS close will only help the less robust ones be a little bit better. > His pause/resume mechanism is what I normally call flow control. It might > be nice to study the idea, though it can have huge security impacts as it > has on Ethernet and TCP (easy DoSes). Note that per-channel flow control is essential for safe & secure multiplexing. If it is omitted, either the flows aren't independent (head of line blocking), or a memory DOS is possible (demuxer has to read & buffer eagerly without bound). Either way makes application-independent multiplexing unsafe, and the former can lead to deadlocks; flow control solves both problems. This is especially important for "invisible" multiplexing inside the browser and/or intermediaries. _Not_ having flow control when you have multiplexing can have huge security impacts including DOSes and deadlocks... -- Jamie From jat@google.com Wed Apr 6 12:49:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64B03A697A for ; Wed, 6 Apr 2011 12:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.929 X-Spam-Level: X-Spam-Status: No, score=-105.929 tagged_above=-999 required=5 tests=[AWL=0.047, 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 WjDo1TCvc85S for ; Wed, 6 Apr 2011 12:49:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DFAC93A696F for ; Wed, 6 Apr 2011 12:49:39 -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 p36JpNnM010051 for ; Wed, 6 Apr 2011 12:51:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302119483; bh=wfiYzNNFTMLVvpdGRz84h45W0h8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=oZg8qfFpWVDKpiXda+KYG6fMZxj2jVXhORa1DVQw6dYm150Ylw/LnEpH6NOTJkdT2 oyLLhQO9Wo58EsBkYD5gQ== Received: from gwb1 (gwb1.prod.google.com [10.200.2.1]) by wpaz37.hot.corp.google.com with ESMTP id p36JpMxn011192 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 12:51:22 -0700 Received: by gwb1 with SMTP id 1so809904gwb.22 for ; Wed, 06 Apr 2011 12:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M25iQn6or3UDxSdaFtlYejJ4pwl72pqxN7XwglxQXkM=; b=Wor3FMEUsAjazmQv9v5i1GCXLxoNeLzVdahg8JWxC1/2hj4X+4qu6g5GJa1zUBtgf0 wHZuyIB8XtykXW66+FfQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lsgbRAACRBYsJCmFnmxHtkNeQYxinEExfh/C0hEWByWAc6mPn2zJCKCDh2Y0OOYhLz eZJYCy0QKRM10IYnpXiQ== Received: by 10.150.255.2 with SMTP id c2mr9472ybi.409.1302119482109; Wed, 06 Apr 2011 12:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Wed, 6 Apr 2011 12:51:02 -0700 (PDT) In-Reply-To: <20110406194602.GF26912@shareable.org> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <20110406194602.GF26912@shareable.org> From: John Tamplin Date: Wed, 6 Apr 2011 15:51:02 -0400 Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=000e0cd6d0822faff004a04551e6 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 06 Apr 2011 19:49:40 -0000 --000e0cd6d0822faff004a04551e6 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 6, 2011 at 3:46 PM, Jamie Lokier wrote: > > His pause/resume mechanism is what I normally call flow control. It might > > be nice to study the idea, though it can have huge security impacts as it > > has on Ethernet and TCP (easy DoSes). > > Note that per-channel flow control is essential for safe & secure > multiplexing. If it is omitted, either the flows aren't independent > (head of line blocking), or a memory DOS is possible (demuxer has to > read & buffer eagerly without bound). Either way makes > application-independent multiplexing unsafe, and the former can lead > to deadlocks; flow control solves both problems. This is especially > important for "invisible" multiplexing inside the browser and/or > intermediaries. > > _Not_ having flow control when you have multiplexing can have huge > security impacts including DOSes and deadlocks... > Right, but it isn't clear you have to have that in the base protocol, rather than just in the multiplexing extension. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6d0822faff004a04551e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 6, 2011 at 3:46 PM, Jamie Lokier <jamie@shareable.o= rg> wrote:
> His pause/resume mechanism is what I normally call f= low control. It might
> be nice to study the idea, though it can have huge security impacts as= it
> has on Ethernet and TCP (easy DoSes).

Note that per-channel flow control is essential for safe & secure=
multiplexing. =C2=A0If it is omitted, either the flows aren't independe= nt
(head of line blocking), or a memory DOS is possible (demuxer has to
read & buffer eagerly without bound). =C2=A0Either way makes
application-independent multiplexing unsafe, and the former can lead
to deadlocks; flow control solves both problems. =C2=A0This is especially important for "invisible" multiplexing inside the browser and/or<= br> intermediaries.

_Not_ having flow control when you have multiplexing can have huge
security impacts including DOSes and deadlocks...

Right= , but it isn't clear you have to have that in the base protocol, rather= than just in the multiplexing extension.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd6d0822faff004a04551e6-- From jamie@shareable.org Wed Apr 6 12:53:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A443A6980 for ; Wed, 6 Apr 2011 12:53:48 -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=[AWL=0.000, 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 mz0uxlExxqYJ for ; Wed, 6 Apr 2011 12:53:47 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 61B3D3A67DA for ; Wed, 6 Apr 2011 12:53:47 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7Yp5-00061f-JP; Wed, 06 Apr 2011 20:55:27 +0100 Date: Wed, 6 Apr 2011 20:55:27 +0100 From: Jamie Lokier To: David Endicott Message-ID: <20110406195527.GG26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.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, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 19:53:48 -0000 David Endicott wrote: > Oh, and ya, my employers have been waiting years for > "server-push" to the browser, but whatever. People have done that for about 12 years over HTTP, so WebSocket does not add new functionality here. It's just an optimisation, and in many cases, WebSocket will be slotted into an existing framework that already works over HTTP (assuming WS works better). -- Jamie From fenix@google.com Wed Apr 6 12:55:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9583A67DA for ; Wed, 6 Apr 2011 12:55:15 -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 vE6Mu4dCyTEC for ; Wed, 6 Apr 2011 12:55:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A141E3A6980 for ; Wed, 6 Apr 2011 12:55:10 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p36JusDf000328 for ; Wed, 6 Apr 2011 12:56:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302119814; bh=ae3farJZFbFiqKMzzzhnw5u7C2Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=iIIxOFL9iQWvOF4u6+gSLPxE2tlCbu0jlBVeb1lsKpYFAyZlJ1t0dhg/LDrCzgShM zQWYuHROBWquuYF1NlObg== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by kpbe14.cbf.corp.google.com with ESMTP id p36JuUxN011318 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 12:56:53 -0700 Received: by gwb11 with SMTP id 11so763450gwb.20 for ; Wed, 06 Apr 2011 12:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s4jnIqA0QlKVk34pGmCl5N7q7tnxu9fpj26qs7Ar7i4=; b=E/Vn69R1wB016ZtMoOGSsN+v6qKASlPD4IQ2QhJY6bH1Oi5MJByrD3E+wmNrj3ZT6z bfcg6hIk1WmKq3aILBoA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kHwZlapYCxvoiNXyU8OEwM/crCzyGY4ly3qN+DCaMeEcRRDGeS8Fkz4aJlUh41OjfX 7ECxcM4pWc30odX8uikA== MIME-Version: 1.0 Received: by 10.150.72.7 with SMTP id u7mr38415yba.75.1302119812686; Wed, 06 Apr 2011 12:56:52 -0700 (PDT) Received: by 10.150.182.9 with HTTP; Wed, 6 Apr 2011 12:56:52 -0700 (PDT) In-Reply-To: <20110406195527.GG26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> Date: Wed, 6 Apr 2011 12:56:52 -0700 Message-ID: From: Roberto Peon To: Jamie Lokier Content-Type: multipart/alternative; boundary=000e0cd58e68e3e35304a04564e1 X-System-Of-Record: true Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 19:55:16 -0000 --000e0cd58e68e3e35304a04564e1 Content-Type: text/plain; charset=ISO-8859-1 Server push over HTTP? We have poor emulations of it, but we've never had it in HTTP. What are you thinking about w.r.t. server push Jamie? -=R On Wed, Apr 6, 2011 at 12:55 PM, Jamie Lokier wrote: > David Endicott wrote: > > Oh, and ya, my employers have been waiting years for > > "server-push" to the browser, but whatever. > > People have done that for about 12 years over HTTP, so WebSocket does > not add new functionality here. It's just an optimisation, and in > many cases, WebSocket will be slotted into an existing framework that > already works over HTTP (assuming WS works better). > > -- Jamie > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd58e68e3e35304a04564e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Server push over HTTP?
We have poor emulations of it, but we've nev= er had it in HTTP.
What are you thinking about w.r.t. server push= Jamie?

-=3DR

On= Wed, Apr 6, 2011 at 12:55 PM, Jamie Lokier <jamie@shareable.org> wrote:
David Endicott wrote:
> =A0 =A0Oh, and ya, my employers have been waiting years for
> =A0 =A0"server-push" to the browser, but whatever.

People have done that for about 12 years over HTTP, so WebSocket does=
not add new functionality here. =A0It's just an optimisation, and in many cases, WebSocket will be slotted into an existing framework that
already works over HTTP (assuming WS works better).

-- Jamie
__________________________________= _____________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--000e0cd58e68e3e35304a04564e1-- From jamie@shareable.org Wed Apr 6 13:04:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CC53A6974 for ; Wed, 6 Apr 2011 13:04:34 -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=[AWL=0.000, 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 99Z9i3HXQdSj for ; Wed, 6 Apr 2011 13:04:34 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 15E6F3A67DA for ; Wed, 6 Apr 2011 13:04:34 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7YzZ-00063Y-7T; Wed, 06 Apr 2011 21:06:17 +0100 Date: Wed, 6 Apr 2011 21:06:17 +0100 From: Jamie Lokier To: Andy Green Message-ID: <20110406200617.GH26912@shareable.org> References: <4D99C628.8090409@ericsson.com> <001f01cbf3e1$801dd120$80597360$@net> <4D9B9AD3.2020101@weelya.com> <4D9C2CF6.5020704@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9C2CF6.5020704@warmcat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org Subject: Re: [hybi] call for feedback on Masking alternatives 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, 06 Apr 2011 20:04:34 -0000 Andy Green wrote: > In the case the websocket framing about length is obscured and #1 stays, > muxed content looks like > > > [impenetrable randomness of unknown length unless fully and > recursively parsed] Unwanted side effect: Delivery timing delays when the muxer does not distinguish underlying message boundaries from mid-message bytes. Either it forwards every byte eagerly, which causes excessive mux chunks and TCP packets, and TCP timing degrades due to mixed size segments, or it delays slightly to buffer more before fowarding, and adds delays that way. -- Jamie From dendicott@gmail.com Wed Apr 6 13:08:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9D53A67DA for ; Wed, 6 Apr 2011 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTfTDj-XlWYt for ; Wed, 6 Apr 2011 13:08:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 498C63A6974 for ; Wed, 6 Apr 2011 13:08:33 -0700 (PDT) Received: by wwa36 with SMTP id 36so1566429wwa.13 for ; Wed, 06 Apr 2011 13:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d2+sj6CZNZLn9iquh8RmQF5ycFApNrha1LdKKQYske0=; b=LIFZs2mq3BLpz7Drp7TNxEG9ZmnVaF5DsdbAkOMFGA21WtVGNlK2PtJ9njhV34/npY xAZHO4uksQ6RSpJLu0S0zUd8rxK4ejdwfVGwvt+h5Zz/Hl72Y4dnLVmALD55hu78I72+ FIllmJPhElXObDiciNlnWlvsTUKvvv3NVFxqk= 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=hyMMQIr6uP2ydAoJWR86WLqHM7P+wml9pixsAjCw1hHLqCRkLZNjKapAxQn0Le8z3H 5/NGv/nEqExMsOzJugM+LAVcT4AbgHDxUI/L2/T2vFHnz+CMm1gZmGMyyIGUX8s4y8EU qgms+dSkw/K75B6ZPTDw8AdHR6J/vofGawqUE= MIME-Version: 1.0 Received: by 10.216.69.131 with SMTP id n3mr32288wed.47.1302120616599; Wed, 06 Apr 2011 13:10:16 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Wed, 6 Apr 2011 13:10:16 -0700 (PDT) In-Reply-To: <20110406195527.GG26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> Date: Wed, 6 Apr 2011 16:10:16 -0400 Message-ID: From: David Endicott To: Jamie Lokier Content-Type: multipart/alternative; boundary=000e0cd66e6ecea41704a0459482 Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 20:08:34 -0000 --000e0cd66e6ecea41704a0459482 Content-Type: text/plain; charset=ISO-8859-1 No, I mean *real* server push. The synchronous nature of HTTP has not allowed "real-time" asynchronous updates from the server. No matter how clever we've been so far (AJAX long polling, et al.) the slight latency has been an issue. We do live financial market trading at the inter-dealer level (ie. our customers are banks) and *any* latency is bad latency. Yes, seriously. Being able to implement an asynchronous callback like mechanism is going to allow us to leverage the browser as viable UI tool. We do not view WS as an optimization that slots into existing frameworks - we view it as a new protocol mechanism separate but allied with HTTP. Our planned use cases have WS as the transport for a message based API. The browser will use HTTP to fetch HTML/CSS/JS to produce UI rendering. In several cases our WS server will sit on a different machine & port than the HTTP server (subdomains to satisfy same-origin policy). In a couple of other cases it'll be part of a WSGI application and integrated into the HTTP stack. On Wed, Apr 6, 2011 at 3:55 PM, Jamie Lokier wrote: > David Endicott wrote: > > Oh, and ya, my employers have been waiting years for > > "server-push" to the browser, but whatever. > > People have done that for about 12 years over HTTP, so WebSocket does > not add new functionality here. It's just an optimisation, and in > many cases, WebSocket will be slotted into an existing framework that > already works over HTTP (assuming WS works better). > > -- Jamie > --000e0cd66e6ecea41704a0459482 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, I mean *real* server push. =A0 The synchronous nature of HTTP has not a= llowed "real-time" asynchronous updates from the server. =A0 =A0N= o matter how clever we've been so far (AJAX long polling, et al.) the s= light latency has been an issue. =A0=A0

We do live financial market trading at the inter-dealer leve= l (ie. our customers are banks) and *any* latency is bad latency. =A0 Yes, = seriously. =A0 Being able to implement an=A0asynchronous=A0callback like me= chanism is going to allow us to leverage the browser as viable UI tool.

We do not view WS as an optimization that slots into existin= g frameworks - we view it as a new protocol mechanism=A0separate=A0but alli= ed with HTTP. =A0=A0

Our planned use cases have WS= as the transport for a message based API. =A0 The browser will use HTTP to= fetch HTML/CSS/JS to produce UI rendering. =A0 In several cases our WS ser= ver will sit on a different machine & port than the HTTP server (subdom= ains to satisfy same-origin policy). =A0 In a couple of other cases it'= ll be part of a WSGI application and integrated into the HTTP stack.




On Wed, Apr 6, 2011 at 3:55 PM, Jamie Lokier <jamie@shareable.org> wro= te:
David Endicott wrote:
> =A0 =A0Oh, and ya, my employers have been waiting years for
> =A0 =A0"server-push" to the browser, but whatever.

People have done that for about 12 years over HTTP, so WebSocket does=
not add new functionality here. =A0It's just an optimisation, and in many cases, WebSocket will be slotted into an existing framework that
already works over HTTP (assuming WS works better).

-- Jamie

--000e0cd66e6ecea41704a0459482-- From w@1wt.eu Wed Apr 6 13:32:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4654B3A69DC for ; Wed, 6 Apr 2011 13:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=-0.541, 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 sPxhAd5Q9JQJ for ; Wed, 6 Apr 2011 13:32:45 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 40BD33A6998 for ; Wed, 6 Apr 2011 13:32:45 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p36KYNaK003396; Wed, 6 Apr 2011 22:34:23 +0200 Date: Wed, 6 Apr 2011 22:34:23 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20110406203423.GB2032@1wt.eu> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <20110406194602.GF26912@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110406194602.GF26912@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 06 Apr 2011 20:32:46 -0000 Hi Jamie, On Wed, Apr 06, 2011 at 08:46:03PM +0100, Jamie Lokier wrote: > Willy Tarreau wrote: > > It seems the guy did not understand the goal of the closing handshake. He > > understood that it was in order to replace the TCP closing handshake while > > the real goal was to let the remote side know if the close was expected or > > not (TCP close without WS close indicates it comes from an intermediary, > > and automatic reconnection might be desirable in some cases). > > As I recall, your reason isn't the real goal either! I recall it > being to prevent the TCP reset-on-close hazard, not to distinguish > endpoint vs. intermediary closes. > > TCP implementations drop all buffered data, in _both_ directions, on > receiving TCP RST, and TCP RST is sent when data is received to a > closed socket. Ah yes, I know that issue too well. It forces some servers to infinitely read data, hoping what they sent was received, just because there is no way for the application to be notified of the ACK of a shutdown(). Indeed, a close handshake then makes sense for that case. (...) > > His pause/resume mechanism is what I normally call flow control. It might > > be nice to study the idea, though it can have huge security impacts as it > > has on Ethernet and TCP (easy DoSes). > > Note that per-channel flow control is essential for safe & secure > multiplexing. If it is omitted, either the flows aren't independent > (head of line blocking), or a memory DOS is possible (demuxer has to > read & buffer eagerly without bound). Either way makes > application-independent multiplexing unsafe, and the former can lead > to deadlocks; flow control solves both problems. This is especially > important for "invisible" multiplexing inside the browser and/or > intermediaries. Multiplexing can be made safe using fair and simple algorithms. Some of them involve limiting the fragment size (I mean refusing fragments larger than negociated). After all, that's exactly what happens in an event-based proxy : it reads chunks up to a certain size from many sockets and processes them in turns so that everyone gets served. It's the implementer's responsibility not to stick on the same flow forever (on the multiplexer size) and the demux must check fragment sizes. > _Not_ having flow control when you have multiplexing can have huge > security impacts including DOSes and deadlocks... I see, but having it is also source of the same issues if improperly used. The attack (I forgot its name) which leaves server sockets in FIN_WAIT1 state by sending a zero TCP window after an HTTP request clearly is the type of DOS which is caused by flow control. A similar one exists on Ethernet where you can send pause frames to your victim instead of 01:80:C2 and see it totally stop talking with just 30 pps of spoofed traffic. I agree flow control has its uses, but I mean they are sometimes very dangerous and a lot of care needs to be taken when designing such a system. Regards, Willy From theturtle32@gmail.com Wed Apr 6 13:43:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E1F28C11B for ; Wed, 6 Apr 2011 13:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4RIarXlTjzh for ; Wed, 6 Apr 2011 13:43:46 -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 501B228C118 for ; Wed, 6 Apr 2011 13:43:46 -0700 (PDT) Received: by pwi5 with SMTP id 5so889835pwi.31 for ; Wed, 06 Apr 2011 13:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i02GqINr6I+FByCynlZMBiDxH8yAjBW+FgngNTPVfcw=; b=HtlVlby5Qb7LusgfZ+MPGHPqpoqIqDJt6a4BuAeTE/b8AQNl5Ak8se23N2cT1GIwLV 9R5ExkSlfafPirFQTkNitGalWtyvN3QdKf4nE6UZEhlIyR00fOSSubKVRX3+TwCqYktJ QJUVHzMSJhuX+W2R+xLRVU2MsEMyxiswLfJmU= 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=Ivyy7GYbOnBc/NeUwWBq+oYWlsLVIld3JCgr7xLWfJKAAbxc2uZsN9/O6xyAR8RIFG aGXLNdpJ6qDH6S9GTnyvKZJZGtKbX7wO5T5jeFgpfXtAySMQ1Gopiq6UGPp0k2mcso/I 6yh/s4M5GmlHBCeHYto5W8VZlAyy1AfWenSUM= MIME-Version: 1.0 Received: by 10.142.208.12 with SMTP id f12mr63191wfg.92.1302122730322; Wed, 06 Apr 2011 13:45:30 -0700 (PDT) Received: by 10.68.44.67 with HTTP; Wed, 6 Apr 2011 13:45:30 -0700 (PDT) In-Reply-To: References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> Date: Wed, 6 Apr 2011 13:45:30 -0700 Message-ID: From: Brian To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Cc: gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 20:43:47 -0000 On Wed, Apr 6, 2011 at 1:10 PM, David Endicott wrote: > The browser will use HTTP to fetch HTML/CSS/JS to produce UI rendering. In > several cases our WS server will sit on a different machine & port than the > HTTP server (subdomains to satisfy same-origin policy). In a couple of > other cases it'll be part of a WSGI application and integrated into the HTTP > stack. The origin enforcement is mediated by the server in websockets, which allows the server to accept connections from any arbitrary domain at its discretion. The method for which origins to allow is application-specific. You can host your websocket server on any arbitrary domain, and connections will be allowed as long as the server responds with a Sec-Websocket-Origin header that matches the domain that served the HTML/JS that is attempting to initiate the connection. Brian From sm@elandsys.com Wed Apr 6 13:46:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB4C28C0ED for ; Wed, 6 Apr 2011 13:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtbQ8lCMloOs for ; Wed, 6 Apr 2011 13:46:08 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 52A823A69B9 for ; Wed, 6 Apr 2011 13:46:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.131]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p36KlblA031711; Wed, 6 Apr 2011 13:47:43 -0700 Message-Id: <6.2.5.6.2.20110406132815.0c3b7248@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Apr 2011 13:45:20 -0700 To: Bruce Atherton From: S Moonesamy In-Reply-To: <4D9CA4E1.70409@callenish.com> References: <4D9CA4E1.70409@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: hybi@ietf.org, Gabriel Montenegro Subject: Re: [hybi] Arguments in the FAQ 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, 06 Apr 2011 20:46:09 -0000 Hi Bruce, At 10:37 06-04-2011, Bruce Atherton wrote: >I have an issue with the FAQ that I would appreciate some guidance >from the WG on. > >I have noted at the top of the FAQ that it is intended that it >describe the state of the protocol as it currently exists and how it >got that way. I do not believe it is intended as a platform for >debate concerning whether a particular choice is a good one. The FAQ is There is a note at the top of the FAQ which says: "A note to contributors: Please do not use the FAQ as a debating document. The FAQ is intended to describe the protocol as it is currently defined in the spec. If you want to see a change in the spec, bring it up on the mailing list and see if you can achieve a rough consensus. Do not present your arguments here as they will be removed. A second note to contributors: Please do not remove the Questions when answering them. This is a FAQ = Frequently Answered Questions, not FA = Frequent Answers. Please write answers in a FAQ style and not book narrative style." >Given that, I intend to delete any such debating points that are >raised in the FAQ unless the WG instructs me otherwise. I am about >to do so now on the question asking why SHA-1 is used for hashing. >IMNSHO contributions that more fully explain why SHA-1 was selected >are welcome. Changes arguing for a different approach are ones that >should be deleted. I suggest that you post a message to this mailing list before making such changes. Please use "FAQ" followed by a description in the subject line as some WG participants might wish to filter out these messages. Please note that the FAQ on the Hybi Wiki is not a work item of this working group. The WG Chairs posted a message ( http://www.ietf.org/mail-archive/web/hybi/current/msg06449.html ) to explain why the FAQ was set up. Regards, S. Moonesamy Hybi WG Secretary From w@1wt.eu Wed Apr 6 14:08:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0603A67C2 for ; Wed, 6 Apr 2011 14:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.533, 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 Ld8S9pVCbg7p for ; Wed, 6 Apr 2011 14:08:11 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 93A463A63D3 for ; Wed, 6 Apr 2011 14:08:09 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p36L9jZd003697; Wed, 6 Apr 2011 23:09:45 +0200 Date: Wed, 6 Apr 2011 23:09:45 +0200 From: Willy Tarreau To: David Endicott Message-ID: <20110406210945.GC2032@1wt.eu> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.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, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 21:08:11 -0000 Hi David, On Wed, Apr 06, 2011 at 11:45:43AM -0400, David Endicott wrote: > Has anyone demonstrated an actual instance of a problem so far, either as > revealed during WS implementation testing or from targeted > vulnerability assessment? No, but see below. > Does anyone have a suspicion that a particular vendor's product might be at > risk? Not a particular vendor either. The problem is that it has been proven via an experience that some unidentified products behave badly when subjected to WS-like traffic. Those products could not be identified because they're likely transparent proxies. By "behave badly", I mean things like connection resets and truncated responses (which can themselves be caused by connection resets BTW). Since it was not possible to identify those products, we had to try to guess what types of issues they might suffer from, with some very likely ones that affect real products to the most unlikely ones that affect no yet-known product. The actual masking was proposed as a solution against a risk of exploiting this family of issues in these products, by still taking into account the risk of ever encountering an affected product, the possible impacts, the performance costs and the flexibility cost. The masking method will never be perfect by definition, because : 1) it's still weak in front of the most possibly vulnerable product we could think of ; 2) it's useless and expensive for the vast majority of non-vulnerable products ; Yet it's still well balanced, it's far less expensive than solutions that could cover everything we can think of (possibly at the expense of limiting protocol adoption in some environments), and it's very efficient against all the vulnerabilities we could *reasonably* think of (based on experience and the difficulty to implement those vulneratbilities on purpose). It could probably be better for some uses at the expense of other ones, may be we could make it better for more uses, but given the amount of arguments everyone has made here on the subject here, I think that many aspects have been covered. It's a fact that I think that moving the masking after the framing would simplify it a bit by avoiding code duplication and state keeping, and make it possible to propose other forms of masking later, but I agree that these are acceptably small benefits, and I respect the fact that some people have fears about the more controllable data that appears after the two first bytes, even if I don't share them based on my experience with HTTP implementations. What we should do now is to see what it costs to correctly implement the masking as it is now, what it could have cost to implement it differently, what either choices bring in terms of flexibility, and decide if the benefits are worth the arguably small added risk on the security plan. Since we can't prove either way is better than the other, we can only make a choice based on personal experience, evolution perspectives, and feelings. Hoping this clarifies the situation for you, Willy From jamie@shareable.org Wed Apr 6 14:11:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCE23A67C3 for ; Wed, 6 Apr 2011 14:11:06 -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=[AWL=0.000, 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 Q7b7A5cmWvkP for ; Wed, 6 Apr 2011 14:11:04 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id E30D73A67C2 for ; Wed, 6 Apr 2011 14:11:03 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7a1t-0006MH-5l; Wed, 06 Apr 2011 22:12:45 +0100 Date: Wed, 6 Apr 2011 22:12:45 +0100 From: Jamie Lokier To: Roberto Peon Message-ID: <20110406211245.GI26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@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, gezelter@rlgsc.com Subject: [hybi] Slightly OT: To those "waiting for server push" 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, 06 Apr 2011 21:11:09 -0000 David Endicott wrote: >>> Oh, and ya, my employers have been waiting years for >>> "server-push" to the browser, but whatever. Jamie Lokier wrote: >> People have done that for about 12 years over HTTP, so WebSocket >> does not add new functionality here. It's just an optimisation, >> and in many cases, WebSocket will be slotted into an existing >> framework that already works over HTTP (assuming WS works >> better). Roberto Peon wrote: > Server push over HTTP? > We have poor emulations of it, but we've never had it in HTTP. > What are you thinking about w.r.t. server push Jamie? Server push means the ability to send messages to the client when the server has a message to send, without polling, after the client has established a connection for this purpose. If it works reasonably well, it exists regardless of how it's implemented. (WebSocket is not without hacks either.) Functionally, Cometd, Bayeaux, numerous others, provide much the same effect as WebSocket, and applications using them are unlikely to notice the difference. Not even in resources used. WS may be faster for some applications, but not hugely so. The practical difference is WebSocket uses fewer TCP connections (though slower handshake), is a bit simpler, a bit faster, and it's built in to some browsers so you don't have to load as much Javascript. Hence: an optimisation. If someone is waiting for server-push before they can write that async application they dreamed of... well, there is no reason to wait, there is good software and toolkits to do it already. If someone thinks WebSocket fixes the complexity, robustness, performance or even network compatibility problems of the HTTP stuff, they're mistaken. (WS appears to be less network compatible, at the moment.) There remain complexity, robustness, performance and compatibility issues with WebSockets. Robust apps must address them using the same methods as with HTTP transports - retrying connections, duplicate and order tracking (across retried connections - corner cases happen), keepalives, idle timeouts, dropping/coalescing redundant updates, cooperating between multiple windows/widgets, message target dispatch, etc. etc. etc. I expect many robust apps & toolkits will use the same code for that using either transport method underneath. And many of the server-side networking and scaling issues are similar in either case. WebSocket only replaces part of the server push problem, and it doesn't introduce any new behaviour we can't already do, that I can see. I'm glad we have it, it's an improvement (I hope), but I can't think of any application that's made possible by it. (Would love examples if you have any!) Thanks for listening, -- Jamie From bruce@callenish.com Wed Apr 6 14:15:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23943A6956 for ; Wed, 6 Apr 2011 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 mv+eqCWdKC6B for ; Wed, 6 Apr 2011 14:15:52 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 4B4FA3A67D3 for ; Wed, 6 Apr 2011 14:15:52 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q7a6Y-0007ss-IA; Wed, 06 Apr 2011 14:17:34 -0700 Message-ID: <4D9CD86F.8000908@callenish.com> Date: Wed, 06 Apr 2011 14:17:35 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: S Moonesamy References: <4D9CA4E1.70409@callenish.com> <6.2.5.6.2.20110406132815.0c3b7248@resistor.net> In-Reply-To: <6.2.5.6.2.20110406132815.0c3b7248@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: hybi@ietf.org, Gabriel Montenegro Subject: Re: [hybi] Arguments in the FAQ 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, 06 Apr 2011 21:15:53 -0000 On 06/04/2011 1:45 PM, S Moonesamy wrote: > Hi Bruce, > At 10:37 06-04-2011, Bruce Atherton wrote: >> I have an issue with the FAQ that I would appreciate some guidance >> from the WG on. >> >> I have noted at the top of the FAQ that it is intended that it >> describe the state of the protocol as it currently exists and how it >> got that way. I do not believe it is intended as a platform for >> debate concerning whether a particular choice is a good one. The FAQ is > > There is a note at the top of the FAQ which says: > > "A note to contributors: Please do not use the FAQ as a debating > document. > The FAQ is intended to describe the protocol as it is currently > defined in > the spec. If you want to see a change in the spec, bring it up on the > mailing list and see if you can achieve a rough consensus. Do not > present > your arguments here as they will be removed. Yes, I wrote that a few weeks ago. I believe it is a good idea as the FAQ should be a document of the history of decisions in order to explain the protocol, not a place to argue about future changes. But that is just my opinion. Yesterday there was an edit that went directly against that policy, so I thought I would bring the matter up here to see if anyone else supported my view. > > A second note to contributors: Please do not remove the Questions > when answering > them. This is a FAQ = Frequently Answered Questions, not FA = > Frequent Answers. > Please write answers in a FAQ style and not book narrative style." I take this to be a reference to the fact that the actual FAQ starts some distance down in the document. Does anyone object to me moving the goals of Websockets to a separate Wiki page and providing a reference to it from the FAQ? Then we can get rid of that note. > > I suggest that you post a message to this mailing list before making > such changes. Please use "FAQ" followed by a description in the > subject line as some WG participants might wish to filter out these > messages. As you wish. > > Please note that the FAQ on the Hybi Wiki is not a work item of this > working group. The WG Chairs posted a message ( > http://www.ietf.org/mail-archive/web/hybi/current/msg06449.html ) to > explain why the FAQ was set up. Right, and I think my view as to its purpose fits with the motivation described. I understand that the WG is not producing it as a working item, but at the same time I don't think it is right for me (or any other individual) to arbitrarily decide what the FAQ is or isn't. I certainly don't want to get into an EditWar (http://en.wikipedia.org/wiki/Wikipedia:EDITWAR). > > Regards, > S. Moonesamy > Hybi WG Secretary Thanks, I appreciate the feedback. From fenix@google.com Wed Apr 6 14:26:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B3628C0D0 for ; Wed, 6 Apr 2011 14:26: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 Rz9NZzJDDbjD for ; Wed, 6 Apr 2011 14:26: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 C4B8428C11B for ; Wed, 6 Apr 2011 14:26:18 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p36LS2Iw021006 for ; Wed, 6 Apr 2011 14:28:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302125282; bh=H2zPO1IcxXOsLtrDB/kUAQKJSh0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=xVatzCuICuG9bRmndsJTVPWpGOk5vj/QF/kvnMTesNoW09MxBs2iu7DnJZ6VPe/MO 7Q+Ldwk7KAa/H4XSqSZCQ== Received: from gwj22 (gwj22.prod.google.com [10.200.10.22]) by kpbe13.cbf.corp.google.com with ESMTP id p36LS09N025040 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 14:28:01 -0700 Received: by gwj22 with SMTP id 22so727974gwj.35 for ; Wed, 06 Apr 2011 14:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LhYkD3h5UuqqzGNuSxST0wHbeNUaJMbn2WfqdpoFOuo=; b=NO9893YaflsTiXQQZViGAPbxdsnLv/io9tFjKm8hKC1bLGPtZ2eo6WgBL4UYraxomb X5ZSPFceyFAklzR03eIg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Vj/OEWalVb/po4/Y7uvORW8R7AC5MLGxMBbBuFvFW/GDzBia8QcHiaUNv8/OGRyLOv /O4hj3gFo0JQl53b9Ekg== MIME-Version: 1.0 Received: by 10.150.114.20 with SMTP id m20mr100845ybc.303.1302125280333; Wed, 06 Apr 2011 14:28:00 -0700 (PDT) Received: by 10.150.182.9 with HTTP; Wed, 6 Apr 2011 14:28:00 -0700 (PDT) In-Reply-To: <20110406211245.GI26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> <20110406211245.GI26912@shareable.org> Date: Wed, 6 Apr 2011 14:28:00 -0700 Message-ID: From: Roberto Peon To: Jamie Lokier Content-Type: multipart/alternative; boundary=000e0cd57398c9903504a046aaab X-System-Of-Record: true Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Slightly OT: To those "waiting for server push" 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, 06 Apr 2011 21:26:20 -0000 --000e0cd57398c9903504a046aaab Content-Type: text/plain; charset=ISO-8859-1 Jamie-- I think your arguments are fair and I agree with most of the points here. In fact, if I'm communicating clearly, you won't find any disagreements here. I'm particularly worried about what effect WS will have on.. well, everything but the user-agent. I've been quiet on that front for a while because consensus was against including multiplexing, etc., but my silence doesn't mean those fears are yet addressed. I hope that John's multiplexing extension whill help to address at least the scaling problems that I fear. I agree that, as compared to the various hanging-get mechanisms, any full-duplex protocol can only offer optimizations. I think that the thing to watch is how important those optimizations are. Using a single host, for instance, you can't get more than 6/rtt messages per second over current methods (assuming per-host connection limit of 6). You may be able to work around this by using more hosts, yes, but barrier to entry for such an application is higher. Worse, potentially, is that if you're running many machines at the same IP as many sites do, the various connections end up at different servers, causing backend loadbalancing complexity that the aplpication writer must resolve either by additional self-proxying, or by modifying the loadbalancer. Anyway, this is OT, and I suspect (or at least hope) that all of this is old hat, and we're just arguing semantics and otherwise violently agreeing. -=R On Wed, Apr 6, 2011 at 2:12 PM, Jamie Lokier wrote: > David Endicott wrote: > >>> Oh, and ya, my employers have been waiting years for > >>> "server-push" to the browser, but whatever. > > Jamie Lokier wrote: > >> People have done that for about 12 years over HTTP, so WebSocket > >> does not add new functionality here. It's just an optimisation, > >> and in many cases, WebSocket will be slotted into an existing > >> framework that already works over HTTP (assuming WS works > >> better). > > Roberto Peon wrote: > > Server push over HTTP? > > We have poor emulations of it, but we've never had it in HTTP. > > What are you thinking about w.r.t. server push Jamie? > > Server push means the ability to send messages to the client when the > server has a message to send, without polling, after the client has > established a connection for this purpose. > > If it works reasonably well, it exists regardless of how it's > implemented. (WebSocket is not without hacks either.) > > Functionally, Cometd, Bayeaux, numerous others, provide much the same > effect as WebSocket, and applications using them are unlikely to > notice the difference. Not even in resources used. WS may be faster > for some applications, but not hugely so. > > The practical difference is WebSocket uses fewer TCP connections > (though slower handshake), is a bit simpler, a bit faster, and it's > built in to some browsers so you don't have to load as much > Javascript. Hence: an optimisation. > > If someone is waiting for server-push before they can write that async > application they dreamed of... well, there is no reason to wait, there > is good software and toolkits to do it already. > > If someone thinks WebSocket fixes the complexity, robustness, > performance or even network compatibility problems of the HTTP stuff, > they're mistaken. (WS appears to be less network compatible, at the > moment.) > > There remain complexity, robustness, performance and compatibility > issues with WebSockets. Robust apps must address them using the same > methods as with HTTP transports - retrying connections, duplicate and > order tracking (across retried connections - corner cases happen), > keepalives, idle timeouts, dropping/coalescing redundant updates, > cooperating between multiple windows/widgets, message target dispatch, > etc. etc. etc. > > I expect many robust apps & toolkits will use the same code for that > using either transport method underneath. > > And many of the server-side networking and scaling issues are similar > in either case. > > WebSocket only replaces part of the server push problem, and it > doesn't introduce any new behaviour we can't already do, that I can see. > > I'm glad we have it, it's an improvement (I hope), but I can't think > of any application that's made possible by it. (Would love examples > if you have any!) > > Thanks for listening, > -- Jamie > --000e0cd57398c9903504a046aaab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jamie--

I think your arguments are fair and I agree with= most of the points here. In fact, if I'm communicating clearly, you wo= n't find any disagreements here.

I'm parti= cularly worried about what effect WS will have on.. well, everything but th= e user-agent. I've been quiet on that front for a while because consens= us was against including multiplexing, etc., but my silence doesn't mea= n those fears are yet addressed. I hope that John's multiplexing extens= ion whill help to address at least the scaling problems that I fear.

I agree that, as compared to the various hanging-get me= chanisms, any full-duplex protocol can only offer optimizations. I think th= at the thing to watch is how important those optimizations are. Using a sin= gle host, for instance, you can't get more than 6/rtt messages per seco= nd over current methods (assuming per-host connection limit of 6). You may = be able to work around this by using more hosts, yes, but barrier to entry = for such an application is higher. Worse, potentially, is that if you'r= e running many machines at the same IP as many sites do, the various connec= tions end up at different servers, causing backend loadbalancing complexity= that the aplpication writer must resolve either by additional self-proxyin= g, or by modifying the loadbalancer.

Anyway, this is OT, and I suspect (or at least hope) th= at all of this is old hat, and we're just arguing semantics and otherwi= se violently agreeing.
-=3DR

On Wed, Apr 6, 2011 at 2:12 PM, Jamie Lokier <jamie@shareable.org> wrote:
David Endicott wrote:
>>> =A0 =A0Oh, and ya, my employers have been waiting years for >>> =A0 =A0"server-push" to the browser, but whatever.
Jamie Lokier wrote:
>> People have done that for about 12 years over HTTP, so WebSocket >> does not add new functionality here. =A0It's just an optimisat= ion,
>> and in many cases, WebSocket will be slotted into an existing
>> framework that already works over HTTP (assuming WS works
>> better).

Roberto Peon wrote:
> =A0 =A0Server push over HTTP?
> =A0 =A0We have poor emulations of it, but we've never had it in HT= TP.
> =A0 =A0What are you thinking about w.r.t. server push Jamie?

Server push means the ability to send messages to the client when the
server has a message to send, without polling, after the client has
established a connection for this purpose.

If it works reasonably well, it exists regardless of how it's
implemented. =A0(WebSocket is not without hacks either.)

Functionally, Cometd, Bayeaux, numerous others, provide much the same
effect as WebSocket, and applications using them are unlikely to
notice the difference. =A0Not even in resources used. =A0WS may be faster for some applications, but not hugely so.

The practical difference is WebSocket uses fewer TCP connections
(though slower handshake), is a bit simpler, a bit faster, and it's
built in to some browsers so you don't have to load as much
Javascript. =A0Hence: an optimisation.

If someone is waiting for server-push before they can write that async
application they dreamed of... well, there is no reason to wait, there
is good software and toolkits to do it already.

If someone thinks WebSocket fixes the complexity, robustness,
performance or even network compatibility problems of the HTTP stuff,
they're mistaken. =A0(WS appears to be less network compatible, at the<= br> moment.)

There remain complexity, robustness, performance and compatibility
issues with WebSockets. =A0Robust apps must address them using the same
methods as with HTTP transports - retrying connections, duplicate and
order tracking (across retried connections - corner cases happen),
keepalives, idle timeouts, dropping/coalescing redundant updates,
cooperating between multiple windows/widgets, message target dispatch,
etc. etc. etc.

I expect many robust apps & toolkits will use the same code for that using either transport method underneath.

And many of the server-side networking and scaling issues are similar
in either case.

WebSocket only replaces part of the server push problem, and it
doesn't introduce any new behaviour we can't already do, that I can= see.

I'm glad we have it, it's an improvement (I hope), but I can't = think
of any application that's made possible by it. =A0(Would love examples<= br> if you have any!)

Thanks for listening,
-- Jamie

--000e0cd57398c9903504a046aaab-- From jamie@shareable.org Wed Apr 6 14:41:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72353A6956 for ; Wed, 6 Apr 2011 14:41:13 -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=[AWL=0.000, 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 frfEYbcyudHM for ; Wed, 6 Apr 2011 14:41:13 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 08C143A67E3 for ; Wed, 6 Apr 2011 14:41:13 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7aV3-0006Xq-Te; Wed, 06 Apr 2011 22:42:53 +0100 Date: Wed, 6 Apr 2011 22:42:53 +0100 From: Jamie Lokier To: David Endicott Message-ID: <20110406214253.GJ26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@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, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 21:41:13 -0000 David Endicott wrote: > No, I mean *real* server push. The synchronous nature of HTTP has > not allowed "real-time" asynchronous updates from the server. No > matter how clever we've been so far (AJAX long polling, et al.) the > slight latency has been an issue. Exactly: It is an optimisation. I'm not saying WebSocket isn't an improvement, and it sounds well suited to your purpose. You are mistaken if you think HTTP long polling is restricted to a synchronous model and cannot do continuous asynchronous updates. It depends very much on how you go about it. Obviously if you wait for a whole response before sending another request, that's what happens. That's the most well known model, but it's not the only way - there are several other patterns available, to remove the synchronous delay. Most people don't care about that delay, so they stick with the synchronous pattern because it's easy. You are mistaken if you think WS is latency optimised. I have brought up issues affecting TCP latency or proxy latency several times on the hybi list, and nearly every time, it is ignored in favour of other things. > We do live financial market trading at the inter-dealer level > (ie. our customers are banks) and *any* latency is bad latency. > Yes seriously. I know. I'm a latency geek myself. > Being able to implement an asynchronous callback like mechanism > is going to allow us to leverage the browser as viable UI tool. For your purpose, WS sounds well suited. If you have big money critically dependent on absolutely minimising server-to-browser latency as much as possible, there are better methods than WS, though you are of course right that WS is a substantial improvement over HTTP in that area. > We do not view WS as an optimization that slots into existing > frameworks - we view it as a new protocol mechanism separate but > allied with HTTP. That's fine. Of course you can implement a 'WebSocket' object in Javascript that uses HTTP behind the scenes, as your fallback ;-) > Our planned use cases have WS as the transport for a message based > API. The browser will use HTTP to fetch HTML/CSS/JS to produce UI > rendering. In several cases our WS server will sit on a different > machine & port than the HTTP server (subdomains to satisfy same-origin > policy). In a couple of other cases it'll be part of a WSGI > application and integrated into the HTTP stack. That's a fine plan. -- Jamie From w@1wt.eu Wed Apr 6 14:44:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59FD28C0D0 for ; Wed, 6 Apr 2011 14:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 uXnMt57th-Zt for ; Wed, 6 Apr 2011 14:44:10 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 852FE3A6956 for ; Wed, 6 Apr 2011 14:44:09 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p36Ljogw004162; Wed, 6 Apr 2011 23:45:50 +0200 Date: Wed, 6 Apr 2011 23:45:50 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20110406214550.GF2032@1wt.eu> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> <20110406211245.GI26912@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110406211245.GI26912@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Slightly OT: To those "waiting for server push" 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, 06 Apr 2011 21:44:10 -0000 On Wed, Apr 06, 2011 at 10:12:45PM +0100, Jamie Lokier wrote: (...) > WebSocket only replaces part of the server push problem, and it > doesn't introduce any new behaviour we can't already do, that I can see. > > I'm glad we have it, it's an improvement (I hope), but I can't think > of any application that's made possible by it. I 100% agree with what you said Jamie. That's exactly the reason why I've been trying to get something *usable* and *cheap* : because that's the only way it will be adopted, considering that alternatives already exist and are used every day. Making a worse/harder to use/more expensive/less extensive replacement for current technologies will simply not work. If application developers and users think "Hey, that's really cool", they will deploy it and the remaining obstacles will be leveraged under the users' pressure (mainly the incompatible transparent proxies). But if it does not bring any measurable benefit, why will developers have to maintain multiple access methods with their share of issues when the current ones already work ? I really think that all the remaining points will have to be addressed at least on the list to ensure that nothing will block their inclusion later (multiplexing, compression, raw TCP, alternative masking, non-101 responses, authentication, state management between connections). If we don't do that, we may block extensivity due to stupid design mistakes and regret it later. Regards, Willy From sm@elandsys.com Wed Apr 6 16:04:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54A23A6808 for ; Wed, 6 Apr 2011 16:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8MJOEkDj8Mh for ; Wed, 6 Apr 2011 16:04:27 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id B2B7E3A6804 for ; Wed, 6 Apr 2011 16:04:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.165]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p36N5vRH013022; Wed, 6 Apr 2011 16:06:03 -0700 Message-Id: <6.2.5.6.2.20110406153338.0c962810@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Apr 2011 16:04:43 -0700 To: Bruce Atherton From: S Moonesamy In-Reply-To: <4D9CD86F.8000908@callenish.com> References: <4D9CA4E1.70409@callenish.com> <6.2.5.6.2.20110406132815.0c3b7248@resistor.net> <4D9CD86F.8000908@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: hybi@ietf.org, Gabriel Montenegro Subject: Re: [hybi] Arguments in the FAQ 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, 06 Apr 2011 23:04:28 -0000 Hi Bruce, At 14:17 06-04-2011, Bruce Atherton wrote: >Yes, I wrote that a few weeks ago. I believe it is a good idea as >the FAQ should be a document of the history of decisions in order to >explain the protocol, not a place to argue about future changes. But >that is just my opinion. As nobody edited that, I gather that it is viewed as a good idea. >Yesterday there was an edit that went directly against that policy, >so I thought I would bring the matter up here to see if anyone else >supported my view. I'll call it a guideline instead of a policy. Please see further comments below. >I take this to be a reference to the fact that the actual FAQ starts >some distance down in the document. Does anyone object to me moving >the goals of Websockets to a separate Wiki page and providing a >reference to it from the FAQ? Then we can get rid of that note. As this does not seem to require a consensus call, I suggest that the people working on the FAQ keep things easy. If it ends up stirring controversy, I am going to stick to the IETF standards process. >Right, and I think my view as to its purpose fits with the >motivation described. I understand that the WG is not producing it >as a working item, but at the same time I don't think it is right >for me (or any other individual) to arbitrarily decide what the FAQ >is or isn't. I certainly don't want to get into an EditWar As an individual comment, if it is not a work item, it can be considered as off-topic. The Note Well ( http://www.ietf.org/about/note-well.html ) is applicable. Regards, S. Moonesamy Hybi WG Secretary From gregw@intalio.com Wed Apr 6 16:12:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396E73A6801 for ; Wed, 6 Apr 2011 16:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEw4EzEAdUTY for ; Wed, 6 Apr 2011 16:12:52 -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 910F43A67FC for ; Wed, 6 Apr 2011 16:12:52 -0700 (PDT) Received: by vws12 with SMTP id 12so1876191vws.31 for ; Wed, 06 Apr 2011 16:14:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.36 with SMTP id cf4mr329619vdc.29.1302131676230; Wed, 06 Apr 2011 16:14:36 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Wed, 6 Apr 2011 16:14:36 -0700 (PDT) In-Reply-To: References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> Date: Thu, 7 Apr 2011 09:14:36 +1000 Message-ID: From: Greg Wilkins To: David Endicott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 06 Apr 2011 23:12:53 -0000 On 7 April 2011 06:10, David Endicott wrote: > No, I mean *real* server push. =A0 The synchronous nature of HTTP has not > allowed "real-time" asynchronous updates from the server. =A0 =A0No matte= r how > clever we've been so far (AJAX long polling, et al.) the slight latency h= as > been an issue. > We do live financial market trading at the inter-dealer level (ie. our > customers are banks) and *any* latency is bad latency. =A0 Yes, seriously= . > Being able to implement an=A0asynchronous=A0callback like mechanism is go= ing to > allow us to leverage the browser as viable UI tool. I think it is a misconception that WS is going to greatly improve latency over solutions like long polling. Firstly this is all over TCP/IP and packets can be lost and timeouts might be needed to trigger a resend. So no matter what you do you are looking at a chance of >1s latency on the occasional message - TCP/IP is not for controlling pace makers! Long polling does have maximal latency of 3 x network latency, only if you are unlucky and hit the no poll window or if you are streaming lots of events. But for many traffic profiles long polling latency is 1 x network latency. So don't get me wrong - WS should be better for latency, but it is no silver bullet. Plus as Jamie has pointed out several times, the obfuscated framing can have a bad effect on latency through intermediaries. cheers From jamie@shareable.org Wed Apr 6 16:33:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FE53A6973 for ; Wed, 6 Apr 2011 16:33:36 -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=[AWL=0.000, 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 thIrZEMjoEvf for ; Wed, 6 Apr 2011 16:33:35 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id A05953A6810 for ; Wed, 6 Apr 2011 16:33:35 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7cFm-0006zv-LI; Thu, 07 Apr 2011 00:35:14 +0100 Date: Thu, 7 Apr 2011 00:35:14 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20110406233514.GK26912@shareable.org> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <20110406194602.GF26912@shareable.org> <20110406203423.GB2032@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110406203423.GB2032@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 06 Apr 2011 23:33:37 -0000 Willy Tarreau wrote: > > > His pause/resume mechanism is what I normally call flow control. It might > > > be nice to study the idea, though it can have huge security impacts as it > > > has on Ethernet and TCP (easy DoSes). > > > > Note that per-channel flow control is essential for safe & secure > > multiplexing. If it is omitted, either the flows aren't independent > > (head of line blocking), or a memory DOS is possible (demuxer has to > > read & buffer eagerly without bound). Either way makes > > application-independent multiplexing unsafe, and the former can lead > > to deadlocks; flow control solves both problems. This is especially > > important for "invisible" multiplexing inside the browser and/or > > intermediaries. > > Multiplexing can be made safe using fair and simple algorithms. Some > of them involve limiting the fragment size (I mean refusing fragments > larger than negociated). After all, that's exactly what happens in an > event-based proxy : it reads chunks up to a certain size from many > sockets and processes them in turns so that everyone gets served. It's > the implementer's responsibility not to stick on the same flow forever > (on the multiplexer size) and the demux must check fragment sizes. That doesn't work. The failure case is what I mean by "the flows aren't independent". Think about a proxy, which is receiving mux'd WebSocket (for example), demuxing and forwarding fragments to individual server processes - perhaps on different servers at a different location. Now if any of those server processes runs slower than the others, it will cause _all_ the processes to slow down to that speed, _or_ the proxy will have to buffer up fragments for that slow server, while it forwards received fragments to the others. If one of the servers runs very slowly, it will effectively block all the others. You can't avoid this, unless the client sends fragments for the slower endpoint less often than for the other endpoints. That's flow control! Positive window tokens are the simplest way to do this; there are others. In the event-based processing you are thinking of, the processes aren't independent. That's ok: You want fair processing, and you accept that processes affect the rate of each other's progress, and you don't allow any of them to stop. You control them, and You probably write them with that in mind. But it doesn't work if you need to demux to independent receiving processes that you don't control, without rogue or just slow behaviour of one receiver blocking or unduly slowing the others. This characteristic is needed by "invisible" multiplexing of WebSocket streams in browser clients and in proxies (at the client/ISP). Otherwise, it is not safe to do. It's not important when you control all the processes yourself, only when you are imposing muxing on processes that you don't control, and should not cause undue interference between them. Independence is key. I only realised this issue exists when, by chance, I noticed flow control mentioned succinctly in the BEEP-over-TCP spec. Then I realised it's critical to "invisible" muxing, that per-channel flow control solves it, and none of this is obvious. It has to be done with some care - new channel creation has to be flow-controlled too[*], and initial windows have be pre-negotiated if you want cheap channels without setup RTTs. [*] (TCP provides flow control for data, and for new connections. It doesn't look like it for new connections, but that's because TCP SYN backoff provides it in a different way.) This sort of blocking has been given (by others) as an objection to multiplexing WS, compared with TCP where application flows are somewhat independent. (I.e. they compete, but don't block each other). Flow control sounds unnecessarily complex (especially if you don't know why), and it doesn't seem very elegant, but it solves the independence problem. I'll be delighted if something better turns up. > > _Not_ having flow control when you have multiplexing can have huge > > security impacts including DOSes and deadlocks... > > I see, but having it is also source of the same issues if improperly > used. The attack (I forgot its name) which leaves server sockets in > FIN_WAIT1 state by sending a zero TCP window after an HTTP request > clearly is the type of DOS which is caused by flow control. I agree. This one shows the importance of controlling where data is buffered, so it doesn't block resources by buffering in the wrong place. It is not an easy problem to solve in general, because there are legitimate slow data consumers too. Btw, can you DOS a WebSocket server in the same way? :-) > A similar one exists on Ethernet where you can send pause frames to > your victim instead of 01:80:C2 and see it totally stop talking with > just 30 pps of spoofed traffic. > > I agree flow control has its uses, but I mean they are sometimes very > dangerous and a lot of care needs to be taken when designing such a > system. Quite right. -- Jamie From bruce@callenish.com Wed Apr 6 16:39:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5ED53A6820 for ; Wed, 6 Apr 2011 16:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 AZjDQ2b8-mvh for ; Wed, 6 Apr 2011 16:39:47 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id EADE63A67F1 for ; Wed, 6 Apr 2011 16:39:47 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q7cLp-0004Rx-Jn; Wed, 06 Apr 2011 16:41:29 -0700 Message-ID: <4D9CFA2A.30403@callenish.com> Date: Wed, 06 Apr 2011 16:41:30 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamie Lokier References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> <20110406214253.GJ26912@shareable.org> In-Reply-To: <20110406214253.GJ26912@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: hybi@ietf.org Subject: [hybi] Websocket Congestion (was Full Frame Masking) 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, 06 Apr 2011 23:39:49 -0000 On 06/04/2011 2:42 PM, Jamie Lokier wrote: > > You are mistaken if you think WS is latency optimised. I have brought > up issues affecting TCP latency or proxy latency several times on the > hybi list, and nearly every time, it is ignored in favour of other things. > That brings to mind a question I've been meaning to ask for a while now. Given the existence of BufferBloat[1], should Websockets have any congestion avoidance mechanism other than TCP? Among the problems with BufferBloat is that large buffers present on most equipment on the Internet defeat the ability for TCP to detect congestion in a timely way. This combined with absurd queue lengths can result in RTT that seem to travel several lunar distances. There are ways to reduce the impact (AQM, ECN) but nothing that will be widely used in the next several years, in all likelihood. So with BufferBloat in mind, should Websockets consider providing its own standard congestion control? This wouldn't be part of the base protocol, of course, but rather a separate draft. Perhaps something that used timings on PING and PONG to do something like TCP Vegas. I don't have the experience to give a concrete suggestion or even to determine whether it is worthwhile or not, but I wanted to bring it up for discussion. [1] http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ From jamie@shareable.org Wed Apr 6 17:00:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80BD3A6827 for ; Wed, 6 Apr 2011 17:00:18 -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 8m26n7IrWmD5 for ; Wed, 6 Apr 2011 17:00:18 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id F3B813A6767 for ; Wed, 6 Apr 2011 17:00:17 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7cfd-000732-WA; Thu, 07 Apr 2011 01:01:57 +0100 Date: Thu, 7 Apr 2011 01:01:57 +0100 From: Jamie Lokier To: John Tamplin Message-ID: <20110407000157.GL26912@shareable.org> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <20110406194602.GF26912@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] Robert Gezelter on the current spec 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, 07 Apr 2011 00:00:19 -0000 John Tamplin wrote: > > On Wed, Apr 6, 2011 at 3:46 PM, Jamie Lokier <[1]jamie@shareable.org> > wrote: > > > His pause/resume mechanism is what I normally call flow control. It > might > > > be nice to study the idea, though it can have huge security impacts > as it > > has on Ethernet and TCP (easy DoSes). > > Note that per-channel flow control is essential for safe & secure > multiplexing. Â If it is omitted, either the flows aren't > independent > (head of line blocking), or a memory DOS is possible (demuxer has > to > read & buffer eagerly without bound). Â Either way makes > application-independent multiplexing unsafe, and the former can > lead > to deadlocks; flow control solves both problems. Â This is > especially > important for "invisible" multiplexing inside the browser and/or > intermediaries. > _Not_ having flow control when you have multiplexing can have huge > security impacts including DOSes and deadlocks... > > Right, but it isn't clear you have to have that in the base protocol, > rather than just in the multiplexing extension. I agree. WebSocket already has flow control. It's called TCP. Though it can be argued that it _already_ muxes two things: Normal messages, and control frames, such as the Close frame. An endpoint can't send the Close frame if the socket is full of data being read by a slow process. It can only queue it for sending later. This may or may not impact the reliability of graceful close; I haven't given it much thought. It would undermine Close-With-Reason-String, if there were such a thing in the base protocol - or even if that were an extension added later. You need data channel flow control to decouple the WS protocol handler's behaviour from the data consumer's behaviour. -- Jamie From jamie@shareable.org Wed Apr 6 17:08:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070C528C101 for ; Wed, 6 Apr 2011 17:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 txfJFkLgJjqw for ; Wed, 6 Apr 2011 17:08:57 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 5A9383A6827 for ; Wed, 6 Apr 2011 17:08:57 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7co2-00077W-9n; Thu, 07 Apr 2011 01:10:38 +0100 Date: Thu, 7 Apr 2011 01:10:38 +0100 From: Jamie Lokier To: Willy Tarreau Message-ID: <20110407001038.GM26912@shareable.org> References: <4D989304.9080802@warmcat.com> <20110404060729.GP5552@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110404060729.GP5552@1wt.eu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 00:08:58 -0000 Willy Tarreau wrote: > On Mon, Apr 04, 2011 at 03:51:17PM +1000, Greg Wilkins wrote: > > On 4 April 2011 01:44, Iñaki Baz Castillo wrote: > > > 2011/4/3 Andy Green : > > >>> Unfortunatelly I think it's too late for a new approach of the > > >>> WebSocket protocol, even if it would be really a much better design > > >>> (IMHO). > > >> > > >> It's not any new approach, you're just suggesting splitting off the > > >> handshake and the websocket transport definition into separate documents. > > >>  The end result is the same, who cares. > > > > > > Instead of a HTTP handshake, I just suggest (as the first mail in this > > > thread) the usage of a Websocket control frame to establish the WS > > > "connection". > > > > > > I think we need to consider this proposal in two parts: > > > > 1) Designing the handshake/protocol so that it could work well over a > > dedicated port > > 2) Actually deciding we want a dedicated port. > > > > > > Note that this was one of the reasons that I'm an advocate of Hello > > frames. If we move much of the protocol parameterisation (eg sub > > protocol and extension negotiation) into hello frames rather than HTTP > > headers, then this is more portable and would work WHEN AND IF we > > ever decided to have a dedicated port for ws. > > > > Hello frames can be done server->client->server to avoid a RTT's but > > maybe it is better to have them client->server->client so that the > > upgrade over HTTP would take one more RTT than a dedicated port and > > thus give an incentive to push for opening a port. > > > > So if there was interest at this late stage of moving some headers to > > hello frames - I'd be supportive of that. But I think we are too > > far down the upgrade path to change now and should keep HTTP upgrade > > for at least the short term. > > Agreed, and unfortunately, mandatory masking makes it harder to use > hello frames to negociate anything. Or we should decide that the masking > method can be negociated and defaults to XOR32 for client->server stream > over HTTP. The ostensible reason for masking is to mitigate security concerns from browsers running downloaded scripts, taking advantage of proxies/servers that treat the script-controlled bytes as HTTP. That concern is valid for any byte stream following an HTTP UPGRADE request, not just WebSocket, if the stream is controlled by a downloaded script. So it would make sense for the *initial* masking procedure, whatever it is, to be at least mentioned in any generic "safe HTTP UPGRADE" specification - irrespective of whether the following data is WebSocket or something else. -- Jamie From jamie@shareable.org Wed Apr 6 17:23:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F3B3A6996 for ; Wed, 6 Apr 2011 17:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, SARE_LWSHORTT=1.24] 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 ZQf0MgACw8yj for ; Wed, 6 Apr 2011 17:23:55 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 829A63A67D9 for ; Wed, 6 Apr 2011 17:23:55 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7d2W-0001tr-Fu; Thu, 07 Apr 2011 01:25:36 +0100 Date: Thu, 7 Apr 2011 01:25:36 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110407002536.GN26912@shareable.org> References: <4D989304.9080802@warmcat.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] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 00:23:56 -0000 Greg Wilkins wrote: > Hello frames can be done server->client->server to avoid a RTT's but > maybe it is better to have them client->server->client so that the > upgrade over HTTP would take one more RTT than a dedicated port and > thus give an incentive to push for opening a port. To reduce RTTs, I would have the protocol following HTTP Upgrade be allowed to _inherit_ initial bytes encoded in one or more designated HTTP headers from the HTTP Upgrade request. Both request and response could contain such "pre-transmitted" bytes. For simplicity, they would be a standard encoding of bytes to follow, such that they have exactly the same meaning as if those bytes were transmitted in both directions following a successful HTTP Upgrade, or as if they were transmitted from the start, when used on a dedicated port without a HTTP Upgrade handshake. There'd be no need to define them beyond that - the protocol spec would already define what they mean, as normal protocol or hello frames. The RTT-removing property is analogous to TCP SYN+data (a subset of T/TCP, which didn't work out due to security and interop problems), and to something I'm only vaguely familiar with that may happen in TLS. If the HTTP Upgrade part were separated into its own document, the encoding of "pre-transmitted" bytes would be specified in that, generically, with the proviso that the feature is only used by protocols which say they use those bytes, and specify which headers they get them from. > So if there was interest at this late stage of moving some headers to > hello frames - I'd be supportive of that. But I think we are too > far down the upgrade path to change now and should keep HTTP upgrade > for at least the short term. I agree, it is too late for this round. -- Jamie From jamie@shareable.org Wed Apr 6 17:45:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0D53A69DE for ; Wed, 6 Apr 2011 17:45:04 -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 5ALj5oqitzjP for ; Wed, 6 Apr 2011 17:45:03 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 5B43A3A69CF for ; Wed, 6 Apr 2011 17:45:03 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7dMy-0001vM-54; Thu, 07 Apr 2011 01:46:44 +0100 Date: Thu, 7 Apr 2011 01:46:44 +0100 From: Jamie Lokier To: David Endicott Message-ID: <20110407004644.GO26912@shareable.org> References: <4D961C5A.9020104@callenish.com> <4D96338F.5010603@callenish.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] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 00:45:04 -0000 David Endicott wrote: > Nor am I (hence the corvid consumption caveat) It is very possible I > have overlooked or am unaware of something. That notwithstanding, I > do feel fairly confident that doing WebSocket without a HTTP Upgrade > handshake is no less secure than with it - and may actually be safer. > Much of the jumping around and Sec-Websocket headers seem to be > simply to deal with the behavior of HTTP & XmlHTTPRequest. Eliminate > it from the WebSocket core specification and it seems to me that > several problems / design warts just go away. The HTTP part comes from the desire to run over port 80, due to firewall restrictions on all other ports. Then that means a WebSocket connection may be connecting over an transparent/intercepting HTTP proxy - that cannot be avoided, because they intercept port 80 traffic whether you want it or not. Some of those intercepting proxies are HTTP caches - whether you want it or not, you can't avoid it. Downloaded Javascript, in the browser, is not written by the user themselves, and in general trust must be carefully limited. It must be restricted in the effects it can have, especially effects on web domains different from where the script came from, or was linked from. Many security concerns aren't about absolutely preventing a possible attack from a single, specially written client, or from a specially written server that someone visits. They are about limiting the scope of damage on a population of users, particularly the damage caused by a malicious script that is downloaded and run by large numbers of unsuspecting users through cross-site scripting attacks, misleading sites and similar, and doubly especially damage that allows one site to spoof what users get when downloading from a different (innocent) site, which allows web virus/worm behaviour, and breaks the assumptions of existing security mechanisms. So it's important that downloaded Javascript can't use WebSocket to send controlled bytes that look enough like HTTP that they can poison a HTTP proxy's cache or HTTP framing, especially not that could make the browser show spoofed pages on _other_ web sites than where the script came from. There is some debate about whether this attack is realistic or not. I'm not sure if the reverse matters (mentioned earlier in this thread): downloaded Javascript using XmlHttpRequest to send controlled bytes (after the HTTP request headers) that look enough like WebSocket to make a server respond to that. None of this would apply if port 80 were not used, but it's regarded as an important use. (Though one test suggested port 80 is not actually much better for WebSockets than another port, and may be more prone to problems.) -- Jamie From jamie@shareable.org Wed Apr 6 18:01:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC7B3A69A2 for ; Wed, 6 Apr 2011 18:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 yigeHshuKbwF for ; Wed, 6 Apr 2011 18:01:38 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 74B723A6961 for ; Wed, 6 Apr 2011 18:01:38 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7dcl-0001yd-Rx; Thu, 07 Apr 2011 02:03:03 +0100 Date: Thu, 7 Apr 2011 02:03:03 +0100 From: Jamie Lokier To: David Endicott Message-ID: <20110407010303.GP26912@shareable.org> References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> 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 Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 01:01:40 -0000 David Endicott wrote: > > > Aside: why do we differentiate between binary and text frames? > > So the browser/user-agent knows what to do with it? AFAIK, that > API at the > W3C/WhatWG is TBD. > > [...] > In my case, when as a user-agent, I connect with WebSocket > sub-protocol "foo", I know that traffic via "foo" is going to be in > some format. That's a property of the specification of sub-protocol > "foo". If "foo" is going to support multiple content-types, I will > need to include that ability as part of sub-protocol "foo". In > neither case should WebSocket, the transport, care what the payload is. Javascript doesn't handle binary (at the moment), only text and integer arrays. A later version will support byte arrays. So the Javascript WebSocket API needs to know what type to give your application when a frame is received - turn it into a text string, or something else. Without the distinction on the wire, it would have to give you integer arrays (in current Javascript) every time. Because it wouldn't know when your byte sequences are to be interpreted as text. That would be very inconvenient. They could have designed the API so that _you_ ask for the message in whatever format you require, _after_ getting the message event. Like how XmlHttpRequest does it... (Aside: Or auto-formatted the payload to a string or array, when it is used in the script - but that would need a non-standard Javascript extension.) That would have saved a bit on the wire, reused an existing pattern, and been more extensible for future frame interpretations. But that's not how the API was designed, so the protocol must assist the API as it is. -- Jamie From jamie@shareable.org Wed Apr 6 18:14:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051213A69A2 for ; Wed, 6 Apr 2011 18:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 7tDiRCbCH37q for ; Wed, 6 Apr 2011 18:14:58 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 65C393A6961 for ; Wed, 6 Apr 2011 18:14:58 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7dpv-00021R-Qw; Thu, 07 Apr 2011 02:16:39 +0100 Date: Thu, 7 Apr 2011 02:16:39 +0100 From: Jamie Lokier To: David Endicott Message-ID: <20110407011639.GQ26912@shareable.org> References: <4D9595AC.6000307@warmcat.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] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 01:14:59 -0000 David Endicott wrote: > And don't get me started on the magic keys (Sec-WebSocket-Key). > Personally I believe this part of the handshake to be useless > hand-waving that does not provide what it's supposedly intended to do. > The client can generate any value and ignore the server's response, > it proves nothing. On the contrary, as that mechanism is intended to limit the effect of attacks via browsers running downloaded malicious scripts, and all browsers will check the server's response, it cannot be subverted in the way you describe. The attack vector is entirely due to a very large population of users who download and run scripts which can be malicious and whose effects have to be carefully limited to provide a more secure web. It is not there to protect non-browser clients from anything, or servers from non-browser clients doing whatever thay want. If someone writes a client which downloads scripts and runs them, or does the same attacks itself, yes that could attack the same web infrastructure, but not at the same scale because you can't muster millions of your custom clients so easily, and not necessarily affecting the places (esp. HTTP caches used by your targets) that you can reach with a browser attack. (Like you I'm not entirely convinced that it's all that great a mechanism, but let's at least understand what it is for.) -- Jamie From ibc@aliax.net Wed Apr 6 18:18:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8040B3A69A2 for ; Wed, 6 Apr 2011 18:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2mQ+-u8ct1P for ; Wed, 6 Apr 2011 18:18:27 -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 C26A03A6834 for ; Wed, 6 Apr 2011 18:18:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so1480841qwc.31 for ; Wed, 06 Apr 2011 18:20:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.221.131 with SMTP id ic3mr195533qcb.239.1302139211251; Wed, 06 Apr 2011 18:20:11 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Wed, 6 Apr 2011 18:20:11 -0700 (PDT) In-Reply-To: <20110407004644.GO26912@shareable.org> References: <4D961C5A.9020104@callenish.com> <4D96338F.5010603@callenish.com> <20110407004644.GO26912@shareable.org> Date: Thu, 7 Apr 2011 03:20:11 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jamie Lokier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 01:18:28 -0000 2011/4/7 Jamie Lokier : > None of this would apply if port 80 were not used, but it's regarded > as an important use. =C2=A0(Though one test suggested port 80 is not > actually much better for WebSockets than another port, and may be more > prone to problems.) A TCP/UDP port identifies a service, so reusing port 80 for another different protocol is a hack (IMHO). Thinking that operators and firewalls just allow outoing traffic to port 80/443 is giving them reasons to continue with such absurd policy. Designing a new protocol from scratch, with any kind of framing or codification (so a JavaScript code could not generate "valid HTTP requests" to poison a server) would solve most of the artificial issues appearing due to the usage of port 80 and the "like-HTTP" handshake. No HTTP proxies having to deal with WebSocket protocol, neither firewalls observing strange TCP traffic through the well known port 80 (which could seem an anomaly). Just a clean new protocol designed from scratch and running in a separate port, as any other network protocol. But I expect it's too late to change it or discuss about it. Just my opinio= n. Regards. --=20 I=C3=B1aki Baz Castillo From jamie@shareable.org Wed Apr 6 18:37:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CB73A69E7 for ; Wed, 6 Apr 2011 18:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 7WSGgiQXG0xp for ; Wed, 6 Apr 2011 18:37:01 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 2B9333A69E3 for ; Wed, 6 Apr 2011 18:37:01 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7eBH-000260-E4; Thu, 07 Apr 2011 02:38:43 +0100 Date: Thu, 7 Apr 2011 02:38:43 +0100 From: Jamie Lokier To: Andy Green Message-ID: <20110407013843.GR26912@shareable.org> References: <000701cbf022$9adb51d0$d091f570$@net> <4D959704.1090303@warmcat.com> <000c01cbf05f$d4df6280$7e9e2780$@net> <4D9616C9.1010408@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9616C9.1010408@warmcat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi , Greg Longtin Subject: Re: [hybi] Two Questions 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, 07 Apr 2011 01:37:02 -0000 Andy Green wrote: > On 04/01/2011 12:27 PM, Somebody in the thread at some point said: > > Hi - > > >How about I rephrase. Per the HTTP spec, can an HTTP server *not* respond > >to a properly formatted but invalid upgrade request from a client? Or, > >*should* an HTTP server respond? > > > >My interpretation of the WS spec is that a non response is correct for > >invalid WS upgrade requests. Does that play well with the HTTP spec? > > A TCP connection can get dropped any time; the http spec important as it > is in the world can't mandate otherwise. It can get dropped, but it's sensible to see it as a fault - i.e. network or system error to be reported - if it does get dropped at certain points, for example half-way through the HTTP headers of a response, or half-way through the body, or shortly after making the first request on a HTTP connection, which is a POST so unsafe to retry. This is quite distinct from a non-error TCP connection drop, when a server drops an idle persistent connection. In that case the client should quietly use another one. If a client expects a response to HTTP Upgrade and gets a closed socket, it would make sense to treat that as either a fault, a normal error (such as "can't do websocket") or a rejection - and it would be good to be clear and consistent about what clients should do. If that's only something which happens abnormally, not specified, it makes sense to treat it as a network or system error. If it's a behaviour allowed for in specification, then it makes sense to treat it as whatever the spec says can do that. > So it's "compatible with http" if a websocket server doesn't like what > the client asked for and just closes the socket flat. I think that behaviour is not compatible with HTTP-as-pragmatically-practised if it's the _first_ request on a connection. HTTP servers are not meant to close sockets without processing at least one request in a reasonable time frame, with the exception as ever being if there is some failure to comply due to network errors, crashed process or whatever. It matters because if regular HTTP servers did (or do) that in _normal_ response to a POST request, which is naturally first on the connection (for this reason), it would be impossible for HTTP clients to safely retry the request because they can't distinguish this from POST being accepted, processed, and then something breaking before they see the response. So lots of POST requests would break. So HTTP servers don't do this in normal operation, including normal HTTP errors. But because the client _knows_ it is making a WebSocket upgrade request, and because other HTTP requests (including XmlHttpRequest) _never_ look like one of these, there is no ambiguity in this case, so it's not actually harmful. We were lucky... > For websocket client as mentioned earlier again the specs can only > really talk about what websocket endpoints should do if compliant. Slightly unfortunate, if what they have to do looks like a HTTP implementation fault (rather than an HTTP error with defined meaning) prior to getting past the HTTP stage. But not really harmful. -- Jamie From jamie@shareable.org Wed Apr 6 18:57:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3AA3A69E6 for ; Wed, 6 Apr 2011 18:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 IRgTlSeWmJZu for ; Wed, 6 Apr 2011 18:57:50 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 6EFA33A69E4 for ; Wed, 6 Apr 2011 18:57:50 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7eVQ-00028k-EZ; Thu, 07 Apr 2011 02:59:32 +0100 Date: Thu, 7 Apr 2011 02:59:32 +0100 From: Jamie Lokier To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo Message-ID: <20110407015932.GS26912@shareable.org> References: <4D961C5A.9020104@callenish.com> <4D96338F.5010603@callenish.com> <20110407004644.GO26912@shareable.org> 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.13 (2006-08-11) Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 01:57:57 -0000 Iñaki Baz Castillo wrote: > 2011/4/7 Jamie Lokier : > > None of this would apply if port 80 were not used, but it's regarded > > as an important use.  (Though one test suggested port 80 is not > > actually much better for WebSockets than another port, and may be more > > prone to problems.) > > A TCP/UDP port identifies a service, so reusing port 80 for another > different protocol is a hack (IMHO). Thinking that operators and > firewalls just allow outoing traffic to port 80/443 is giving them > reasons to continue with such absurd policy. You shouldn't assume they are *deliberately* blocking all other ports. In some environments, ports 80/443 work because special forwarding has been *installed* for those ports, and there is no normal route to the internet. For example in some environments, clients have no connection to the internet at all, and port 80 works because an HTTP proxy gets all port 80 traffic and has its own, separate access to the internet, with either a browser-proxy-configuration script distributed to all browsers, or DNS pointing every non-local domain to that proxy, or an intercepting proxy as the default route. In those environments, "enabling" other ports is not a simple matter of removing port restrictions. Other than that: one of WebSocket's goals is to work in environments where HTTP works, to displace existing HTTP long-polling hacks with something a bit better. Also, to be fair, WebSocket does participate in the "web security model" (= restrictions on what scripts/HTML can do), so it has to some extent earned the right to be allowed in environments that trust "web browsing" (because they know browsers implement a security model and are heavily audited), and don't trust "arbitrary clients". It doesn't make that much sense, because many clients use port 80 and 443 for all sorts of random protocols these days. For better or worse, the "absurd policy" is likely to continue for some time. -- Jamie From jamie@shareable.org Wed Apr 6 19:28:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5AF3A6784 for ; Wed, 6 Apr 2011 19:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 VaOtE2KbBwlY for ; Wed, 6 Apr 2011 19:28:26 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id EE3533A659A for ; Wed, 6 Apr 2011 19:28:25 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Q7ez0-0002HU-Le; Thu, 07 Apr 2011 03:30:06 +0100 Date: Thu, 7 Apr 2011 03:30:06 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110407023006.GT26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> 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.13 (2006-08-11) Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking 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, 07 Apr 2011 02:28:28 -0000 Greg Wilkins wrote: > On 7 April 2011 06:10, David Endicott wrote: > > No, I mean *real* server push.   The synchronous nature of HTTP has not > > allowed "real-time" asynchronous updates from the server.    No matter how > > clever we've been so far (AJAX long polling, et al.) the slight latency has > > been an issue. > > We do live financial market trading at the inter-dealer level (ie. our > > customers are banks) and *any* latency is bad latency.   Yes, seriously. > > Being able to implement an asynchronous callback like mechanism is going to > > allow us to leverage the browser as viable UI tool. > > I think it is a misconception that WS is going to greatly improve > latency over solutions like long polling. > > Firstly this is all over TCP/IP and packets can be lost and timeouts > might be needed to trigger a resend. So no matter what you do you are > looking at a chance of >1s latency on the occasional message - TCP/IP > is not for controlling pace makers! It depends on the network. TCP on wired LANs rarely delays for 1s in the middle of a regular traffic flow. But on 3G, it regularly delays for >20s, and on my old 56k modem, it would sometimes delay for minutes, recovering from a burst of lost packets. Whatever it is, it's often several times longer than the time of a transient network outage. If you really need consistent minimum latency (like in a video game), you'd try for one of the quirky ways to access UDP or equivalent; that's a lot of non-portable work, though. > Long polling does have maximal latency of 3 x network latency, only if > you are unlucky and hit the no poll window or if you are streaming > lots of events. But for many traffic profiles long polling latency > is 1 x network latency. I think what David's getting at is inter-message delay _less_ than 1 x network latency (due to not having to wait for the previous one to be delivered), and maximal transmission latency close to 1 x network latency when there _are_ lots of events being streamed. That can't be done with the simplest (and most reliable) type of long-polling, where the client requests, server sends a complete response, client response with another request, server can then send next response... But it can be done with other long-polling communication patterns. -- Jamie From buskanaka@gmail.com Wed Apr 6 21:29:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A4C28C104 for ; Wed, 6 Apr 2011 21:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izWY4G6p1MiK for ; Wed, 6 Apr 2011 21:29:33 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 0616428C0CF for ; Wed, 6 Apr 2011 21:29:32 -0700 (PDT) Received: by ewy19 with SMTP id 19so770595ewy.31 for ; Wed, 06 Apr 2011 21:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bo0wFUzSQiEv2iwLxvF/TVZ23IHVl4aRZc4kiIAJuHM=; b=nI6Oy404BBHpPCjW5LmuTOnwnK6x/g1G/3Qo0o/9Yk/kDmJ3kCT4PJ4ukkT0SxNnfC GfIv8AZKBjcvP+/I8+sjCgm57qvBTieB0FFBvYI5fztVZ8sUypWFggN1MG/OHfEwfSFI /OyvygOWM6JihC+GZGU5pR8mTeis1mBLMHy4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Zmse0HO6yfPjAu1f49Svd6/LC7NECDYTAGefqjc+wh24R6hD6VEFNuUiXENuh6McE6 Vxu7MwOgAVKZ60Bo97cgVwdrGzmCWOa+LQIwCnjSMzd9dhBcwQN76TLgFpTGjJh9rW+g cRFSJzsx0xykzbvuVuxf9Kj8ddVcvZ7yys6e8= Received: by 10.14.15.156 with SMTP id f28mr136217eef.105.1302150676100; Wed, 06 Apr 2011 21:31:16 -0700 (PDT) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.22.16 with HTTP; Wed, 6 Apr 2011 21:30:56 -0700 (PDT) In-Reply-To: <20110406211245.GI26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> <20110406211245.GI26912@shareable.org> From: Joel Martin Date: Wed, 6 Apr 2011 23:30:56 -0500 X-Google-Sender-Auth: e9g9EMd2ywYNBFbQ2LdtNDLdNoA Message-ID: To: Jamie Lokier Content-Type: multipart/alternative; boundary=0016e65a09987e370104a04c9408 Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Slightly OT: To those "waiting for server push" 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, 07 Apr 2011 04:29:35 -0000 --0016e65a09987e370104a04c9408 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 4:12 PM, Jamie Lokier wrote: > > I'm glad we have it, it's an improvement (I hope), but I can't think > of any application that's made possible by it. (Would love examples > if you have any!) > IMO, the lower latency (once established), and more socket-like nature of WebSockets will enable a whole realm of new web applications. The combination of fast Javascript engines and WebSockets is what made noVNC ( https://github.com/kanaka/noVNC) possible. Existing web applications that use AJAX or long-polling may or may not be helped all that much by the lower latency achievable with a WebSocket connection. It's the new applications that become possible that are exciting to me. Even if the latency of AJAX/long-poll was sufficient for noVNC, I would never have made the conceptual leap by thinking in terms of HTTP plus a pile of kludges. Everybody is excited about the video and audio tags that is part of the next HTML, but in my opinion the second most important part of the new evolving open web platform is WebSockets (the first being fast Javascript engines). Regards, Joel Martin (kanaka) --0016e65a09987e370104a04c9408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 6, 2011 at 4:12 PM, Jamie Lokier <jamie@shareable.o= rg> wrote:

I'm glad we have it, it's an improvement (I hope), but I can't = think
of any application that's made possible by it. =A0(Would love examples<= br> if you have any!)

IMO, the lower latenc= y (once established), and more socket-like nature of WebSockets will enable= a whole realm of new web applications. The combination of fast Javascript = engines and WebSockets is what made noVNC (https://github.com/kanaka/noVNC) possible.

Existing web applications that use AJAX or long-polling= may or may not be helped all that much by the lower latency achievable wit= h a WebSocket connection. It's the new applications that become possibl= e that are exciting to me.

Even if the latency of AJAX/long-poll was sufficient fo= r noVNC, I would never have made the conceptual leap by thinking in terms o= f HTTP plus a pile of kludges.

Everybody is excite= d about the video and audio tags that is part of the next HTML, but in my o= pinion the second most important part of the new evolving open web platform= is WebSockets (the first being fast Javascript engines).

Regards,

Joel Martin (kanaka)<= /div>
--0016e65a09987e370104a04c9408-- From w@1wt.eu Wed Apr 6 22:38:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AE03A685D for ; Wed, 6 Apr 2011 22:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=-0.518, 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 BTOUIrmPKsUq for ; Wed, 6 Apr 2011 22:38:38 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 3A4A03A684D for ; Wed, 6 Apr 2011 22:38:37 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p375eJMI006029; Thu, 7 Apr 2011 07:40:19 +0200 Date: Thu, 7 Apr 2011 07:40:19 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20110407054019.GB5915@1wt.eu> References: <4D99F000.8090001@gmx.de> <20110404182625.GD20671@1wt.eu> <20110406194602.GF26912@shareable.org> <20110406203423.GB2032@1wt.eu> <20110406233514.GK26912@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110406233514.GK26912@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Robert Gezelter on the current spec 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, 07 Apr 2011 05:38:40 -0000 Hi Jamie, On Thu, Apr 07, 2011 at 12:35:14AM +0100, Jamie Lokier wrote: > Willy Tarreau wrote: > > > > His pause/resume mechanism is what I normally call flow control. It might > > > > be nice to study the idea, though it can have huge security impacts as it > > > > has on Ethernet and TCP (easy DoSes). > > > > > > Note that per-channel flow control is essential for safe & secure > > > multiplexing. If it is omitted, either the flows aren't independent > > > (head of line blocking), or a memory DOS is possible (demuxer has to > > > read & buffer eagerly without bound). Either way makes > > > application-independent multiplexing unsafe, and the former can lead > > > to deadlocks; flow control solves both problems. This is especially > > > important for "invisible" multiplexing inside the browser and/or > > > intermediaries. > > > > Multiplexing can be made safe using fair and simple algorithms. Some > > of them involve limiting the fragment size (I mean refusing fragments > > larger than negociated). After all, that's exactly what happens in an > > event-based proxy : it reads chunks up to a certain size from many > > sockets and processes them in turns so that everyone gets served. It's > > the implementer's responsibility not to stick on the same flow forever > > (on the multiplexer size) and the demux must check fragment sizes. > > That doesn't work. The failure case is what I mean by "the flows > aren't independent". > > Think about a proxy, which is receiving mux'd WebSocket (for example), > demuxing and forwarding fragments to individual server processes - > perhaps on different servers at a different location. > > Now if any of those server processes runs slower than the others, it > will cause _all_ the processes to slow down to that speed, _or_ the > proxy will have to buffer up fragments for that slow server, while > it forwards received fragments to the others. OK got it! We were both talking about the opposite side. I thought you were suggesting that a client could make a multiplexer fill its channel using too large data, but in fact it's the opposite, it's the fact that the muxed channel stalls due to one stalled flow. It's sometimes required to implement window management on top of this but this becomes complex and sometimes inefficient (eg: tcp over tcp). Thanks for the explanation Jamie! Willy From w@1wt.eu Wed Apr 6 22:48:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8062D3A69FB for ; Wed, 6 Apr 2011 22:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=-0.511, 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 00vaQqRdD0+H for ; Wed, 6 Apr 2011 22:48:18 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id C243D3A69F5 for ; Wed, 6 Apr 2011 22:46:52 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p375l3UM006075; Thu, 7 Apr 2011 07:47:03 +0200 Date: Thu, 7 Apr 2011 07:47:03 +0200 From: Willy Tarreau To: Jamie Lokier Message-ID: <20110407054703.GC5915@1wt.eu> References: <4D989304.9080802@warmcat.com> <20110407002536.GN26912@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110407002536.GN26912@shareable.org> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 05:48:20 -0000 On Thu, Apr 07, 2011 at 01:25:36AM +0100, Jamie Lokier wrote: > Greg Wilkins wrote: > > Hello frames can be done server->client->server to avoid a RTT's but > > maybe it is better to have them client->server->client so that the > > upgrade over HTTP would take one more RTT than a dedicated port and > > thus give an incentive to push for opening a port. > > To reduce RTTs, I would have the protocol following HTTP Upgrade be > allowed to _inherit_ initial bytes encoded in one or more designated > HTTP headers from the HTTP Upgrade request. Both request and response > could contain such "pre-transmitted" bytes. +1, I like this idea a lot. We could even exchange small messages within a single RTT : HTTP request + small request + closing handshake HTTP response + small response + closing handshake That would be similar to HTTP GET+200 with short-lived connections but adapted to some services offered over WS. Regards, Willy From w@1wt.eu Wed Apr 6 22:50:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DED3A684D for ; Wed, 6 Apr 2011 22:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-0.654, 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 tBjJz4i7yJpM for ; Wed, 6 Apr 2011 22:49:58 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 882E328C101 for ; Wed, 6 Apr 2011 22:49:21 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p375oxPT006104; Thu, 7 Apr 2011 07:50:59 +0200 Date: Thu, 7 Apr 2011 07:50:59 +0200 From: Willy Tarreau To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo Message-ID: <20110407055059.GD5915@1wt.eu> References: <4D961C5A.9020104@callenish.com> <4D96338F.5010603@callenish.com> <20110407004644.GO26912@shareable.org> 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.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 05:50:00 -0000 On Thu, Apr 07, 2011 at 03:20:11AM +0200, Iñaki Baz Castillo wrote: > 2011/4/7 Jamie Lokier : > > None of this would apply if port 80 were not used, but it's regarded > > as an important use.  (Though one test suggested port 80 is not > > actually much better for WebSockets than another port, and may be more > > prone to problems.) > > A TCP/UDP port identifies a service, so reusing port 80 for another > different protocol is a hack (IMHO). Thinking that operators and > firewalls just allow outoing traffic to port 80/443 is giving them > reasons to continue with such absurd policy. > > Designing a new protocol from scratch, with any kind of framing or > codification (so a JavaScript code could not generate "valid HTTP > requests" to poison a server) would solve most of the artificial > issues appearing due to the usage of port 80 and the "like-HTTP" > handshake. No HTTP proxies having to deal with WebSocket protocol, > neither firewalls observing strange TCP traffic through the well known > port 80 (which could seem an anomaly). Just a clean new protocol > designed from scratch and running in a separate port, as any other > network protocol. And conversely, it can work *because* some forwarding service, URL filtering etc... is installed on these ports only. Why do you think that previous attempts to make HTTP bidirectional were also running on port 80, why didn't they simply pick any random port instead ? Simply because this one only works. If we defined a specific port *and* decided to abandon the HTTP upgrade, I predict that WS would not replace the other technologies that already work. Regards, Willy From andy.warmcat.com@googlemail.com Wed Apr 6 22:52:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C553A687A for ; Wed, 6 Apr 2011 22:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqbQJU8lN36y for ; Wed, 6 Apr 2011 22:52:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 18EF73A684D for ; Wed, 6 Apr 2011 22:52:39 -0700 (PDT) Received: by wyb29 with SMTP id 29so2098456wyb.31 for ; Wed, 06 Apr 2011 22:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2RY20mCynIuvYNh1Hpt+/KK12KNvhZM9XWQnEIvmk4I=; b=aX4E8X7IdwVTBQHkXs5yWoC03U398mRp96/4UIG3zntRCjzWs+k59IaVMgenYlwSG4 IQ4rsgOnVSw9fPIRejBVPJzkouaSlslbD9XxyPGY+4t/+oIn1gPyUbPHD0aHTAJH9nKo XtVSR+dUPUJTkcANakaFsn51R5j/bSwE6Ekl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=g8q2BdpCI+JpadqE2p+wvBp/L06H8ZNaAIB7kWvci11KZa6Q0RQVy9YTdhquhKkAH0 ksqz+XA3+wG1NHg+7isX/Z3TzjkLM9hjgFupNqS8YEjAQZUiqI9m4SnsOtcdLnLOk9ig dRSnD7fKerjYbbKuvoAb1caeEJQmgc4yWfw58= Received: by 10.216.158.21 with SMTP id p21mr403470wek.99.1302155663689; Wed, 06 Apr 2011 22:54:23 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id l24sm805504wbc.13.2011.04.06.22.54.20 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 22:54:21 -0700 (PDT) Sender: Andy Green Message-ID: <4D9D518A.8080502@warmcat.com> Date: Thu, 07 Apr 2011 06:54:18 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Willy Tarreau References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406210945.GC2032@1wt.eu> In-Reply-To: <20110406210945.GC2032@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Full Frame Masking / identifying allegedly broken 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, 07 Apr 2011 05:52:45 -0000 On 04/06/2011 10:09 PM, Somebody in the thread at some point said: Hi - >> Has anyone demonstrated an actual instance of a problem so far, either as >> revealed during WS implementation testing or from targeted >> vulnerability assessment? > > No, but see below. > >> Does anyone have a suspicion that a particular vendor's product might be at >> risk? > > Not a particular vendor either. The problem is that it has been proven via "It has been claimed...", it's not proven to me anyway at all. > an experience that some unidentified products behave badly when subjected > to WS-like traffic. Those products could not be identified because they're > likely transparent proxies. By "behave badly", I mean things like connection I have already mentioned some weeks ago I would be interested to make a fuzzer or other tool in libwebsockets if I get some help with exactly what packets it was claimed it needs to send. Then we could expect to 'out' the allegedly "badly behaving" intermediaries and I will be able to agree it is proven. You'd think people would be highly interested to run such a security tool on their own client side and make sure they are not vulnerable to a proposed attack that had such a high public profile and claimed apocalyptic results. Because if they were vulnerable to -76 they are still sitting there vulnerable to the same packets issued another way from client side. Surely people would want to know and swap out or upgrade that intermediary. > Yet it's still well balanced, it's far less expensive than solutions that I agree if you compare it to AES that quite a few people insisted was absolutely necessary or it would be The End Of The Internet, then Ian Fette balanced those demands well. -Andy From salvatore.loreto@ericsson.com Thu Apr 7 01:08:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55D528C10A for ; Thu, 7 Apr 2011 01:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 S8VPyu35G7Ua for ; Thu, 7 Apr 2011 01:08:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 176CF28C108 for ; Thu, 7 Apr 2011 01:08:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-e4-4d9d71804d72 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EC.C4.11171.0817D9D4; Thu, 7 Apr 2011 10:10:40 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 7 Apr 2011 10:10:39 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1317B27F9; Thu, 7 Apr 2011 11:10:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CAB5C50B6A; Thu, 7 Apr 2011 11:10:38 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0BC8D50B63; Thu, 7 Apr 2011 11:10:37 +0300 (EEST) Message-ID: <4D9D717D.6080103@ericsson.com> Date: Thu, 7 Apr 2011 11:10:37 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bruce Atherton References: <4D9CA4E1.70409@callenish.com> <6.2.5.6.2.20110406132815.0c3b7248@resistor.net> <4D9CD86F.8000908@callenish.com> In-Reply-To: <4D9CD86F.8000908@callenish.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" , Gabriel Montenegro , S Moonesamy Subject: Re: [hybi] Arguments in the FAQ 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, 07 Apr 2011 08:08:58 -0000 On 4/7/11 12:17 AM, Bruce Atherton wrote: > On 06/04/2011 1:45 PM, S Moonesamy wrote: >> Hi Bruce, >> At 10:37 06-04-2011, Bruce Atherton wrote: >>> I have an issue with the FAQ that I would appreciate some guidance >>> from the WG on. >>> >>> I have noted at the top of the FAQ that it is intended that it >>> describe the state of the protocol as it currently exists and how it >>> got that way. I do not believe it is intended as a platform for >>> debate concerning whether a particular choice is a good one. The FAQ is >> There is a note at the top of the FAQ which says: >> >> "A note to contributors: Please do not use the FAQ as a debating >> document. >> The FAQ is intended to describe the protocol as it is currently >> defined in >> the spec. If you want to see a change in the spec, bring it up on the >> mailing list and see if you can achieve a rough consensus. Do not >> present >> your arguments here as they will be removed. > Yes, I wrote that a few weeks ago. I believe it is a good idea as the > FAQ should be a document of the history of decisions in order to explain > the protocol, not a place to argue about future changes. But that is > just my opinion. +1 actually that was also my original idea when I suggested to start a FAQ > Yesterday there was an edit that went directly against that policy, so I > thought I would bring the matter up here to see if anyone else supported > my view. > >> A second note to contributors: Please do not remove the Questions >> when answering >> them. This is a FAQ = Frequently Answered Questions, not FA = >> Frequent Answers. >> Please write answers in a FAQ style and not book narrative style." > I take this to be a reference to the fact that the actual FAQ starts > some distance down in the document. Does anyone object to me moving the > goals of Websockets to a separate Wiki page and providing a reference to > it from the FAQ? Then we can get rid of that note. the HyBi wg has still as a deliverable a document describing the Design Space characterization where I think the goals descriptions of WebSockets should go. (see: http://tools.ietf.org/wg/hybi/charters _ The precedent version of the document has expired and not renewed mainly due to lack of time/cycles from the editors... http://tools.ietf.org/wg/hybi/draft-ietf-hybi-design-space/ If you would like help and have cycles for it, please contact the chairs (Gabriel and I). For the time being, I do not want to start another wiki page for something that is still supposed to go in a wg item. cheers /Sal -- Salvatore Loreto www.sloreto.com From dendicott@gmail.com Thu Apr 7 06:33:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F053A6916 for ; Thu, 7 Apr 2011 06:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEsmtZRRZ8tt for ; Thu, 7 Apr 2011 06:33:14 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3B95D3A690F for ; Thu, 7 Apr 2011 06:33:14 -0700 (PDT) Received: by wwa36 with SMTP id 36so2134675wwa.13 for ; Thu, 07 Apr 2011 06:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Uz4wqz+ymQDMozQIq2INERxpUKtRFGu0+WkCW8V79VY=; b=u+81qs7BVktOhkQQ4mXKnJdksjtNPEBcdVPgTJVSaQT/mczhLpUPM9+Vh7miXL9eGt 3NTDhPmtwOgOzrVzZvMBHgZIpZMgFZDcRjWGf1fZEKPOFreHsonpckUjUi0wsnjJtciB 59QigIo0PqoaZMsKjRGpIuaMn/se4HpksQwts= 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=cEtiek5Z9WenM4omywbbAkNbonTmSnDMHCwD8Cgx8MLiOulNEeNvkatFRHj12L6lI/ pw7Jjknw6PDT5OVNMd6+2IvNPANYP+Gn4AbL7frprSkIPkcb8Nrxu4UWmykDtbgodOxP QB6Ei32V5LER+jbFxVLty4SvK/2VunSRMmEuM= MIME-Version: 1.0 Received: by 10.216.143.134 with SMTP id l6mr895105wej.2.1302183298295; Thu, 07 Apr 2011 06:34:58 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 06:34:58 -0700 (PDT) In-Reply-To: <20110406211245.GI26912@shareable.org> References: <4D9C4F0C.5080504@rlgsc.com> <4D9C51A7.2060704@warmcat.com> <4D9C75E6.5050604@warmcat.com> <20110406195527.GG26912@shareable.org> <20110406211245.GI26912@shareable.org> Date: Thu, 7 Apr 2011 09:34:58 -0400 Message-ID: From: David Endicott To: Jamie Lokier Content-Type: multipart/alternative; boundary=0016e6ddfee4ed68da04a0542ca6 Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] Slightly OT: To those "waiting for server push" 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, 07 Apr 2011 13:33:15 -0000 --0016e6ddfee4ed68da04a0542ca6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 5:12 PM, Jamie Lokier wrote: > David Endicott wrote: > >>> Oh, and ya, my employers have been waiting years for > >>> "server-push" to the browser, but whatever. > > Server push means the ability to send messages to the client when the > server has a message to send, without polling, after the client has > established a connection for this purpose. > > If it works reasonably well, it exists regardless of how it's > implemented. (WebSocket is not without hacks either.) > Agreed. Unfortunately, part of what I have to deal with in my situation is perception. Having a polling layer as part of the system is anathema to our firm. The fact that the performance difference is negligible is irrelevant. *Any* impairment of timely message delivery is a concern. (Note: our time critical application will be used over a private network, so Internet latencies are not a factor) Also, a "true" asynchronous mechanism produces a much cleaner implementation - without the need for ad-hoc "kludges" to emulate that behavior from synchronous HTTP. I must admit certain bias towards elegance. > If someone is waiting for server-push before they can write that async > application they dreamed of... well, there is no reason to wait, there > is good software and toolkits to do it already. > We have and we do. But until the recent arrival of certain new technologies (WS, CSS2, HTML5 and fast JS engines) using the browser as a platform neutral User Interface has been....unsatisfactory. > > WebSocket only replaces part of the server push problem, and it > doesn't introduce any new behaviour we can't already do, that I can see. > Personally, I like how it makes explicit the asynchronous nature of the communication. If I had to guess (and that's always risky) - I suspect WS is going to end up doing content centric API's (similar to REST) and HTTP will become presentation centric. ie. your browser does HTTP to fetch some HTML/CSS and then uses WS to fill in the content. And that content can be dynamically live. > I'm glad we have it, it's an improvement (I hope), but I can't think > of any application that's made possible by it. (Would love examples > if you have any!) > True, I doubt there is any application that WS makes "possible", but I'd argue there are a boatload that would become "practical". --0016e6ddfee4ed68da04a0542ca6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 6, 2011 at 5:12 PM, Jamie Lo= kier <jamie@sha= reable.org> wrote:
David Endicott wrote:
>>> =A0 =A0Oh, and ya, my employers have been waiting years for >>> =A0 =A0"server-push" to the browser, but whatever.
Server push means the ability to send messages to the client when the
server has a message to send, without polling, after the client has
established a connection for this purpose.

If it works reasonably well, it exists regardless of how it's
implemented. =A0(WebSocket is not without hacks either.)

Agreed. =A0 Unfortunately, part of what I have to deal wi= th in my situation is perception. =A0 Having a polling layer as part of the= system is=A0anathema to our firm. =A0 The fact that the performance differ= ence is=A0negligible=A0is irrelevant. =A0*Any* impairment of timely message= delivery is a concern. =A0 =A0(Note: our time critical application will be= used over a private network, so Internet latencies are not a factor)

Also, a "true" asynchronous mechanism produce= s a much cleaner implementation - without the need for ad-hoc "kludges= " to emulate that=A0behavior=A0from=A0synchronous=A0HTTP. =A0I must ad= mit certain bias towards elegance.


If someone is waiting for server-push before they can write that async
application they dreamed of... well, there is no reason to wait, there
is good software and toolkits to do it already.

We have and we do. =A0 But until the recent=A0arrival=A0of certain= new technologies (WS, CSS2, HTML5 and fast JS engines) using the browser a= s a platform neutral User Interface has been....unsatisfactory.
=A0

WebSocket only replaces part of the server push problem, and it
doesn't introduce any new behaviour we can't already do, that I can= see.

Personally, I like how it makes= =A0explicit=A0the asynchronous nature of the communication. =A0 If I had to= guess (and that's always risky) - I suspect WS is going to end up doin= g content centric API's =A0(similar to REST) and HTTP will become prese= ntation centric. =A0 ie. your browser does HTTP to fetch some HTML/CSS and = then uses WS to fill in the content. =A0 And that content can be dynamicall= y live.


I'm glad we have it, it's an improvement (I hope), but I can't = think
of any application that's made possible by it. =A0(Would love examples<= br> if you have any!)

True, I doubt there i= s any application that WS makes "possible", but I'd argue the= re are a boatload that would become "practical".
=A0
--0016e6ddfee4ed68da04a0542ca6-- From dendicott@gmail.com Thu Apr 7 06:46:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D636028C0FB for ; Thu, 7 Apr 2011 06:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Uf2E4-aNN1k for ; Thu, 7 Apr 2011 06:46:52 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A1BA328B56A for ; Thu, 7 Apr 2011 06:46:51 -0700 (PDT) Received: by wwa36 with SMTP id 36so2146449wwa.13 for ; Thu, 07 Apr 2011 06:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vHMFtselH4hE5quTqB04Iq4J83/t/HahU7ILnkYkPKQ=; b=VxuXVWyhzWl3Zvk9Qd2YQcEeFO2yRyQzJ4d7j0X4/oHOG4CtkitFP//Pr2CvQDzzhQ +bZqgDBwuW6pSjc5H05vQq32aUhHgj9BMCyTBEzrIZoulOm7osqJRkJFydnDtp+XzP/f 109nn4XBozVZ9gSbl+OhatGBf2YnIBECzblzE= 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=eUD6psxjKJTDVgns88zba+UFJPfCGNbop2BUy4jjebNh0mz2mM7GNO1CLgEt8IiAFy J9lUay4C4yO3llZa/BF6fCEO8XQ49PsICCYsbVZyUVJUEEp550jDEyLdodpr/SmRWIVw a/MEojnuaRM81nF0YjO7hPmHTH9REj1LfjbgY= MIME-Version: 1.0 Received: by 10.216.144.86 with SMTP id m64mr275201wej.32.1302184115516; Thu, 07 Apr 2011 06:48:35 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 06:48:35 -0700 (PDT) In-Reply-To: <20110407011639.GQ26912@shareable.org> References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> Date: Thu, 7 Apr 2011 09:48:35 -0400 Message-ID: From: David Endicott To: Jamie Lokier Content-Type: multipart/alternative; boundary=0016e6d77f1ba3383304a0545db4 Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 13:46:52 -0000 --0016e6d77f1ba3383304a0545db4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 9:16 PM, Jamie Lokier wrote: > David Endicott wrote: > > And don't get me started on the magic keys (Sec-WebSocket-Key). > > On the contrary, as that mechanism is intended to limit the effect of > attacks via browsers running downloaded malicious scripts, and all > browsers will check the server's response, it cannot be subverted in > the way you describe. > Yes, but...all it provides is a method for a browser to check if the server is doing WS. Which, imho, is functionally useless, especially when paired with HTTP Upgrade: WebSocket in the opening handshake. The server accepts the upgrade to WS or it doesn't. A secondary mechanism to confirm that is...redundantly useless. A malicious script trying to... a) attack WS - is going to be happy the browser confirmed it b) attack HTTP using WS - won't care, c) attack WS using crafted HTTP- will create bogus Key and ignore server's response d) attack HTTP using crafted WS - it's a HTTP Upgrade and Key again doesn't matter. A non-browser client-agent can, of course, generate anything it wants and all bets are off. The attack vector is entirely due to a very large population of users > who download and run scripts which can be malicious and whose effects > have to be carefully limited to provide a more secure web. > The same-origin policy is a much better mechanism. Scripts should only be trusted to talk with the servers they came from. > (Like you I'm not entirely convinced that it's all that great a > mechanism, but let's at least understand what it is for.) > > Ya, I understood the motivation. I didn't understand why anyone thought it actually helped. But, it's a non-impediment and harmless, so I'm going to let it slide. Sometimes it's nice to leave a little WTF for future generations. --0016e6d77f1ba3383304a0545db4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 6, 2011 at 9:16 PM, Jamie Lo= kier <jamie@sha= reable.org> wrote:
David Endicott wrote:
> =A0 =A0And don't get me started on the magic keys (Sec-WebSocket-K= ey).

On the contrary, as that mechanism is intended to limit the effect of=
attacks via browsers running downloaded malicious scripts, and all
browsers will check the server's response, it cannot be subverted in the way you describe.

Yes, but...all it= provides is a method for a browser to check if the server is doing WS. =A0= Which, imho, is functionally useless, especially when paired with HTTP Upg= rade: WebSocket in the opening handshake. =A0 The server accepts the upgrad= e to WS or it doesn't. =A0A secondary mechanism to confirm that is...re= dundantly useless.

A malicious script trying to...

a) attack WS - is going to be happy the browser confirmed it=A0
b) attack HTTP using WS - won't care,=A0
c) attack WS using = crafted HTTP- will create bogus Key and ignore server's response
d) attack HTTP using crafted WS - it's a HTTP Upgrade and Key agai= n doesn't matter.

A non-browser client-agent c= an, of course, generate anything it wants and all bets are off.


The attack vector = is entirely due to a very large population of users
who download and run scripts which can be malicious and whose effects
have to be carefully limited to provide a more secure web.
=

The same-origin policy is a much better mechanism. =A0 = Scripts should only be trusted to talk with the servers they came from. =A0= =A0
=A0
(Like you I'm not entirel= y convinced that it's all that great a
mechanism, but let's at least understand what it is for.)

Ya, I= understood the motivation. =A0 I didn't understand why anyone thought = it actually helped.
=A0
But, it's a non-impediment and harmless, so I'm = going to let it slide. =A0 Sometimes it's nice to leave a little WTF fo= r future generations.

--0016e6d77f1ba3383304a0545db4-- From dendicott@gmail.com Thu Apr 7 07:14:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9581528C0E1 for ; Thu, 7 Apr 2011 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRPlwYrl5qpj for ; Thu, 7 Apr 2011 07:14:52 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4768428C0CE for ; Thu, 7 Apr 2011 07:14:52 -0700 (PDT) Received: by ewy19 with SMTP id 19so929184ewy.31 for ; Thu, 07 Apr 2011 07:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HCwYqcFZQ6f5+N3s1nw6qX0Nt7hSe60XYp4cu2NWgk8=; b=YOhtQUx93MZTehE3qYMHKfXDzDAG6f36x0Pt/SaJSVzPXmYcmihsG0XXtxqknarZYz 8kxm4rodq0ZtQUHzYbpsIZzVey+wbDCzuIkeOk7C+zz3zJbo+apU8O63Kt0dYl0b0s13 Rel84nhd5B4/Om3UdKd/IveGwinMlFBj0KQAk= 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=a13WunQla3Chc7u5VzgmeuusdAkbTso7ZDFKnm5vEYowdEnynGKvC/gBoDf6SH9MP0 Z3cuoZNsXLGdWcfwF9kig0LMlfK9BaO1JATvFs4hj+ylUZNu7oTDd2RVyS+QGUGDo4DK DZEgPL8qRLuYqc0Gw7tgQJkMjlc/wUOatvdew= MIME-Version: 1.0 Received: by 10.216.69.131 with SMTP id n3mr896567wed.47.1302184584919; Thu, 07 Apr 2011 06:56:24 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 06:56:24 -0700 (PDT) In-Reply-To: <20110407010303.GP26912@shareable.org> References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> Date: Thu, 7 Apr 2011 09:56:24 -0400 Message-ID: From: David Endicott To: Jamie Lokier Content-Type: multipart/alternative; boundary=000e0cd66e6e9dbba104a054790b Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 14:14:53 -0000 --000e0cd66e6e9dbba104a054790b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 6, 2011 at 9:03 PM, Jamie Lokier wrote: > David Endicott wrote: > > > > > Aside: why do we differentiate between binary and text frames? > > > > So the browser/user-agent knows what to do with it? AFAIK, that > > So the Javascript WebSocket API needs to know what type to give your > application when a frame is received - turn it into a text string, or > something else. > Javascript strings can hold any byte values, yes? We could have delivered the WS frame payload as a JS string and be done with it. It would be up to the application to know if that's UTF-8 or ASCII or raw binary or whatever. > They could have designed the API so that _you_ ask for the message in > whatever format you require, _after_ getting the message event. > Like how XmlHttpRequest does it... > Ya, that might have been nice. > But that's not how the API was designed, so the protocol must > assist the API as it is. I don't have a significant concern about the frame data typing. It makes excellent practical sense to have a TEXT frame for the majority of use-cases where it's passing text around (HTML,JSON, etc.). And a BINARY frame for the odd folks who need to do something different. It is a practically simpler mechanism than incorporating a whole Content-Type system. I suppose you could specify Content-Type on the HTTP Upgrade, but I'd rather have a per-message content specification, not a entire-stream one. --000e0cd66e6e9dbba104a054790b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 6, 2011 at 9:03 PM, Jamie Lo= kier <jamie@sha= reable.org> wrote:
David Endicott wrote:
>
> =A0 =A0> Aside: why do we differentiate between binary and text fra= mes?
>
> =A0 =A0 =A0So the browser/user-agent knows what to do with it? =A0AFAI= K, that
=A0
So the Javascript WebSocket API needs to know what type to give your
application when a frame is received - turn it into a text string, or
something else.

Javascript strings can = hold any byte values, yes? =A0 =A0We could have delivered the WS frame payl= oad as a JS string and be done with it. =A0 It would be up to the applicati= on to know if that's UTF-8 or ASCII or raw binary or whatever.
=A0
They could have designed the = API so that _you_ ask for the message in
whatever format you require, _after_ getting the message event.
=A0Like how XmlHttpRequest does it...

Y= a, that might have been nice.
=A0
But that's not how the API was designed, so the protocol must
assist the API as it is.

I don't have a= significant concern about the frame data typing. =A0

<= div>It makes excellent practical sense to have a TEXT frame for the majorit= y of use-cases where it's passing text around (HTML,JSON, etc.). =A0 = =A0And a BINARY frame for the odd folks who need to do something different.= =A0 It is a practically simpler mechanism than incorporating a whole Conte= nt-Type system.

I suppose you could specify Content-Type on the HTTP Up= grade, but I'd rather have a per-message content specification, not a e= ntire-stream one.
--000e0cd66e6e9dbba104a054790b-- From jat@google.com Thu Apr 7 07:43:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B43228C134 for ; Thu, 7 Apr 2011 07:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.93 X-Spam-Level: X-Spam-Status: No, score=-105.93 tagged_above=-999 required=5 tests=[AWL=0.046, 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 2thyd97E+rg5 for ; Thu, 7 Apr 2011 07:43:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7D74528C125 for ; Thu, 7 Apr 2011 07:43:52 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p37EjaHR028132 for ; Thu, 7 Apr 2011 07:45:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302187536; bh=tbVtEsHO06T36vO22WxSOE4iJTI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BYtAzJ9a5sry7KraUULHUFxDAZg3JD2OHhnqihvbtT4sFWHXDUVBzdx24zrOlFpmZ 6brES5wcRsRA+80e4dMvA== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by wpaz29.hot.corp.google.com with ESMTP id p37EjZ6k004905 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Apr 2011 07:45:35 -0700 Received: by gyg4 with SMTP id 4so1164925gyg.32 for ; Thu, 07 Apr 2011 07:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jEqMoXFgMKE1Dt568oi/N0kpZ9PTtsj5j9mGuGAzor0=; b=Dpd6skHG0tzwX1xQA9H4KD24Mp4aT4EFcZ4X4AY+vrYFjg8rjz0q+OovaUpKL8r4+R yTbEMpVoV0bZcsEFa3dA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=eSDJWzGBEAeWyAbWrNQMPCRRisIxaEwmLODuFheE3/3jofHQ/hcAeDfLK9I1IcYFj1 ChIwmaSg5EQf4c5YjA4A== Received: by 10.150.170.19 with SMTP id s19mr851108ybe.67.1302187535126; Thu, 07 Apr 2011 07:45:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 7 Apr 2011 07:45:15 -0700 (PDT) In-Reply-To: References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> From: John Tamplin Date: Thu, 7 Apr 2011 10:45:15 -0400 Message-ID: To: David Endicott Content-Type: multipart/alternative; boundary=000e0cd4cc3c7655a404a0552929 X-System-Of-Record: true Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 14:43:53 -0000 --000e0cd4cc3c7655a404a0552929 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2011 at 9:56 AM, David Endicott wrote: > Javascript strings can hold any byte values, yes? We could have > delivered the WS frame payload as a JS string and be done with it. It > would be up to the application to know if that's UTF-8 or ASCII or raw > binary or whatever. > No, Javascript strings are sequences of UTF16 characters. Even subject to that restriction, several browsers munge the data you give it if it includes combining marks or unpaired surrogates, so you can't just pass arbitrary data in a JS string and expect it to be unmodified. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4cc3c7655a404a0552929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2011 at 9:56 AM, David Endicott <= span dir=3D"ltr"><dendicott@gmail= .com> wrote:
Javascript strings can hold any byte values= , yes? =C2=A0 =C2=A0We could have delivered the WS frame payload as a JS st= ring and be done with it. =C2=A0 It would be up to the application to know = if that's UTF-8 or ASCII or raw binary or whatever.

No, Javascript stri= ngs are sequences of UTF16 characters. =C2=A0Even subject to that restricti= on, several browsers munge the data you give it if it includes combining ma= rks or unpaired surrogates, so you can't just pass arbitrary data in a = JS string and expect it to be unmodified.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd4cc3c7655a404a0552929-- From dendicott@gmail.com Thu Apr 7 08:16:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE2328C0F3 for ; Thu, 7 Apr 2011 08:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBJ8kZBYhvHd for ; Thu, 7 Apr 2011 08:16:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B917728C0EB for ; Thu, 7 Apr 2011 08:16:10 -0700 (PDT) Received: by wyb29 with SMTP id 29so2549716wyb.31 for ; Thu, 07 Apr 2011 08:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BpuC9nkikXOBFe1jYFx1loSBZsuu76TcYkAhbqgeb+k=; b=mt2ZsW6vQD3Bh2s2R2MErCNFByN9zbUB7R8vDLmINbR7Uu3hDx5gv/99WM+gxaQvhQ gfekmKLmoRPrjtHcb1IwOabraa6LHDB5nCNnlixJoVqU35wGo2LpPQXzMNDrVsi0xsdy QXYsH9K78wwWFMe28LfpoZ9W+BUE1/YmdNkRU= 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=XLoRTStJ26BO47/rKfqxvjc5ZifOAqInk57WXO3aO/alNdlR0exJ+7Od9tnRRWWv2w p3WB1RcqJGqG4yQkTRJgZRvhZF0c7Nf6fH0JAUp2oodHhmLeeJIkDiMbO/Qp1LaW1PHR 5iZ89bTao4T2ruBz+H35KCxC3kznz9FwTv2yQ= MIME-Version: 1.0 Received: by 10.216.143.134 with SMTP id l6mr1012027wej.2.1302189474583; Thu, 07 Apr 2011 08:17:54 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 08:17:54 -0700 (PDT) In-Reply-To: References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> Date: Thu, 7 Apr 2011 11:17:54 -0400 Message-ID: From: David Endicott To: John Tamplin Content-Type: multipart/alternative; boundary=0016e6ddfee41018e204a0559d24 Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 15:16:11 -0000 --0016e6ddfee41018e204a0559d24 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 7, 2011 at 10:45 AM, John Tamplin wrote: > On Thu, Apr 7, 2011 at 9:56 AM, David Endicott wrote: > >> Javascript strings can hold any byte values, yes? We could have >> delivered the WS frame payload as a JS string and be done with it. It >> would be up to the application to know if that's UTF-8 or ASCII or raw >> binary or whatever. >> > > No, Javascript strings are sequences of UTF16 characters. Even subject to > that restriction, several browsers munge the data you give it if it includes > combining marks or unpaired surrogates, so you can't just pass arbitrary > data in a JS string and expect it to be unmodified. > That's what I thought. I had noticed that any pseudo-binary that I had turned into a JS string was making it thru ok. It's very likely I just hadn't generated any combination that triggered munging. Nonetheless, stuffing arbitrary binary into a UTF-16, and expecting the other side to properly decode it is a Bad Idea. What the Text/Binary frames lack in conceptual purity are *more* than made up for in real-world practicality. --0016e6ddfee41018e204a0559d24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 7, 2011 at 10:45 AM, John Ta= mplin <jat@google.co= m> wrote:
On Thu, Apr 7, 2011 at 9:56 AM= , David Endicott <dendicott@gmail.com> wrote:
Javascript strings can hold any byte values= , yes? =A0 =A0We could have delivered the WS frame payload as a JS string a= nd be done with it. =A0 It would be up to the application to know if that&#= 39;s UTF-8 or ASCII or raw binary or whatever.

No, Javascrip= t strings are sequences of UTF16 characters. =A0Even subject to that restri= ction, several browsers munge the data you give it if it includes combining= marks or unpaired surrogates, so you can't just pass arbitrary data in= a JS string and expect it to be unmodified.

That's what I thought. =A0 =A0I = had noticed that any pseudo-binary that I had turned into a JS string was m= aking it thru ok. =A0 =A0It's very likely I just hadn't generated a= ny combination that triggered munging. =A0Nonetheless, stuffing arbitrary b= inary into a UTF-16, and expecting the other side to properly decode it is = a Bad Idea. =A0 =A0

What the Text/Binary frames lack in conceptual purity a= re *more* than made up for in real-world practicality.

=

--0016e6ddfee41018e204a0559d24-- From theturtle32@gmail.com Thu Apr 7 10:02:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D256128C16C for ; Thu, 7 Apr 2011 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYG4CHByzfiR for ; Thu, 7 Apr 2011 10:02:44 -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 984E23A67CF for ; Thu, 7 Apr 2011 10:02:44 -0700 (PDT) Received: by pzk30 with SMTP id 30so1168983pzk.31 for ; Thu, 07 Apr 2011 10:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+mNewtgXHQPsMVgmJsUGhe12R0elURUyXPo1wYq53xs=; b=Bdbd/Yuu/HCXhvYK2ayfbM8YeTq78a7n3ssUrJoXZmXGM3CXd12KiPjc0zvuEZOfnK YzG4rhjedsq/Cysqoys15+Ikk60q1gYF17Fc+eGB7Kp0po43LLWqtJ5oLdckhakaiFly OrnlUhRPl+yS0zgClSdVeH+XQcz2W6LTkeNNw= 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=mozKICU7YNm07R4Tud7da75uIWZu6lEXMDB8ygl5DbnSw6H94D9s85uGzz/uqpViCu jLS5AqsQMJxAe0DXMopfusLLk7OUlEH7w1Nk1AGRVnNEoskJjTTreX2R59yWhyoiEqI3 7/tgvFCYzefZR55awnt4x55f2teTPZle1K4+s= MIME-Version: 1.0 Received: by 10.142.171.4 with SMTP id t4mr241421wfe.434.1302195868935; Thu, 07 Apr 2011 10:04:28 -0700 (PDT) Received: by 10.68.44.67 with HTTP; Thu, 7 Apr 2011 10:04:28 -0700 (PDT) In-Reply-To: References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> Date: Thu, 7 Apr 2011 10:04:28 -0700 Message-ID: From: Brian To: David Endicott Content-Type: multipart/alternative; boundary=000e0cd50ab432293704a0571aee Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 17:02:46 -0000 --000e0cd50ab432293704a0571aee Content-Type: text/plain; charset=ISO-8859-1 While manipulating binary data in JavaScript is inconvenient, it is not true to say that it is not possible to represent binary data cleanly as a string. See https://developer.mozilla.org/En/Using_XMLHttpRequest#Handling_binary_datafor example. I've successfully used that interface to write a full ABC (ActionScript 3 Byte Code) disassembler in JavaScript. I can tell you that it does work. var aByte = inputString.charCodeAt(2) & 0xFF; It may be reasonable to hold out for a better native mechanism for handling binary data to be added to JavaScript, but I'm not yet aware of any such thing in the ES5 spec (if there is something on the horizon please let me know!) In any case, JavaScript *can* correctly and reliably interpret binary messages as a string -- no question about it. Brian On Apr 7, 2011, at 8:17 AM, David Endicott wrote: On Thu, Apr 7, 2011 at 10:45 AM, John Tamplin < jat@google.com> wrote: > On Thu, Apr 7, 2011 at 9:56 AM, David Endicott < > dendicott@gmail.com> wrote: > >> Javascript strings can hold any byte values, yes? We could have >> delivered the WS frame payload as a JS string and be done with it. It >> would be up to the application to know if that's UTF-8 or ASCII or raw >> binary or whatever. >> > > No, Javascript strings are sequences of UTF16 characters. Even subject to > that restriction, several browsers munge the data you give it if it includes > combining marks or unpaired surrogates, so you can't just pass arbitrary > data in a JS string and expect it to be unmodified. > That's what I thought. I had noticed that any pseudo-binary that I had turned into a JS string was making it thru ok. It's very likely I just hadn't generated any combination that triggered munging. Nonetheless, stuffing arbitrary binary into a UTF-16, and expecting the other side to properly decode it is a Bad Idea. What the Text/Binary frames lack in conceptual purity are *more* than made up for in real-world practicality. _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi --000e0cd50ab432293704a0571aee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
While manipulating binary data in JavaScript = is inconvenient, it is not true to say that it is not possible to represent= binary data cleanly as a string. =A0See=A0https://developer.mo= zilla.org/En/Using_XMLHttpRequest#Handling_binary_data for example. =A0= I've successfully used that interface to write a full ABC (ActionScript= 3 Byte Code) disassembler in JavaScript. =A0I can tell you that it does wo= rk.

var aByte =3D inputString.charCodeAt(2) & 0xFF;

It may be reasonable to hold out for a better native = mechanism for handling binary data to be added to JavaScript, but I'm n= ot yet aware of any such thing in the ES5 spec (if there is something on th= e horizon please let me know!) =A0In any case,=A0JavaScript *can* correctly= and reliably interpret binary messages as a string -- no question about it= .

Brian

=

On Apr 7, 2011, at 8:17 AM, David Endicott &l= t;dendicott@gmail.= com> wrote:



On Thu, Apr 7, 2011 at 10:45 AM, John Tamplin <jat@google.com> wrote:<= br>
On Thu, Apr 7, 2011 at 9:56 AM, David Endic= ott <dendic= ott@gmail.com> wrote:
Javascript strings can hold any byte values= , yes? =A0 =A0We could have delivered the WS frame payload as a JS string a= nd be done with it. =A0 It would be up to the application to know if that&#= 39;s UTF-8 or ASCII or raw binary or whatever.

No, Javascrip= t strings are sequences of UTF16 characters. =A0Even subject to that restri= ction, several browsers munge the data you give it if it includes combining= marks or unpaired surrogates, so you can't just pass arbitrary data in= a JS string and expect it to be unmodified.

That's what I thought. =A0 =A0I = had noticed that any pseudo-binary that I had turned into a JS string was m= aking it thru ok. =A0 =A0It's very likely I just hadn't generated a= ny combination that triggered munging. =A0Nonetheless, stuffing arbitrary b= inary into a UTF-16, and expecting the other side to properly decode it is = a Bad Idea. =A0 =A0

What the Text/Binary frames lack in conceptual purity a= re *more* than made up for in real-world practicality.

=

___________________= ____________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi
--000e0cd50ab432293704a0571aee-- From jat@google.com Thu Apr 7 10:18:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245223A6954 for ; Thu, 7 Apr 2011 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.852 X-Spam-Level: X-Spam-Status: No, score=-105.852 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Un3wDCsYrZGO for ; Thu, 7 Apr 2011 10:18:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id DB77E3A694F for ; Thu, 7 Apr 2011 10:18:55 -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 p37HKde4002864 for ; Thu, 7 Apr 2011 10:20:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302196839; bh=XBwlDGe1qwMhx9u935iedvt2QBs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BJ6zTAvteH9apXFYDxvgljT7Eln0r5xsvs0kt75C1ek/k9b7BFP5xmaCAIkBjleTe G6OpWULKxoU7f5fpQTxqw== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by kpbe17.cbf.corp.google.com with ESMTP id p37HKbZg022166 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Apr 2011 10:20:37 -0700 Received: by gxk2 with SMTP id 2so1659459gxk.22 for ; Thu, 07 Apr 2011 10:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FyC2u6CO9siEgOYiwgBZALTYsmZfCgKGLP8ZBpAbKw8=; b=MTAJYkoO5fPpZ7wrs5qCowWzsi/k06GdFcrYFiEByTfJfQ0KssHXcFRH/nCLGAEkrI x4c8Giq9tZA3LmyXFzgg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iKCMVSKlFzZqPC0uuSHy9xRpjRGUHsDPxtew5ADXGNBGoRxpFoze20KCAzsj9RHr+4 C89DpwN8dqMnbKZzsIhA== Received: by 10.150.69.30 with SMTP id r30mr976806yba.124.1302196837119; Thu, 07 Apr 2011 10:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.200.16 with HTTP; Thu, 7 Apr 2011 10:20:16 -0700 (PDT) In-Reply-To: References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> From: John Tamplin Date: Thu, 7 Apr 2011 13:20:17 -0400 Message-ID: To: Brian Content-Type: multipart/alternative; boundary=000e0cd59196e779bb04a05753b5 X-System-Of-Record: true Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 17:18:57 -0000 --000e0cd59196e779bb04a05753b5 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2011 at 1:04 PM, Brian wrote: > While manipulating binary data in JavaScript is inconvenient, it is not > true to say that it is not possible to represent binary data cleanly as a > string. See > https://developer.mozilla.org/En/Using_XMLHttpRequest#Handling_binary_datafor example. I've successfully used that interface to write a full ABC > (ActionScript 3 Byte Code) disassembler in JavaScript. I can tell you that > it does work. > > var aByte = inputString.charCodeAt(2) & 0xFF; > Sure, but that is encoding bytes 0x00-0xFF as characters 0-255, which means the upper half of these bytes actually takes two bytes on the wire using UTF8. GWT quake does the same thing to send Quake's binary message formats (involving lots of floating point numbers) via WebSocket using the text API. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd59196e779bb04a05753b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2011 at 1:04 PM, Brian <theturtle32@gmail.com= > wrote:
While manipulating binary data in JavaScript = is inconvenient, it is not true to say that it is not possible to represent= binary data cleanly as a string. =C2=A0See=C2=A0https://developer.mozilla.org/En/Using_XMLHttpRequest#Handling_binary_d= ata for example. =C2=A0I've successfully used that interface to wri= te a full ABC (ActionScript 3 Byte Code) disassembler in JavaScript. =C2=A0= I can tell you that it does work.

var aByte =3D inputString.charCodeAt(2) & 0xFF;

Sure, but that is encoding bytes 0= x00-0xFF as characters 0-255, which means the upper half of these bytes act= ually takes two bytes on the wire using UTF8. =C2=A0GWT quake does the same= thing to send Quake's binary message formats (involving lots of floati= ng point numbers) via WebSocket using the text API.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd59196e779bb04a05753b5-- From zt.tmzt@gmail.com Thu Apr 7 10:21:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686633A69CC for ; Thu, 7 Apr 2011 10:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.241 X-Spam-Level: X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FRT_ADULT2=1.474, 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 6UQI2Wr+iLvx for ; Thu, 7 Apr 2011 10:21:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 860303A694F for ; Thu, 7 Apr 2011 10:21:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so2557463vxg.31 for ; Thu, 07 Apr 2011 10:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XeLM1bFqDj7Kd9KsiaDdcXn1wwz21EvQzQ1AvQh8Uak=; b=bYLc/I96LBH3rHjSCfaJeGsI/GBZnIu5ShnJT+rRHKQcxc0HjDGrJLDRHBvsmT8M6T 1DJHT8EBj+kLT6mZOhFl2bKzwaqgarRKhhNdDixa2DhYCp6XhBC4+yBSeHrg4NpKnPmT oqVT+6qetOU7XlbSqT7+3NczXiCoHISMDngXM= 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=R0DcbNmp9XQQFdVr6x0zSZMUhMhyxM260XPz+iEQ4Gui9oxzZLgxYfpqpahxbufDJv APo+r/Tuplym12uq8lXOPniiayWilHp92UQNw5nkwTxWr7+Z3K1ellQODJiFX67WcUsc 8NlOj/vTf+kVZ2km7ZWUd/fNQXgvEEpj+OPgE= MIME-Version: 1.0 Received: by 10.220.125.74 with SMTP id x10mr343595vcr.61.1302196985879; Thu, 07 Apr 2011 10:23:05 -0700 (PDT) Received: by 10.220.48.79 with HTTP; Thu, 7 Apr 2011 10:23:04 -0700 (PDT) Received: by 10.220.48.79 with HTTP; Thu, 7 Apr 2011 10:23:04 -0700 (PDT) In-Reply-To: References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> Date: Thu, 7 Apr 2011 13:23:04 -0400 Message-ID: From: "zt.tmzt@gmail.com" To: Brian Content-Type: multipart/alternative; boundary=001636d33ac8c55cb504a0575cf2 Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 17:21:23 -0000 --001636d33ac8c55cb504a0575cf2 Content-Type: text/plain; charset=ISO-8859-1 There are mechanisms in modern browsers or coming soon for binary data in javascript, such as TypedArray (from WebGL). The question I think is not if binary support is coming, but in what form. Quoted: Compatibility Typed arrays are available in WebKit as well. Chrome 7 includes support for ArrayBuffer,Float32Array,Int16Array, andUint8Array. Chrome 9 adds support forDataView objects. https://developer.mozilla.org/en/JavaScript_typed_arrays Uses Uint8Array -- Timothy Meade real -time web developer On Apr 7, 2011 1:04 PM, "Brian" wrote: > While manipulating binary data in JavaScript is inconvenient, it is not true > to say that it is not possible to represent binary data cleanly as a string. > See > https://developer.mozilla.org/En/Using_XMLHttpRequest#Handling_binary_datafor > example. I've successfully used that interface to write a full ABC > (ActionScript 3 Byte Code) disassembler in JavaScript. I can tell you that > it does work. > > var aByte = inputString.charCodeAt(2) & 0xFF; > > It may be reasonable to hold out for a better native mechanism for handling > binary data to be added to JavaScript, but I'm not yet aware of any such > thing in the ES5 spec (if there is something on the horizon please let me > know!) In any case, JavaScript *can* correctly and reliably interpret > binary messages as a string -- no question about it. > > Brian > > > > On Apr 7, 2011, at 8:17 AM, David Endicott wrote: > > > > On Thu, Apr 7, 2011 at 10:45 AM, John Tamplin < > jat@google.com> wrote: > >> On Thu, Apr 7, 2011 at 9:56 AM, David Endicott < >> dendicott@gmail.com> wrote: >> >>> Javascript strings can hold any byte values, yes? We could have >>> delivered the WS frame payload as a JS string and be done with it. It >>> would be up to the application to know if that's UTF-8 or ASCII or raw >>> binary or whatever. >>> >> >> No, Javascript strings are sequences of UTF16 characters. Even subject to >> that restriction, several browsers munge the data you give it if it includes >> combining marks or unpaired surrogates, so you can't just pass arbitrary >> data in a JS string and expect it to be unmodified. >> > > That's what I thought. I had noticed that any pseudo-binary that I had > turned into a JS string was making it thru ok. It's very likely I just > hadn't generated any combination that triggered munging. Nonetheless, > stuffing arbitrary binary into a UTF-16, and expecting the other side to > properly decode it is a Bad Idea. > > What the Text/Binary frames lack in conceptual purity are *more* than made > up for in real-world practicality. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --001636d33ac8c55cb504a0575cf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


There are mechanisms in modern browsers or coming soon for binary data in j= avascript, such as TypedArray (from WebGL). The question I think is not if = binary support is coming, but in what form.

Quoted:
Compatibility Typed arrays are available in WebKit as well. Chrome 7 includ= es support for ArrayBuffer,Float32Array,Int16Array, andUint8Array. Chrome 9= adds support forDataView objects.

htt= ps://developer.mozilla.org/en/JavaScript_typed_arrays
Uses Uint8Array

--
Timothy Meade
real -time web developer

On Apr 7, 2011 1:04 PM, "Brian" <theturtle32@gmail.com> wrote:=
> While manipulating binary data in JavaScript = is inconvenient, it is not true
> to say that it is not possible to represent binary data cleanly as a s= tring.
> See
> https://developer.mozilla.org/En= /Using_XMLHttpRequest#Handling_binary_datafor
> example. I've successfully used that interface to write a full AB= C
> (ActionScript 3 Byte Code) disassembler in JavaScript. I can tel= l you that
> it does work.
>
> var aByte =3D inputString= .charCodeAt(2) & 0xFF;
>
> It may be reasonable to hold out for a better native mechanis= m for handling
> binary data to be added to JavaScript, but I'm n= ot yet aware of any such
> thing in the ES5 spec (if there is somethi= ng on the horizon please let me
> know!) In any case, JavaScript *can* correctly and reliably interpret=
> binary messages as a string -- no question about it.
>
&= gt; Brian
>
>
>
> On Apr 7, 2011, at 8:17 AM, Da= vid Endicott <dendicott@gmail.com= > wrote:
>
>
>
> On Thu, Apr 7, 2011 at 10:45 AM, John Tampl= in < <jat@google.com>
>= ; jat@google.com> wrote:
> <= br> >> On Thu, Apr 7, 2011 at 9:56 AM, David Endicott < <dendicott@gmail.com>
>> dendicott@gmail.com> wrote:
>= >
>>> Javascript strings can hold any byte values, yes? We could = have
>>> delivered the WS frame payload as a JS string and be d= one with it. It
>>> would be up to the application to know if= that's UTF-8 or ASCII or raw
>>> binary or whatever.
>>>
>>
>> No= , Javascript strings are sequences of UTF16 characters. Even subject to>> that restriction, several browsers munge the data you give it if = it includes
>> combining marks or unpaired surrogates, so you can't just pass= arbitrary
>> data in a JS string and expect it to be unmodified.<= br>>>
>
> That's what I thought. I had noticed th= at any pseudo-binary that I had
> turned into a JS string was making it thru ok. It's very likely= I just
> hadn't generated any combination that triggered munging= . Nonetheless,
> stuffing arbitrary binary into a UTF-16, and expect= ing the other side to
> properly decode it is a Bad Idea.
>
> What the Text/Binar= y frames lack in conceptual purity are *more* than made
> up for in r= eal-world practicality.
>
>
> _________________________= ______________________
> hybi mailing list
> hybi@ietf.o= rg
> https= ://www.ietf.org/mailman/listinfo/hybi
--001636d33ac8c55cb504a0575cf2-- From henrikn@microsoft.com Thu Apr 7 10:57:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA743A695D for ; Thu, 7 Apr 2011 10:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMMC-5fV8LSz for ; Thu, 7 Apr 2011 10:57:44 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5004428C0E5 for ; Thu, 7 Apr 2011 10:57:44 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Apr 2011 10:59:28 -0700 Received: from TK5EX14MBXC213.redmond.corp.microsoft.com ([169.254.2.245]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Thu, 7 Apr 2011 10:59:29 -0700 From: Henrik Frystyk Nielsen To: "hybi@ietf.org" Thread-Topic: Indicating acceptable protocols in a 426 Upgrade Required Status response Thread-Index: Acv1THojZe1Zjr5kQI+H72V16Zh+AQ== Date: Thu, 7 Apr 2011 17:59:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC0AEBTK5EX14MBXC213r_" MIME-Version: 1.0 Subject: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response 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, 07 Apr 2011 17:57:48 -0000 --_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC0AEBTK5EX14MBXC213r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The latest HTTP/1.1-bis draft [1] includes a definition of the "426 Upgrade= Required" status code which was adopted from RFC 2817. This allows a serve= r to send back a response indicating that an upgrade protocol such as WebSo= cket is required: HTTP/1.1 426 Upgrade Required Upgrade: websocket Connection: Upgrade Just like a "101 Switching Protocols" should indicate which sub-protocol (i= f any) was accepted ('chat' in this example): HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=3D Sec-WebSocket-Protocol: chat I propose that a "426 Upgrade Required" response MUST indicate which protoc= ols (if any) are acceptable: HTTP/1.1 426 Upgrade Required Upgrade: websocket Connection: Upgrade Sec-WebSocket-Protocol: chat This mirrors similar patterns already used in HTTP including a "405 Method = Not Allowed" response where the server (from [2]): 8.4.6. 405 Method Not Allowed The method specified in the Request-Line is not allowed for the target resource. The response MUST include an Allow header field containing a list of valid methods for the requested resource. The reason it is a must is that otherwise there is no way for the client to= know what to do because the exchange is not self-described. I think it is fine to reuse the Sec-WebSocket-Protocol header field just li= ke what is done for the 101 response. Thanks, Henrik [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8= .4.19 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8= .4.6 --_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC0AEBTK5EX14MBXC213r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The latest HTTP/1.1-bis draft [1] includes a defi= nition of the “426 Upgrade Required” status code which was adop= ted from RFC 2817. This allows a server to send back a response indicating = that an upgrade protocol such as WebSocket is required:

 

     HTTP/1.1 426 Upgrade Req= uired

     Upgrade: websocket<= /o:p>

     Connection: Upgrade=

 

Just like a “101 Switching Protocols”= should indicate which sub-protocol (if any) was accepted (‘chat̵= 7; in this example):

 

     HTTP/1.1 101 Switching P= rotocols

     Upgrade: websocket<= /o:p>

     Connection: Upgrade=

     Sec-WebSocket-Accept: s3= pPLMBiTxaQ9kYGzzhZRbK+xOo=3D

     Sec-WebSocket-Protocol: = chat

 

I propose that a “426 Upgrade Required̶= 1; response MUST indicate which protocols (if any) are acceptable:

 

     HTTP/1.1 426 Upgrade Req= uired

     Upgrade: websocket<= /o:p>

     Connection: Upgrade=

     Sec-WebSocket-Protocol: = chat

 

This mirrors similar patterns already used in HTT= P including a “405 Method Not Allowed” response where the serve= r (from [2]):

 

   8.4.6.  405 Method Not Allowed<= o:p>

 

   The method specified in the Request-= Line is not allowed for the

   target resource.  The response = MUST include an Allow header field

   containing a list of valid methods f= or the requested resource.

 

The reason it is a must is that otherwise there i= s no way for the client to know what to do because the exchange is not self= -described.

 

I think it is fine to reuse the Sec-WebSocket-Pro= tocol header field just like what is done for the 101 response.<= /p>

 

Thanks,

 

Henrik

 

[1] http://tools.ietf.org/html/draft-ietf-httpbis= -p2-semantics-13#section-8.4.19

[2] http://tools.ietf.org/html/draft-ietf-httpbis= -p2-semantics-13#section-8.4.6

 

 

--_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC0AEBTK5EX14MBXC213r_-- From theturtle32@gmail.com Thu Apr 7 11:43:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7026D3A696A for ; Thu, 7 Apr 2011 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPxOxKauRqx0 for ; Thu, 7 Apr 2011 11:43:44 -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 4E4663A67B0 for ; Thu, 7 Apr 2011 11:43:44 -0700 (PDT) Received: by iwn39 with SMTP id 39so3408297iwn.31 for ; Thu, 07 Apr 2011 11:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=436d9S5pefCB6qKXvce7/aE3J92SBuBcB/2tmfSe5OA=; b=cKybvDTkSqOG+gzN+sqf9MLqYPJBOjLaDQ8d0HwhFx4RYBDIl+KHx7hmIQ++wqn0e2 JODWxI4aNP3XfQzaekF0LMnlMMGzFl+P+/2w/HUZOx7phoHrgnaHxJ45FrjUN3Vca7gw XRusVNRZfH+woWpQxonnU7JF4cB3qQs8SLdIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=RqUKuLr3stjGtweLhGeb3tEEmxB1voFwrME16PR/AnfiBRyHN/DwgePQCAlRWDs8mQ 1LpYcPegJGwhb6k/CiFblfTCJif8sXIaRY/ArMYos9aapXE3ACDKu3bYReB+86toH6ZN /xAj31EySbB4dxmjBwbR6t7hyuTPPjAsbs0Ic= Received: by 10.42.222.71 with SMTP id if7mr1954953icb.271.1302201928280; Thu, 07 Apr 2011 11:45:28 -0700 (PDT) Received: from [10.138.126.66] ([166.205.136.186]) by mx.google.com with ESMTPS id c1sm1305967ibe.34.2011.04.07.11.45.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 11:45:24 -0700 (PDT) References: <000601cbf022$4c420320$e4c60960$@net> <000f01cbf067$e9fab310$bdf01930$@net> <001601cbf06d$d3b5f550$7b21dff0$@net> <20110407010303.GP26912@shareable.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3--375308634 Message-Id: <602E2C27-227F-4221-B58C-202304FF5B4E@gmail.com> X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Thu, 7 Apr 2011 11:45:16 -0700 To: John Tamplin Cc: hybi Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 18:43:45 -0000 --Apple-Mail-3--375308634 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii With UTF-8 it only takes two bytes for values over 127. And it doesn't take= two bytes on the wire at all if you use a binary message frame type, which I= thought was what we were talking about. The browser would be responsible f= or converting it to an appropriately encoded string for binary processing. Brian Sent from my iPhone On Apr 7, 2011, at 10:20 AM, John Tamplin wrote: > On Thu, Apr 7, 2011 at 1:04 PM, Brian wrote: > While manipulating binary data in JavaScript is inconvenient, it is not tr= ue to say that it is not possible to represent binary data cleanly as a stri= ng. See https://developer.mozilla.org/En/Using_XMLHttpRequest#Handling_bina= ry_data for example. I've successfully used that interface to write a full A= BC (ActionScript 3 Byte Code) disassembler in JavaScript. I can tell you th= at it does work. >=20 > var aByte =3D inputString.charCodeAt(2) & 0xFF; >=20 > Sure, but that is encoding bytes 0x00-0xFF as characters 0-255, which mean= s the upper half of these bytes actually takes two bytes on the wire using U= TF8. GWT quake does the same thing to send Quake's binary message formats (= involving lots of floating point numbers) via WebSocket using the text API. >=20 > --=20 > John A. Tamplin > Software Engineer (GWT), Google --Apple-Mail-3--375308634 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
With UTF-8 it only takes two bytes for values over 127.  And it doesn't take two bytes on the wire at all if you use a binary message frame type, which I thought was what we were talking about.  The browser would be responsible for converting it to an appropriately encoded string for binary processing.

Brian

Sent from my iPhone

On Apr 7, 2011, at 10:20 AM, John Tamplin <jat@google.com> wrote:

On Thu, Apr 7, 2011 at 1:04 PM, Brian <theturtle32@gmail.com> wrote:
While manipulating binary data in JavaScript is inconvenient, it is not true to say that it is not possible to represent binary data cleanly as a string.  See https://developer.mozilla.org/En/Using_XMLHttpRequest#Handling_binary_data for example.  I've successfully used that interface to write a full ABC (ActionScript 3 Byte Code) disassembler in JavaScript.  I can tell you that it does work.

var aByte = inputString.charCodeAt(2) & 0xFF;

Sure, but that is encoding bytes 0x00-0xFF as characters 0-255, which means the upper half of these bytes actually takes two bytes on the wire using UTF8.  GWT quake does the same thing to send Quake's binary message formats (involving lots of floating point numbers) via WebSocket using the text API.

--
John A. Tamplin
Software Engineer (GWT), Google
--Apple-Mail-3--375308634-- From buskanaka@gmail.com Thu Apr 7 13:04:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72DBB28C0DB for ; Thu, 7 Apr 2011 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqkrVAnbZIhB for ; Thu, 7 Apr 2011 13:04:00 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B65533A6980 for ; Thu, 7 Apr 2011 13:03:59 -0700 (PDT) Received: by ewy19 with SMTP id 19so1049974ewy.31 for ; Thu, 07 Apr 2011 13:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=HvEyyb6RAPnYEA1hsGJ3QQ0L18qDBjR8s/MuBEjcHjQ=; b=RIm8iRfZUC0bdk1b7xdJyL1EuizGgAduBEtucqeT58+2XQOu4CnwfNOnhm4PNivibS 5wU0bRYkyXeAQVk4cSoyUFIEaA2FbRCi+ASLKR5hWQ8ZVHP1tCUgs1T8So7tbGGG/sUd eYmb6m0GOpDd281VZSmdBtXuYJs6zE5WeBrR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=H0ic8mT8BFcRm2yH2d6BZXjQng92RIDXRf3k4MEdrndBpHkjBaUnOqul0YhZsFFFQa A3eSOvNzf5zMx7OdSuGA7KLSTka3n+7iIhv6VagFMELVjs3vCnfbR4XJGyyJo7p7Sjv8 hHxWf0jeN76hCkA6MmMRGe4zXjfsoo1u8zSQw= Received: by 10.14.124.139 with SMTP id x11mr606988eeh.219.1302206742260; Thu, 07 Apr 2011 13:05:42 -0700 (PDT) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.47.8 with HTTP; Thu, 7 Apr 2011 13:05:22 -0700 (PDT) From: Joel Martin Date: Thu, 7 Apr 2011 15:05:22 -0500 X-Google-Sender-Auth: pO0O8O5qmo9vK5EmoBzj-cJ3WZ0 Message-ID: To: hybi Content-Type: multipart/alternative; boundary=e0cb4e6ffcb54bee4304a059a2b8 Subject: [hybi] API for binary data (was: HTTP Upgrade - A Modest Proposal) 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, 07 Apr 2011 20:04:01 -0000 --e0cb4e6ffcb54bee4304a059a2b8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 7, 2011 at 1:45 PM, Brian McKelvey wrote: > With UTF-8 it only takes two bytes for values over 127. And it doesn't > take two bytes on the wire at all if you use a binary message frame type, > which I thought was what we were talking about. The browser would be > responsible for converting it to an appropriately encoded string for binary > processing. > Is anybody here involved with the API side (standard or browser implementation) that can comment on what the API side of things will look like for sending binary data? Will it be automatic based on data-type (i.e. ArrayBuffer vs string) or some sort of change to the API? If it is automatic, how will the program know before sending if the API is capable of sending binary data? A link to discussion on a different list works for me. And just for reference for those considering binary data before the API officially supports it, I recommend base64 encode/decode rather than UTF-8 for a few reasons: - Using base64 is more space efficient than UTF-8 conversion of byte data if it evenly spread across 0-255 (133% for base64 vs 150% for UTF-8). - The meaning of 0 (zero) is somewhat uncertain in UTF-8 implementations. Some implementations treat 0 in UTF-8 as string termination. Flash is one example, which is problematic if you want to use the Flash WebSockets fallback/polyfill web-socket-js. I consider this brokenness in Flash but it does make transferring binary data via UTF-8 difficult. The combination of length and binary data type in the new protocol will address this (because then in Flash binary data can just be treated as binary data and not decoded as UTF-8). However, it's not useful until the API supports binary data. - If you are using a python WebSockets server, encoding to/from base64 is much easier (and I faster too IIRC) then the encode/decode to/from UTF-8. And if talking to raw TCP servers via the browser is your thing, then check out https://github.com/kanaka/websockify which is a python WebSockets to raw TCP socket proxy (or LD_PRELOAD wraps an existing server) plus a Javascript lib that talks to it. It only speaks v76 currenly but I'm planning on updating it to support 06 soon (or whatever is current when I get around to it). Regards, Joel Martin (kanaka) --e0cb4e6ffcb54bee4304a059a2b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2011 at 1:45 PM, Brian McKelvey <= span dir=3D"ltr"><theturtle32@g= mail.com> wrote:
With UTF-8 it only takes two bytes for values= over 127. =A0And it doesn't take two bytes on the wire at all if you u= se a binary message frame type, which I thought was what we were talking ab= out. =A0The browser would be responsible for converting it to an appropriat= ely encoded string for binary processing.

Is anybody here involved with the AP= I side (standard or browser implementation) that can comment on what the AP= I side of things will look like for sending binary data? Will it be automat= ic based on data-type (i.e. ArrayBuffer vs string) or some sort of change t= o the API? If it is automatic, how will the program know before sending if = the API is capable of sending binary data? A link to discussion on a differ= ent list works for me.

And just for reference for those considering binary dat= a before the API officially supports it, I recommend base64 encode/decode r= ather than UTF-8 for a few reasons:

- Using base64= is more space efficient than UTF-8 conversion of byte data if it evenly sp= read across 0-255 (133% for base64 vs 150% for UTF-8).

- The meaning of 0 (zero) is somewhat uncertain in UTF-= 8 implementations. Some implementations treat 0 in UTF-8 as string terminat= ion. Flash is one example, which is problematic if you want to use the Flas= h WebSockets fallback/polyfill web-socket-js. I consider this brokenness in= Flash but it does make transferring binary data via UTF-8 difficult. The c= ombination of length and binary data type in the new protocol will address = this (because then in Flash binary data can just be treated as binary data = and not decoded as UTF-8). However, it's not useful until the API suppo= rts binary data.

- If you are using a python WebSockets server, encoding= to/from base64 is much easier (and I faster too IIRC) then the encode/deco= de to/from UTF-8.

And if talking to raw TCP server= s via the browser is your thing, then check out https://github.com/kanaka/websockify which is a p= ython WebSockets to raw TCP socket proxy (or LD_PRELOAD wraps an existing s= erver) plus a=A0Javascript lib that talks to it.=A0It only speaks v76 curre= nly but I'm planning on updating it to support 06 soon (or whatever is = current when I get around to it).

Regards,

Joel Martin (kanaka)
--e0cb4e6ffcb54bee4304a059a2b8-- From pmcmanus@mozilla.com Thu Apr 7 13:13:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537DC28C13C for ; Thu, 7 Apr 2011 13:13:32 -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 1uTWkn3iqi-B for ; Thu, 7 Apr 2011 13:13:30 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 949333A690A for ; Thu, 7 Apr 2011 13:13:30 -0700 (PDT) Received: from host-2-207.mv.mozilla.com (corp-240.mv.mozilla.com [63.245.220.240]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 325E8102A9 for ; Thu, 7 Apr 2011 16:15:15 -0400 (EDT) Message-ID: <4D9E1B52.4030700@mozilla.com> Date: Thu, 07 Apr 2011 13:15:14 -0700 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] API for binary data (was: HTTP Upgrade - A Modest Proposal) 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, 07 Apr 2011 20:13:32 -0000 On 4/7/11 1:05 PM, Joel Martin wrote: > > Is anybody here involved with the API side (standard or browser > implementation) that can comment on what the API side of things will > look like for sending binary data? Will it be automatic based on > data-type (i.e. ArrayBuffer vs string) or some sort of change to the > API? If it is automatic, how will the program know before sending if > the API is capable of sending binary data? A link to discussion on a > different list works for me. > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 From ibc@aliax.net Thu Apr 7 13:58:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B114A3A6982 for ; Thu, 7 Apr 2011 13:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyEUi09sCNsX for ; Thu, 7 Apr 2011 13:58:00 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 22BBB3A6974 for ; Thu, 7 Apr 2011 13:57:59 -0700 (PDT) Received: by qyk29 with SMTP id 29so3319803qyk.10 for ; Thu, 07 Apr 2011 13:59:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.40.198 with SMTP id l6mr1152954qae.47.1302209984437; Thu, 07 Apr 2011 13:59:44 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Thu, 7 Apr 2011 13:59:44 -0700 (PDT) In-Reply-To: References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> Date: Thu, 7 Apr 2011 22:59:44 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: David Endicott Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 20:58:00 -0000 2011/4/7 David Endicott : > Scripts should only be trusted to talk with the servers they came from. Please not, that assumes that the HTTP server must also speak websocket (and the subprotocol over it). Let's design scalable systems please. --=20 I=C3=B1aki Baz Castillo From sdw@lig.net Thu Apr 7 14:22:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB6428C0D8 for ; Thu, 7 Apr 2011 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 a-kfbCB4IvwR for ; Thu, 7 Apr 2011 14:22:56 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by core3.amsl.com (Postfix) with ESMTP id 703073A67CC for ; Thu, 7 Apr 2011 14:22:54 -0700 (PDT) Received: from mq.lig.net (adsl-71-141-114-61.dsl.snfc21.pacbell.net [71.141.114.61]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 044D2AB5E31 for ; Thu, 7 Apr 2011 14:34:40 -0700 (PDT) Message-ID: <4D9E2B96.1030001@lig.net> Date: Thu, 07 Apr 2011 14:24:38 -0700 From: Stephen Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060806080105000808090504" Subject: Re: [hybi] API for binary data (was: HTTP Upgrade - A Modest Proposal) 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, 07 Apr 2011 21:22:59 -0000 This is a multi-part message in MIME format. --------------060806080105000808090504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/7/11 1:05 PM, Joel Martin wrote: > On Thu, Apr 7, 2011 at 1:45 PM, Brian McKelvey > wrote: > > With UTF-8 it only takes two bytes for values over 127. And it doesn't take two bytes on the wire at all if you use a > binary message frame type, which I thought was what we were talking about. The browser would be responsible for > converting it to an appropriately encoded string for binary processing. > > > Is anybody here involved with the API side (standard or browser implementation) that can comment on what the API side of > things will look like for sending binary data? Will it be automatic based on data-type (i.e. ArrayBuffer vs string) or some > sort of change to the API? If it is automatic, how will the program know before sending if the API is capable of sending > binary data? A link to discussion on a different list works for me. Websockets should have payloads that are binary only, just like TCP. If the application wants to consider the data to be a particular encoding, mime-type, etc., that is fine but it should be layered on a binary transport. Both Post and Get support binary bodies already. > > And just for reference for those considering binary data before the API officially supports it, I recommend base64 > encode/decode rather than UTF-8 for a few reasons: > > - Using base64 is more space efficient than UTF-8 conversion of byte data if it evenly spread across 0-255 (133% for base64 vs > 150% for UTF-8). > > - The meaning of 0 (zero) is somewhat uncertain in UTF-8 implementations. Some implementations treat 0 in UTF-8 as string > termination. Flash is one example, which is problematic if you want to use the Flash WebSockets fallback/polyfill > web-socket-js. I consider this brokenness in Flash but it does make transferring binary data via UTF-8 difficult. The > combination of length and binary data type in the new protocol will address this (because then in Flash binary data can just > be treated as binary data and not decoded as UTF-8). However, it's not useful until the API supports binary data. > > - If you are using a python WebSockets server, encoding to/from base64 is much easier (and I faster too IIRC) then the > encode/decode to/from UTF-8. Many environments, including Java, use layers of objects to work with UTF-8. Encoding and decoding UTF-8 can be done in about 10 lines of code. Doing it inline, or at least in a focused, tight loop, should be about as fast as b64. > > And if talking to raw TCP servers via the browser is your thing, then check out https://github.com/kanaka/websockify which is > a python WebSockets to raw TCP socket proxy (or LD_PRELOAD wraps an existing server) plus a Javascript lib that talks to > it. It only speaks v76 currenly but I'm planning on updating it to support 06 soon (or whatever is current when I get around > to it). > > Regards, > > Joel Martin (kanaka) sdw --------------060806080105000808090504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/7/11 1:05 PM, Joel Martin wrote:
On Thu, Apr 7, 2011 at 1:45 PM, Brian McKelvey <theturtle32@gmail.com> wrote:
With UTF-8 it only takes two bytes for values over 127. =C2=A0And it doesn't take two bytes on the wire at all if y= ou use a binary message frame type, which I thought was what we were talking about. =C2=A0The browser would be responsib= le for converting it to an appropriately encoded string for binary processing.

Is anybody here involved with the API side (standard or browser implementation) that can comment on what the API side of things will look like for sending binary data? Will it be automatic based on data-type (i.e. ArrayBuffer vs string) or some sort of change to the API? If it is automatic, how will the program know before sending if the API is capable of sending binary data? A link to discussion on a different list works for me.

Websockets should have payloads that are binary only, just like TCP.=C2=A0 If the application wants to consider the data to be a particular encoding, mime-type, etc., that is fine but it should be layered on a binary transport.=C2=A0 Both Post and Get support binary= bodies already.


And just for reference for those considering binary data before the API officially supports it, I recommend base64 encode/decode rather than UTF-8 for a few reasons:

- Using base64 is more space efficient than UTF-8 conversion of byte data if it evenly spread across 0-255 (133% for base64 vs 150% for UTF-8).

- The meaning of 0 (zero) is somewhat uncertain in UTF-8 implementations. Some implementations treat 0 in UTF-8 as string termination. Flash is one example, which is problematic if you want to use the Flash WebSockets fallback/polyfill web-socket-js. I consider this brokenness in Flash but it does make transferring binary data via UTF-8 difficult. The combination of length and binary data type in the new protocol will address this (because then in Flash binary data can just be treated as binary data and not decoded as UTF-8). However, it's not useful until the API supports binary data.

- If you are using a python WebSockets server, encoding to/from base64 is much easier (and I faster too IIRC) then the encode/decode to/from UTF-8.

Many environments, including Java, use layers of objects to work with UTF-8.=C2=A0 Encoding and decoding UTF-8 can be done in about 10= lines of code.=C2=A0 Doing it inline, or at least in a focused, tight= loop, should be about as fast as b64.


And if talking to raw TCP servers via the browser is your thing, then check out https://github.= com/kanaka/websockify which is a python WebSockets to raw TCP socket proxy (or LD_PRELOAD wraps an existing server) plus a=C2=A0Javascript lib= that talks to it.=C2=A0It only speaks v76 currenly but I'm plan= ning on updating it to support 06 soon (or whatever is current when I get around to it).

Regards,

Joel Martin (kanaka)

sdw

--------------060806080105000808090504-- From dendicott@gmail.com Thu Apr 7 14:56:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9031928C11A for ; Thu, 7 Apr 2011 14:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jc5akvGH3fA for ; Thu, 7 Apr 2011 14:56:27 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7474928C112 for ; Thu, 7 Apr 2011 14:56:27 -0700 (PDT) Received: by wwa36 with SMTP id 36so2516624wwa.13 for ; Thu, 07 Apr 2011 14:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zFld2Scjl96v7pg/WqzwmhVEQA/5h43AsF/IPwgQotk=; b=x1GQJOXhSE0OLgwUhLEk/I+OWfMDstuBI+7b2T1VXMvcvTuGBAy0iKHXbTjvBJNuFW 14mCYleulbcjaJpg1Zqq7DP6HBpM5/yoLETwHfqx72up8jkbvw0QRXiDrtNxusODEGM3 Tg+pkgCyGN/gfTnbs3LVjTd9G6Cl2tTTJ86xc= 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=Bga657o52lEF+ySIRsSC+6B15SP/DYijC21uJLEpKHnEJCKWNYiQmKlOMe3Wqqmlyv vaX4jInMo0R+Zk71nHdy6Y4pBGEBQuHPUAoCkoQuWH+5hk0e7XdIhHl2JrHI8OBAJi5g prbPCUQySuZNCcFZ5UfpMaF5VKLJ+Klll6PVo= MIME-Version: 1.0 Received: by 10.216.65.142 with SMTP id f14mr1176764wed.2.1302213491698; Thu, 07 Apr 2011 14:58:11 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 14:58:11 -0700 (PDT) In-Reply-To: References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> Date: Thu, 7 Apr 2011 17:58:11 -0400 Message-ID: From: David Endicott To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cdf8db0982f7a04a05b343f Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 21:56:28 -0000 --000e0cdf8db0982f7a04a05b343f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Right, sorry. I misspoke. I meant to say, "scripts should only be trusted to talk with the *domains* they came from". (or subdomains, of course) On Thu, Apr 7, 2011 at 4:59 PM, I=F1aki Baz Castillo wrote: > 2011/4/7 David Endicott : > > Scripts should only be trusted to talk with the servers they came from. > > Please not, that assumes that the HTTP server must also speak > websocket (and the subprotocol over it). Let's design scalable systems > please. > > -- > I=F1aki Baz Castillo > > --000e0cdf8db0982f7a04a05b343f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ri= ght, sorry. =A0 I misspoke. =A0

=A0I meant to say, "= ;scripts should only be trusted to talk with the *domains* they came from&q= uot;.

(or subdomains, of course)



On Thu, Apr 7, 2011 at 4:59 PM, I=F1= aki Baz Castillo <ibc= @aliax.net> wrote:
2011/4/7 David Endicott <dendicott@gmail.com>:
> Scripts should only be trusted to talk with the serv= ers they came from.

Please not, that assumes that the HTTP server must also speak
websocket (and the subprotocol over it). Let's design scalable systems<= br> please.

--
I=F1aki Baz Castillo
<ibc@aliax.net>

--000e0cdf8db0982f7a04a05b343f-- From gregw@intalio.com Thu Apr 7 15:43:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9147C3A6943 for ; Thu, 7 Apr 2011 15:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt5QMVd-cBnW for ; Thu, 7 Apr 2011 15:43:32 -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 A66623A692F for ; Thu, 7 Apr 2011 15:43:32 -0700 (PDT) Received: by vws12 with SMTP id 12so2829751vws.31 for ; Thu, 07 Apr 2011 15:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.175 with SMTP id dl15mr2157197vdb.69.1302216317158; Thu, 07 Apr 2011 15:45:17 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Thu, 7 Apr 2011 15:45:17 -0700 (PDT) Date: Fri, 8 Apr 2011 08:45:17 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Sec- headers from server? 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, 07 Apr 2011 22:43:33 -0000 I've asked this question in several threads, but never got a response. So I'll give it it's own thread. Why are we putting Sec- on headers from the server? My understanding is that Sec- is a browser XHR mechanism that prevents js code sending these headers. No such mechanism exists on the server side and thus the Sec- prefix is meaningless in that direction. Worse still, it may give some false impression of security. Can we just drop the Sec- prefix from all server sent headers? regards From gregw@intalio.com Thu Apr 7 15:49:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A313A69B1 for ; Thu, 7 Apr 2011 15:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 OwkEEXnVZaHB for ; Thu, 7 Apr 2011 15:49:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CBE713A6965 for ; Thu, 7 Apr 2011 15:49:16 -0700 (PDT) Received: by vxg33 with SMTP id 33so2812105vxg.31 for ; Thu, 07 Apr 2011 15:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.36 with SMTP id cf4mr2119533vdc.29.1302216661384; Thu, 07 Apr 2011 15:51:01 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Thu, 7 Apr 2011 15:51:01 -0700 (PDT) In-Reply-To: References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> Date: Fri, 8 Apr 2011 08:51:01 +1000 Message-ID: From: Greg Wilkins To: David Endicott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 07 Apr 2011 22:49:18 -0000 On 8 April 2011 07:58, David Endicott wrote: > Right, sorry. =A0 I misspoke. > =A0I meant to say, "scripts should only be trusted to talk with the *doma= ins* > they came from". > (or subdomains, of course) or with domains that have been checked with a CORS preflight check? http://www.w3.org/TR/cors/ From theturtle32@gmail.com Thu Apr 7 17:36:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2766D3A698F for ; Thu, 7 Apr 2011 17:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzsv8a7as+FW for ; Thu, 7 Apr 2011 17:36:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 059263A6846 for ; Thu, 7 Apr 2011 17:36:57 -0700 (PDT) Received: by iye19 with SMTP id 19so3687907iye.31 for ; Thu, 07 Apr 2011 17:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=PaKVJB/TJOhkHnJlor0S2m698hQgG5jq4VMsgLsZLGI=; b=KwisgV2D6dR2DcD7mI9sCiyU4xdBfY8SFI5Jmk/MPJhjGBnlR/3IQtFWoanjoPPpIg DeC6FzWtHwM7zzYchBYHDgyiWIXkJrT0RO28ihNH3r1MgOCBPuR9/stklwcvPVzmc/OD Tu0Tn2lEvQFKe4+ypvhklaHT8ZdewsjjYdDQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=gbvUjGWxdW96WC2B3/tyxS+LPATNzsyZDN7m41tK50f+LdiIPbPk5vUjDjb8Dks6qv ho4m6jUWNJc9MqHJ1SEqPVwl6uzF+TWTVn+OVDw/0aLKwWLKI2GOuvUzhKUtvDisJv4/ fck7N4UlRr98fMv9w9NgPhO1xEKv1sTT8has0= Received: by 10.43.70.137 with SMTP id yg9mr2337238icb.218.1302223122852; Thu, 07 Apr 2011 17:38:42 -0700 (PDT) Received: from [10.138.126.66] ([166.205.136.186]) by mx.google.com with ESMTPS id y10sm1471512iba.63.2011.04.07.17.38.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 17:38:42 -0700 (PDT) References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Thu, 7 Apr 2011 17:38:34 -0700 To: Greg Wilkins Cc: "hybi@ietf.org" Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 08 Apr 2011 00:36:59 -0000 I see nothing wrong with the current model. The server declares whether or n= ot connections should be accepted from a given origin. If you want to clamp= that down to one domain for your server, that's very easy to do. But for o= thers that want to enable a broadly used API (Facebook for example) it's a h= uge boon to be able to optionally allow connections from any origin. The cu= rrent websocket model follows from the widely deployed and very successful s= ocket policy file approach pioneered by flash, but without the extra round t= rip. Brian Sent from my iPhone On Apr 7, 2011, at 3:51 PM, Greg Wilkins wrote: > On 8 April 2011 07:58, David Endicott wrote: >> Right, sorry. I misspoke. >> I meant to say, "scripts should only be trusted to talk with the *domain= s* >> they came from". >> (or subdomains, of course) >=20 > or with domains that have been checked with a CORS preflight check? >=20 > http://www.w3.org/TR/cors/ > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From dendicott@gmail.com Thu Apr 7 21:23:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAE73A69ED for ; Thu, 7 Apr 2011 21:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ymGkjdSHyZq for ; Thu, 7 Apr 2011 21:23:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F0FA33A6784 for ; Thu, 7 Apr 2011 21:23:51 -0700 (PDT) Received: by wyb29 with SMTP id 29so3033658wyb.31 for ; Thu, 07 Apr 2011 21:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FhK9E+ggqFqNZQUPa89HrhjuBTWsB7AAxyLb3pXs3FQ=; b=TsvCm6etJLNTmfVSYAvCJx9Zro4T7trTIHrAwMYnU4CuT4XAQAOIwmejZgw8E6/8LT 5PcvpQhNKr2DRYbvekVkcr2RPH80Jly4gxbxXL48t6bDzYqEMEiWBXijEIloP2mg4coM vu4PHiAG/fAUKgbpV2rKUxzYRc/X4R4Y7EnQM= 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=eGeB8O8syBv+vJDbT+a8mefrHCgGmEFH4Ao5ZBUwjDWUuSNz+Q4jM9eDCBKwki5YEl oPRzg7OCFY+9+HZXo52R5xRaEc7MYB2pt7qVghOdcked+BwEIdHOh2peMayEprlB0Tzk nmvs6ygsYJAFtyFGfPqIlbdgsmLQ0RGd2Yqww= MIME-Version: 1.0 Received: by 10.216.159.141 with SMTP id s13mr1458467wek.17.1302236734627; Thu, 07 Apr 2011 21:25:34 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 21:25:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2011 00:25:34 -0400 Message-ID: From: David Endicott To: Greg Wilkins Content-Type: multipart/alternative; boundary=0016e64f5de4fb1eeb04a0609d1e Cc: Hybi Subject: Re: [hybi] Sec- headers from server? 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, 08 Apr 2011 04:23:54 -0000 --0016e64f5de4fb1eeb04a0609d1e Content-Type: text/plain; charset=ISO-8859-1 I assumed it was for symmetry. I filed it under "harmless" and haven't worried about it. I hope nobody would assume anything from just the name of a header string. Heck, when I see "Security", I think of a financial instrument with periodic interest payments, so I didn't attach any special significance to "Sec-" headers. But you do make a valid point - it does imply something that isn't necessarily true. On Thu, Apr 7, 2011 at 6:45 PM, Greg Wilkins wrote: > I've asked this question in several threads, but never got a response. > So I'll give it it's own thread. > > Why are we putting Sec- on headers from the server? My > understanding is that Sec- is a browser XHR mechanism that prevents js > code sending these headers. > No such mechanism exists on the server side and thus the Sec- prefix > is meaningless in that direction. Worse still, it may give some false > impression of security. > > Can we just drop the Sec- prefix from all server sent headers? > > regards > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016e64f5de4fb1eeb04a0609d1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I assumed it was for symmetry. =A0=A0

I filed it under &= quot;harmless" and haven't worried about it.

<= div>I hope nobody would assume anything from just the name of a header stri= ng. =A0 Heck, when I see "Security", I think of a financial=A0ins= trument with periodic interest payments, so I didn't attach any special= significance to "Sec-" headers. =A0=A0

But you do make a valid point - it does imply something= that isn't necessarily true.


On Thu, Apr 7, 2011 at 6:45 PM, Greg Wilkins <= ;gregw@intalio.com> wrot= e:
I've asked this question in several thr= eads, but never got a response.
=A0So I'll give it it's own thread.

Why are we putting Sec- on headers from the server? =A0 =A0My
understanding is that Sec- is a browser XHR mechanism that prevents js
code sending these headers.
No such mechanism exists on the server side and thus the Sec- prefix
is meaningless in that direction. =A0Worse still, it may give some false impression of security.

Can we just drop the Sec- prefix from all server sent headers?

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

--0016e64f5de4fb1eeb04a0609d1e-- From dendicott@gmail.com Thu Apr 7 21:31:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CC93A69ED for ; Thu, 7 Apr 2011 21:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3Q+lJuX-Jrj for ; Thu, 7 Apr 2011 21:31:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 29D813A6784 for ; Thu, 7 Apr 2011 21:31:41 -0700 (PDT) Received: by wyb29 with SMTP id 29so3036768wyb.31 for ; Thu, 07 Apr 2011 21:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FYJ+WXa/v/kLlHDiytNtEiSDv/E+l0J8Q7q75ZMe7yo=; b=CT/JUx4M5ncadrJhmhNp+LeLVsIyxXhU3jEeQ1SKnpaHg3qPdGP+yoO0ZLXe8GvUdh QldkSlzcGpIEPUCetnA8hTRqPugx0Vgvosw3tBxb36dYq6QNXIyZ2wWzC7ohPCkng8sR fX66N/u6QmQYaDxiiYpcud/hVNmBeaaIYQFCw= 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=p6uDBsnPcRJCfu9NjjTrIKjGtRiinL27Yi8ksm8EFNmca278cqdYquoYP4rxOYLk+l BKO7eoA/uV4xd489MEzh0z+aWPkVER4W7gIRlPkr/oTtNRdfGo8/DGxq6c0GW4paJkfz I/JRoMtFdPx7Ejk8bkofG6Of9Lw/yaF11R1nk= MIME-Version: 1.0 Received: by 10.216.168.82 with SMTP id j60mr1452430wel.47.1302237205553; Thu, 07 Apr 2011 21:33:25 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Thu, 7 Apr 2011 21:33:25 -0700 (PDT) In-Reply-To: <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> Date: Fri, 8 Apr 2011 00:33:25 -0400 Message-ID: From: David Endicott To: Brian McKelvey Content-Type: multipart/alternative; boundary=0016e65b40e00ce47d04a060bad6 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 08 Apr 2011 04:31:45 -0000 --0016e65b40e00ce47d04a060bad6 Content-Type: text/plain; charset=ISO-8859-1 Alright, now I'm confused. (ignoring CORS et. al. for the moment) If I had a website on foo.com and it served a browser client some Javascript and that JS attempted a XmlHttp (or whatever) to facebook.com, it fails, yes? But, if the browser hits facebook.com and is served the Javascript from there, then it would succeed, yes? Doesn't/Shouldn't WS work within similar restrictions? On Thu, Apr 7, 2011 at 8:38 PM, Brian McKelvey wrote: > I see nothing wrong with the current model. The server declares whether or > not connections should be accepted from a given origin. If you want to > clamp that down to one domain for your server, that's very easy to do. But > for others that want to enable a broadly used API (Facebook for example) > it's a huge boon to be able to optionally allow connections from any origin. > The current websocket model follows from the widely deployed and very > successful socket policy file approach pioneered by flash, but without the > extra round trip. > > Brian > > Sent from my iPhone > > On Apr 7, 2011, at 3:51 PM, Greg Wilkins wrote: > > > On 8 April 2011 07:58, David Endicott wrote: > >> Right, sorry. I misspoke. > >> I meant to say, "scripts should only be trusted to talk with the > *domains* > >> they came from". > >> (or subdomains, of course) > > > > or with domains that have been checked with a CORS preflight check? > > > > http://www.w3.org/TR/cors/ > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > --0016e65b40e00ce47d04a060bad6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alright, now I'm confused.

(ignoring CORS et. al. fo= r the moment)

If I had a website on foo.com and it served a browser client some Javascript and= that JS attempted a XmlHttp (or whatever) to facebook.com, it fails, yes? =A0 =A0

But, if the browser hits facebook.com and is served the Javascript from there, then it would s= ucceed, yes?

Doesn't/Shouldn't WS work wit= hin similar restrictions?



On Thu, A= pr 7, 2011 at 8:38 PM, Brian McKelvey <theturtle32@gmail.com> wrote:
I see nothing wrong with the current model. =A0The server declares whether = or not connections should be accepted from a given origin. =A0If you want t= o clamp that down to one domain for your server, that's very easy to do= . =A0But for others that want to enable a broadly used API (Facebook for ex= ample) it's a huge boon to be able to optionally allow connections from= any origin. =A0The current websocket model follows from the widely deploye= d and very successful socket policy file approach pioneered by flash, but w= ithout the extra round trip.

Brian

Sent from my iPhone

On Apr 7, 2011, at 3:51 PM, Greg Wi= lkins <gregw@intalio.com> wr= ote:

> On 8 April 2011 07:58, David Endicott <dendicott@gmail.com> wrote:
>> Right, sorry. =A0 I misspoke.
>> =A0I meant to say, "scripts should only be trusted to talk wi= th the *domains*
>> they came from".
>> (or subdomains, of course)
>
> or with domains that have been checked with a CORS preflight check? >
> http://www.w3= .org/TR/cors/
> ________________________= _______________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

--0016e65b40e00ce47d04a060bad6-- From pmcmanus@mozilla.com Thu Apr 7 22:07:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5143A69A9 for ; Thu, 7 Apr 2011 22:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 necwpzJz3S2Q for ; Thu, 7 Apr 2011 22:06:58 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 1A54F3A67E6 for ; Thu, 7 Apr 2011 22:06:57 -0700 (PDT) Received: from Patrick-McManuss-MacBook.local (unknown [209.118.182.194]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 3775F10178 for ; Fri, 8 Apr 2011 01:08:42 -0400 (EDT) Message-ID: <4D9E9855.7080104@mozilla.com> Date: Thu, 07 Apr 2011 22:08:37 -0700 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000905090900030603050701" Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 08 Apr 2011 05:07:01 -0000 This is a multi-part message in MIME format. --------------000905090900030603050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, On 4/7/11 9:33 PM, David Endicott wrote: > > (ignoring CORS et. al. for the moment) you simply cannot ignore CORS - it is what is relevant here. > > If I had a website on foo.com and it served a browser > client some Javascript and that JS attempted a XmlHttp (or whatever) > to facebook.com , it fails, yes? > it fails the same-origin policy for javascript, but that xhr can still succeed if the cors requirements are met. cors requires the server to explicitly opt-in based on the origin information in the request. in your example the request to facebook.com would have origin information indicating foo.com and the server can decide whether or not that is a relationship it expects to see. > Doesn't/Shouldn't WS work within similar restrictions? The WS handshake uses a mechanism like CORS - it requires the server to opt in to the websocket connection given the origin information before any WS data is exchanged. That is the purpose of the client presenting a random token along with the origin information and the server performing a hash on that token and returning the result. This shows that the server has opted into connections from that origin. We know this because the websockets specification defines it and performing the esoteric hash proves the server knows websockets in particular, and not just http in general. To the working group: Let's stop going in circles and publish this darn protocol already and get some real experience with it. --------------000905090900030603050701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David,

On 4/7/11 9:33 PM, David Endicott wrote:

(ignoring CORS et. al. for the moment)

you simply cannot ignore CORS - it is what is relevant here.


If I had a website on foo.com and it served a browser client some Javascript and that JS attempted a XmlHttp (or whatever) to facebook.com, it fails, yes?    

it fails the same-origin policy for javascript, but that xhr can still succeed if the cors requirements are met. cors requires the server to explicitly opt-in based on the origin information in the request. in your example the request to facebook.com would have origin information indicating foo.com and the server can decide whether or not that is a relationship it expects to see.
Doesn't/Shouldn't WS work within similar restrictions?
The WS handshake uses a mechanism like CORS - it requires the server to opt in to the websocket connection given the origin information before any WS data is exchanged. That is the purpose of the client presenting a random token along with the origin information and the server performing a hash on that token and returning the result. This shows that the server has opted into connections from that origin. We know this because the websockets specification defines it and performing the esoteric hash proves the server knows websockets in particular, and not just http in general.

To the working group: Let's stop going in circles and publish this darn protocol already and get some real experience with it.



--------------000905090900030603050701-- From gregw@intalio.com Thu Apr 7 22:48:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4CA3A6881 for ; Thu, 7 Apr 2011 22:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.173, 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 bp5NMwJjU3re for ; Thu, 7 Apr 2011 22:48:20 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id DDB933A6989 for ; Thu, 7 Apr 2011 22:48:19 -0700 (PDT) Received: by vxg33 with SMTP id 33so2993115vxg.31 for ; Thu, 07 Apr 2011 22:50:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.36 with SMTP id cf4mr2530775vdc.29.1302241804544; Thu, 07 Apr 2011 22:50:04 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Thu, 7 Apr 2011 22:50:04 -0700 (PDT) In-Reply-To: <4D9E9855.7080104@mozilla.com> References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> <4D9E9855.7080104@mozilla.com> Date: Fri, 8 Apr 2011 15:50:04 +1000 Message-ID: From: Greg Wilkins To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 08 Apr 2011 05:48:21 -0000 On 8 April 2011 15:08, Patrick McManus wrote: > To the working group: Let's stop going in circles and publish this darn > protocol already and get some real experience with it. There is nothing preventing us shipping implementations that support the current draft and getting real experience with it. The currently released jetty server supports -76, -00, -01 and -06 drafts. The cometd framework uses that was was getting some real usage until such time as the browsers turned WS off. When -07 is shipped, we'll support that as well. I'd much rather we widely deployed -07,-08,... and then with experience obtained we can finalise the document, rather than the other way around. cheers From dendicott@gmail.com Fri Apr 8 06:17:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B0128C118 for ; Fri, 8 Apr 2011 06:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+KSzNWXirk2 for ; Fri, 8 Apr 2011 06:16:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 52E1528C117 for ; Fri, 8 Apr 2011 06:16:59 -0700 (PDT) Received: by wwa36 with SMTP id 36so2974750wwa.13 for ; Fri, 08 Apr 2011 06:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RnNqV+nAMxnSPVQ9yr3TTyNQ0vytH2ileDCV5N4xzM0=; b=ZYvR6iV8zeBUmlNNnkH4NEv33N6uvrftuhrFqNRznnEMXul3fMvP+iZj22btkkqiEf T8c0nLZngJI/EPKHUtnRXctUUjZS1IaG8plMFVWISPqHXk+43Imq3sWN0lRgiXZ19+Ks L/kClwl0qjTaaEQg+vChfA/hxUcxkRepFP9lA= 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=t0Z3FnRt4RCnCbmXNTG9Cgaq15kaVA/4bKceE3i+1QTVYq62u5fkpCjbz3x7yCOiyQ TMRqjyPzr2csJuVyx1EnkMhkPVqqs7e949qZX5gHfmdYKYNwfywJ02iIMVBcPOfGIIQ8 bccZL44jx4eCJn4jE+ogeRT8iLHDVUw552OzI= MIME-Version: 1.0 Received: by 10.216.168.82 with SMTP id j60mr1948992wel.47.1302268724081; Fri, 08 Apr 2011 06:18:44 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Fri, 8 Apr 2011 06:18:43 -0700 (PDT) In-Reply-To: <4D9E9855.7080104@mozilla.com> References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> <4D9E9855.7080104@mozilla.com> Date: Fri, 8 Apr 2011 09:18:43 -0400 Message-ID: From: David Endicott To: Patrick McManus Content-Type: multipart/alternative; boundary=0016e65b40e0b3764b04a068105f Cc: hybi@ietf.org Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 08 Apr 2011 13:17:00 -0000 --0016e65b40e0b3764b04a068105f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 8, 2011 at 1:08 AM, Patrick McManus wrote: > On 4/7/11 9:33 PM, David Endicott wrote: > (ignoring CORS et. al. for the moment) > > you simply cannot ignore CORS - it is what is relevant here. > What I meant by "ignoring CORS" was only that I was considering the case where it wasn't specified (it still being a working draft after all). However, you're entirely right that it does provide a mechanism to deal with cross-origin resources. The WS handshake uses a mechanism like CORS - it requires the server to opt > in to the websocket connection given the origin information before any WS > data is exchanged. > "like CORS" - hence my confusion. I was under the impression that the Javascript on the browser would enforce same-origin and WS would never get a chance to "opt-in". It would be prevented from establishing the connection in the first place. That is the purpose of the client presenting a random token along with the > origin information and the server performing a hash on that token and > returning the result. This shows that the server has opted into connections > from that origin. > We know this because the websockets specification defines it and performing > the esoteric hash proves the server knows websockets in particular, and not > just http in general. > Not really. Responding "101 Switching Protocols" along with the websocket headers shows that it has accepted the connection and it's using WS. The esoteric hash is irrelevant redundant hand-wavery. > To the working group: Let's stop going in circles and publish this darn > protocol already and get some real experience with it. > Totally agreed. More people need to be seeing what happens in real-world implementations so we can have a better understanding & discussion of the implications. But a caveat: sometimes going in circles means you haven't found a good solution. Perhaps there is still debate because some of WS is still questionable. The longer we leave it to "fix" something, the more painful it's going to be. --0016e65b40e0b3764b04a068105f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 8, 2011 at 1:08 AM, Patrick McManus = <pmcmanus@mozi= lla.com> wrote:
=20 =20 =20 =20
On 4/7/11 9:3= 3 PM, David Endicott wrote:
(ignoring CORS = et. al. for the moment)

you simply cannot ignore CORS - it is what is relevant here.

What I meant by "ignoring C= ORS" was only that I was considering the case where it wasn't spec= ified (it still being a working draft after all). =A0 =A0However, you'r= e entirely right that it does provide a mechanism to deal with cross-origin= resources. =A0=A0


The WS handshake uses a mechanism like CORS - it re= quires the server to opt in to the websocket connection given the origin information before any WS data is exchanged.

"like CORS" =A0- hence my confusion. =A0 I was under the impress= ion that the Javascript on the browser would enforce same-origin and WS wou= ld never get a chance to "opt-in". =A0It would be prevented from = establishing the connection in the first place. =A0 =A0

That is the purpose of the client presenting a random token along with the origin information and the server performing a hash on that token and returning the result. This shows that the server has opted into connections from that origin.
We know this because the websockets specification defines it= and performing the esoteric hash proves the server knows websockets in par= ticular, and not just http in general.
=A0
Not really. =A0 Responding "101 Switch= ing Protocols" along with the websocket headers shows that it has acce= pted the connection and it's using WS. =A0 =A0The esoteric hash is irre= levant redundant hand-wavery. =A0 =A0

=A0
To the working group: Let's stop going in circles and publish this darn protocol already and get some real experience with it.

Totally agreed. =A0 More people need to be s= eeing what happens in real-world implementations so we can have a better un= derstanding & discussion of the implications. =A0 But a caveat: sometim= es going in circles means you haven't found a good solution. =A0Perhaps= there is still debate because some of WS is still questionable. =A0 The lo= nger we leave it to "fix" something, the more painful it's go= ing to be.


--0016e65b40e0b3764b04a068105f-- From dendicott@gmail.com Fri Apr 8 06:24:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901213A691F for ; Fri, 8 Apr 2011 06:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGGDatMFgnhl for ; Fri, 8 Apr 2011 06:24:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B479728C106 for ; Fri, 8 Apr 2011 06:24:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so3403226wyb.31 for ; Fri, 08 Apr 2011 06:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BkGeyZ57Z238TkrBDgC+uQMR4V0JFOPRYFn2GYE6MA8=; b=hdVn0OI02kO97zmcrijxZgx2dxwehclC5bcE8YF9UMCRwBt7GAzqv1EWsFnTqbx2oN 4uGJEx7ORm304Yu2y5zOVkzrZ5zrpL52M0oMZ2Lcy+PS1pNF84WrzD7RwEp4i627eQUi MX6ijPOO2VJBUvrlXAJMtNU7zMNSR3SvVuX+w= 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=rB24+LysNTgfSbWElm5XyFfPYRTqwq/seNAHoY9ZdqRSNMdeEk8YiyDjbRtPldyKyU bn/N/b5NzVacQnOpjGganQvG/m44PeU9J06SjB9VEiPgCqOgaVMf2/tfuYEhbtNSSm9w r3MunVXWo73BCAJMrsfZfIqD+qjLAssGIAZ2o= MIME-Version: 1.0 Received: by 10.216.65.142 with SMTP id f14mr13259wed.2.1302269089779; Fri, 08 Apr 2011 06:24:49 -0700 (PDT) Received: by 10.216.49.134 with HTTP; Fri, 8 Apr 2011 06:24:49 -0700 (PDT) In-Reply-To: References: <4D9595AC.6000307@warmcat.com> <20110407011639.GQ26912@shareable.org> <0A7DD19B-808D-41E3-917B-550C0EE86048@gmail.com> <4D9E9855.7080104@mozilla.com> Date: Fri, 8 Apr 2011 09:24:49 -0400 Message-ID: From: David Endicott To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cdf8db07f943904a068260c Cc: hybi@ietf.org, Patrick McManus Subject: Re: [hybi] HTTP Upgrade - A Modest Proposal 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, 08 Apr 2011 13:24:03 -0000 --000e0cdf8db07f943904a068260c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 8, 2011 at 1:50 AM, Greg Wilkins wrote: > On 8 April 2011 15:08, Patrick McManus wrote: > > To the working group: Let's stop going in circles and publish this darn > > protocol already and get some real experience with it. > > > I'd much rather we widely deployed -07,-08,... and then with > experience obtained we can finalise the document, rather than the > other way around. > > Strongly agreed. Actually having an implementation in context with intended use-cases has been....enlightening. Note: my implementations are currently supporting -75, -00, -04, & -05. I'm going to add the most recent "real-soon-now". And once I've cleared some bureaucracy at work, I'm putting it up for public consumption. They are python based if anyone is interested. --000e0cdf8db07f943904a068260c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 8, 2011 at 1:50 AM, Greg Wil= kins <gregw@intal= io.com> wrote:
On 8 April 2011 15:08, Patrick McManus <pmcmanus@mozilla.com> wrote:
> To the working group: Let's stop going in circles and publish this= darn
> protocol already and get some real experience with it.


I'd much rather = we widely deployed -07,-08,... and then with
experience =A0obtained we can finalise the document, rather than the
other way around.

=A0
Strongly agreed. =A0 Actually having an= implementation in context with intended use-cases has been....enlightening= .

Note: my implementations are currently supportin= g -75, -00, -04, & -05. =A0 =A0I'm going to add the most recent &qu= ot;real-soon-now". =A0 =A0And once I've cleared some bureaucracy a= t work, I'm putting it up for public consumption. =A0 They are python b= ased if anyone is interested.
--000e0cdf8db07f943904a068260c-- From ibc@aliax.net Fri Apr 8 09:53:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFB53A6910 for ; Fri, 8 Apr 2011 09:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faRLgeHiyuWY for ; Fri, 8 Apr 2011 09:53:27 -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 1AE553A690B for ; Fri, 8 Apr 2011 09:53:26 -0700 (PDT) Received: by qwc23 with SMTP id 23so2720346qwc.31 for ; Fri, 08 Apr 2011 09:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.120.7 with SMTP id b7mr239725qar.147.1302281711400; Fri, 08 Apr 2011 09:55:11 -0700 (PDT) Received: by 10.229.35.72 with HTTP; Fri, 8 Apr 2011 09:55:11 -0700 (PDT) Date: Fri, 8 Apr 2011 18:55:11 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] draft-ibc-websocket-dns-srv-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, 08 Apr 2011 16:53:28 -0000 Hi, I've written a draft for including DNS SRV resolution in WebSocket prot= ocol: Title: DNS SRV Resource Records for the WebSocket Protocol Filename: draft-ibc-websocket-dns-srv-00 URL: http://oversip.net/public/draft-ibc-websocket-dns-srv.html It's the first revision and most probably needs some editorial improvements (not too much I hope). Best regards. --=20 I=C3=B1aki Baz Castillo From piotrku@microsoft.com Fri Apr 8 13:55:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4C13A69C6 for ; Fri, 8 Apr 2011 13:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWnN-e8kNhuw for ; Fri, 8 Apr 2011 13:55:57 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 42A6B3A6980 for ; Fri, 8 Apr 2011 13:55:57 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Apr 2011 13:57:42 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.33]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Fri, 8 Apr 2011 13:57:42 -0700 From: Piotr Kulaga To: "hybi@ietf.org" Thread-Topic: Re: [hybi] call for feedback on Masking alternatives Thread-Index: Acv2LwSlH3Gf5pfjTgWyBu7JncmjTg== Date: Fri, 8 Apr 2011 20:57:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_ED13A76FCE9E96498B049688227AEA291E19D87ETK5EX14MBXC202r_" MIME-Version: 1.0 Subject: Re: [hybi] call for feedback on Masking alternatives 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, 08 Apr 2011 20:57:38 -0000 --_000_ED13A76FCE9E96498B049688227AEA291E19D87ETK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I prefer #2 but can live with either approach. > (as HyBi wg co-chair) > > > Hi there, > > Last Tuesday, during the HyBi wg session at the IETF meeting, we discusse= d the masking issue. > > Based on that discussion, the decision is *only between two alternatives*= : > whether to (1) mask the entire frame, as in the current 06 spec, > or to (2) mask only after the op codes and length. Kind regards, Piotr Kulaga --_000_ED13A76FCE9E96498B049688227AEA291E19D87ETK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I prefer #2 but can live with either approach.
 
> (as HyBi wg co-chair)
>
>
> Hi there,
>
> Last Tuesday, during the HyBi wg session at the IETF meeting, we = discussed the masking issue.
>
> Based on that discussion, the decision is *only between two alter= natives*:
> whether to (1) mask the entire frame, as in the current 06 spec,<= /div>
> or to (2) mask only after the op codes and length.
 
Kind regards,
Piotr Kulaga
 
 --_000_ED13A76FCE9E96498B049688227AEA291E19D87ETK5EX14MBXC202r_-- From micheil@brandedcode.com Sat Apr 9 02:53:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166483A68D1 for ; Sat, 9 Apr 2011 02:53:20 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KA8DNyZc1mu for ; Sat, 9 Apr 2011 02:53:19 -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 0B84C3A68CD for ; Sat, 9 Apr 2011 02:53:18 -0700 (PDT) Received: by pvh1 with SMTP id 1so1866502pvh.31 for ; Sat, 09 Apr 2011 02:55:04 -0700 (PDT) Received: by 10.143.21.31 with SMTP id y31mr2763530wfi.377.1302342904777; Sat, 09 Apr 2011 02:55:04 -0700 (PDT) Received: from [192.168.46.181] (124-149-177-22.dyn.iinet.net.au [124.149.177.22]) by mx.google.com with ESMTPS id n4sm4904747wfl.14.2011.04.09.02.55.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 02:55:03 -0700 (PDT) From: Micheil Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Apr 2011 19:54:57 +1000 To: Hybi Message-Id: <192BF100-8E3F-4E94-A3BF-54C16FEF250A@brandedcode.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [hybi] Question on Closing Frames 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, 09 Apr 2011 09:53:20 -0000 Hi all,=20 I'm currently working on an implementation of draft-06, and the draft = does not indicate as to=20 whether or not the message/status code component of a closing frame = should be encoded=20 as utf8. The draft also does not define where in the frame this message/status = code should be=20 presented, eg, should it be in the application_data area?=20 I'd assume the answers are "yes, utf8", and "yes, in application_data", = however, I want to make=20 sure before doing so. This should probably be clarified in the drafts. Regards, Micheil Smith -- BrandedCode.com= From theturtle32@gmail.com Sat Apr 9 03:40:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35553A6A5B for ; Sat, 9 Apr 2011 03:40:29 -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=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEs+qa3i9hvv for ; Sat, 9 Apr 2011 03:40:28 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id B88863A69E7 for ; Sat, 9 Apr 2011 03:40:28 -0700 (PDT) Received: by pxi20 with SMTP id 20so2424234pxi.27 for ; Sat, 09 Apr 2011 03:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eZicSg78hsswKhUEkgNuz9LyDgwx/9CdenTMSZUywKw=; b=EFsVxbQyisA9wjrIFMde1DDZlH40/qJOkvhZD/orPYgTE4fi25vtjlJZyUYHhkITWx SEtU1pi45WWnndRHLdTLA4JU8Blzr2Dh5JKKDOXPNDbRp3bARhuCfZhDi5xlwsMhzxTD 3JmhwSH/gxiJZfbHcaIBtIGCsdabJpUtWluhw= 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:content-transfer-encoding; b=MJANmuGQYMR0FU4vb9WmewP6rgTQd2fBpfbdCrVH0vKUrEuB2RlqjvkIb2pFFhn5GI dVQlrdtFhyxaGQRXLNl0dIps2m6C5q60RLORm/2ms/H7P99r8aKzpceEntTM7somUOz8 kR7sHWheBd/1lRnwkPJkD0JqWpVcxy2YYYvpY= MIME-Version: 1.0 Received: by 10.142.131.21 with SMTP id e21mr2662560wfd.320.1302345734700; Sat, 09 Apr 2011 03:42:14 -0700 (PDT) Received: by 10.68.44.67 with HTTP; Sat, 9 Apr 2011 03:42:14 -0700 (PDT) In-Reply-To: <192BF100-8E3F-4E94-A3BF-54C16FEF250A@brandedcode.com> References: <192BF100-8E3F-4E94-A3BF-54C16FEF250A@brandedcode.com> Date: Sat, 9 Apr 2011 03:42:14 -0700 Message-ID: From: Brian To: Micheil Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Question on Closing Frames 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, 09 Apr 2011 10:40:30 -0000 In section 4.5.1 the draft does actually specify that the close reason should be encoded as a big-endian short, optionally followed by a utf-8 text description: The Close message MAY contain a body (the "application data" portion of the frame) that indicates a reason for closing, such as an endpoint shutting down, an endpoint having received a message too large, or an endpoint having received a message that does not conform to the format expected by the other endpoint. If there is a body, the first two bytes of the body MUST be a 2-byte integer (in network byte order) representing a status code defined in Section 7.4. Following the 2-byte integer the body MAY contain UTF-8 encoded data, the interpretation of which is not defined by this specification. Cheers, Brian On Sat, Apr 9, 2011 at 2:54 AM, Micheil Smith wro= te: > Hi all, > > I'm currently working on an implementation of draft-06, and the draft doe= s not indicate as to > whether or not the message/status code component of a closing frame shoul= d be encoded > as utf8. > > The draft also does not define where in the frame this message/status cod= e should be > presented, eg, should it be in the application_data area? > > I'd assume the answers are "yes, utf8", and "yes, in application_data", h= owever, I want to make > sure before doing so. > > =A0This should probably be clarified in the drafts. > > Regards, > Micheil Smith > -- > BrandedCode.com > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From micheil@brandedcode.com Sat Apr 9 09:22:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA893A695F for ; Sat, 9 Apr 2011 09:22:19 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4gmHryg79Ob for ; Sat, 9 Apr 2011 09:22:18 -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 31DB83A6819 for ; Sat, 9 Apr 2011 09:22:17 -0700 (PDT) Received: by pvh1 with SMTP id 1so1947634pvh.31 for ; Sat, 09 Apr 2011 09:24:04 -0700 (PDT) Received: by 10.143.136.1 with SMTP id o1mr2889784wfn.188.1302366243258; Sat, 09 Apr 2011 09:24:03 -0700 (PDT) Received: from [192.168.46.181] (124-149-177-22.dyn.iinet.net.au [124.149.177.22]) by mx.google.com with ESMTPS id p40sm5336885wfc.5.2011.04.09.09.23.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 09:24:01 -0700 (PDT) From: Micheil Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Apr 2011 02:23:56 +1000 To: Hybi Message-Id: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 16:22:19 -0000 I'm currently working further still on my websocket protocol = implementation for node.js, and=20 I'm trying to figure out how to support the fragmentation of frames and = whether I should have=20 a automatic fragmentation of frames greater than a certain length. Can anyone answer the following: - Should messages be automatically fragmented? - What are recommended fragmentation sizes? - Should the complete headers be repeated each fragment? - Is the payload length the length of just that fragments payload, or is = it the total payload length? Regards, Micheil Smith -- BrandedCode.com From andy.warmcat.com@googlemail.com Sat Apr 9 09:32:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5E53A695F for ; Sat, 9 Apr 2011 09:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJDwC5mfmNTy for ; Sat, 9 Apr 2011 09:32:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C1D5E3A6819 for ; Sat, 9 Apr 2011 09:32:10 -0700 (PDT) Received: by wyb29 with SMTP id 29so4208674wyb.31 for ; Sat, 09 Apr 2011 09:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4afHCa+JtbWmPF/1q7hsimlWb7prvluE5GxCQkm8N9I=; b=HXLQEFWMSLdt7DaBDaI/BQ14HWHhdNedzyEfeiQjkyl1A7/2fMGiOgyEaoIV3OGywj 6IyvsUjkpv6bOzBFoYYbFf/AN6PWSe/W/YUxUnNCIxPJi/QNIEdq1/xm4vUrdM2gZMUL XEnsNyL4Dzxs6a2bJHRfPU4Oxa3RXbiyMoDkA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pZMJY8L+2FddDP4Sv0hFdYk2gK8G03x7Do5dOXPMlDZH9UM0u3eFRWlD/V2a2kEqJU ms46S+XnW/8Ltb3z76WXoHr93GnjsJQJrmOS7e0pgA43HbUpDTYaF/F/HGQDOWYgkauE ksphD2Or6rHPccHwTlAffa2iMwtQQoy8WiXhc= Received: by 10.216.12.146 with SMTP id 18mr925944wez.63.1302366836247; Sat, 09 Apr 2011 09:33:56 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o6sm2349217wbo.3.2011.04.09.09.33.54 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 09:33:55 -0700 (PDT) Sender: Andy Green Message-ID: <4DA08A71.7090405@warmcat.com> Date: Sat, 09 Apr 2011 17:33:53 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Micheil Smith References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> In-Reply-To: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 16:32:13 -0000 On 04/09/2011 05:23 PM, Somebody in the thread at some point said: > I'm currently working further still on my websocket protocol implementation for node.js, and > I'm trying to figure out how to support the fragmentation of frames and whether I should have > a automatic fragmentation of frames greater than a certain length. > > Can anyone answer the following: > - Should messages be automatically fragmented? > - What are recommended fragmentation sizes? > - Should the complete headers be repeated each fragment? > - Is the payload length the length of just that fragments payload, or is it the total payload length? Not sure if this is what you are asking overall, but it was the understanding I was initially missing: - length on frames is bogus in terms of overall message length, totally meaningless - Nothing actually describes overall message length unless it's the degenerate case the message is one frame which has FIN set; the frame length is the message length then. - when you're in a frame of the length that was told, nothing else can come on the wire until you sent enough packets to deliver the amount of content promised - therefore to allow PING and PONG control frames to happen with reasonable latency, you should restrict the max frame length you ever issue - message completion is only shown by a frame with FIN bit set. What went before in terms of frames without FIN bit set is meaningless except for the total amount of payload it represented. Only the end of the frame who had FIN bit set triggers the whole message, which can be many frames each of which may be many packets, being completed - In browser case, Javascript only gets told about one event when the FIN frame is completed and gets the whole aggregated payload. Actually 64 bit frame length is kind of worthless AFAIK. I don't care either way but it'd be fine restricting it to 16 or 32 bits given the need to break up messages into short frames for control frame latency. -Andy From jat@google.com Sat Apr 9 09:43:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDA13A695F for ; Sat, 9 Apr 2011 09:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.931 X-Spam-Level: X-Spam-Status: No, score=-105.931 tagged_above=-999 required=5 tests=[AWL=0.045, 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 vCxe1HgcKMMp for ; Sat, 9 Apr 2011 09:43:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3994F3A6819 for ; Sat, 9 Apr 2011 09:43:14 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p39Gixa8011994 for ; Sat, 9 Apr 2011 09:44:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302367500; bh=1wQdm3T1FHoEHAqAceh3H1o52AI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=k5gi7kUGIdWtgSPm4fBwPONGA4RohYFGi5PD/0I6RhTHfxmWccJDgURcW6VEGqn2e PFP2TSPx06kLa5/05tBbg== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by kpbe12.cbf.corp.google.com with ESMTP id p39GiwYF009224 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 9 Apr 2011 09:44:58 -0700 Received: by ywf9 with SMTP id 9so2056252ywf.13 for ; Sat, 09 Apr 2011 09:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q6lwCjdYPUSF5WCppsxzDVLNoDG8oeLa/wS9gHqAJGY=; b=Ec25sbfGQL/KkOWp80R69WZndsaUVmKmSv7BC3bEyP6l4lFw9u7ESr+M/RwOpJGAof dizwTwtLFLRwJ2MsNDuw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=awSjBETtxcaiCZQ3LSbgRmXpZe5Gg35JSOmNZp3m9kzq9pN7nWyc3hSlZMLWlOu5K2 OyntVdY+v/eoY6/Bx+fw== Received: by 10.150.162.2 with SMTP id k2mr3428034ybe.10.1302367498155; Sat, 09 Apr 2011 09:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Sat, 9 Apr 2011 09:44:38 -0700 (PDT) In-Reply-To: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> From: John Tamplin Date: Sat, 9 Apr 2011 12:44:38 -0400 Message-ID: To: Micheil Smith Content-Type: multipart/alternative; boundary=000e0cd60ae418379904a07f1039 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 16:43:16 -0000 --000e0cd60ae418379904a07f1039 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 9, 2011 at 12:23 PM, Micheil Smith wrote: > I'm currently working further still on my websocket protocol implementation > for node.js, and > I'm trying to figure out how to support the fragmentation of frames and > whether I should have > a automatic fragmentation of frames greater than a certain length. > > Can anyone answer the following: > - Should messages be automatically fragmented? > If it is convenient for you, you are free to fragment. The two primary reasons for supporting fragmentation are (from my recollection anyway): - to allow sending dynamically generated content without requiring the sender to buffer the entire message first - to allow a multiplexor to fragment messages from logical channels to allow fair use of the shared channel > - What are recommended fragmentation sizes? > None have been recommended. For the dynamic content use case above, it would likely be a reasonable buffer size, such as 64k. For the mux case, it is likely to be dynamic based on the utilization of the shared channel or the characteristics of the logical channel flows, and in any case would be defined in the mux extension. > - Should the complete headers be repeated each fragment? > What complete headers are you referring to? > - Is the payload length the length of just that fragments payload, or is it > the total payload length? > A frame's payload length is the length of that frame, including any extension data. There is no length for the unfragmented message. During the framing discussions, it was suggested that could be provided in an extension if it proved useful (to allow the receiver to allocate the entire buffer for the message). -- John A. Tamplin Software Engineer (GWT), Google --000e0cd60ae418379904a07f1039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 9, 2011 at 12:23 PM, Micheil Smith <= span dir=3D"ltr"><micheil@bra= ndedcode.com> wrote:
I'm currently working further still on my websocket protocol implementa= tion for node.js, and
I'm trying to figure out how to support the fragmentation of frames and= whether I should have
a automatic fragmentation of frames greater than a certain length.

Can anyone answer the following:
- Should messages be automatically fragmented?

If it is convenient for you, you are free to fragment. =C2=A0The tw= o primary reasons for supporting fragmentation are (from my recollection an= yway):
=C2=A0- to allow sending dynamically generated content without requiri= ng the sender to buffer the entire message first
=C2=A0- to allow= a multiplexor to fragment messages from logical channels to allow fair use= of the shared channel
=C2=A0
- What are recommended fragmentation sizes?

=
None have been recommended. =C2=A0For the dynamic content use case abo= ve, it would likely be a reasonable buffer size, such as 64k. =C2=A0For the= mux case, it is likely to be dynamic based on the utilization of the share= d channel or the characteristics of the logical channel flows, and in any c= ase would be defined in the mux extension.
=C2=A0
- Should the complete headers be repeated each fragment?

What complete headers are you referring to?
=C2= =A0
- Is the payload length the length of just that fragments payload, or is it= the total payload length?

A frame'= s payload length is the length of that frame, including any extension data.= =C2=A0There is no length for the unfragmented message. =C2=A0During the fr= aming discussions, it was suggested that could be provided in an extension = if it proved useful (to allow the receiver to allocate the entire buffer fo= r the message).=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd60ae418379904a07f1039-- From jat@google.com Sat Apr 9 09:45:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E424B3A6819 for ; Sat, 9 Apr 2011 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.044, 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 zvOAof23HgjO for ; Sat, 9 Apr 2011 09:45:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 20F6C3A680A for ; Sat, 9 Apr 2011 09:45:52 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p39GlceA000938 for ; Sat, 9 Apr 2011 09:47:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302367659; bh=ZauTaJAQ5E9cP+/WJ+E7yHRiF+c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WfVOdPsIbJkjMBIV7/T/6voD+P4lzexCjFGzKln7Nu3dJsibQ6gKi3BF8atWcO/rr FbL8K+DBGKdLxy4gXjTfg== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by kpbe18.cbf.corp.google.com with ESMTP id p39GlbMi000710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 9 Apr 2011 09:47:37 -0700 Received: by gyb11 with SMTP id 11so3117581gyb.15 for ; Sat, 09 Apr 2011 09:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lqE8h3cpV9lca71nhH9qfH24jUfcq7H9WQrRfeJh3w4=; b=vuR4HZHUc1IkH/ddP/ByhcRBR2m9GvvcZs40Qm2UNFiiynlirSXooPQjVko6cxVxiy OqDxpXcvaq4gsyOsSC2Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=HE54tvTlOf5pBl7URMeaMP9JIVzS5ijtvOymHFcYETtrEDQv5oOowAKp1DjrLd3Sxq Oy0V+ByjXz749tcJIMGA== Received: by 10.150.69.30 with SMTP id r30mr3017388yba.124.1302367657179; Sat, 09 Apr 2011 09:47:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Sat, 9 Apr 2011 09:47:17 -0700 (PDT) In-Reply-To: <4DA08A71.7090405@warmcat.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> From: John Tamplin Date: Sat, 9 Apr 2011 12:47:17 -0400 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=000e0cd5919692bbde04a07f19a9 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 16:45:54 -0000 --000e0cd5919692bbde04a07f19a9 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 9, 2011 at 12:33 PM, Andy Green wrote: > Actually 64 bit frame length is kind of worthless AFAIK. I don't care > either way but it'd be fine restricting it to 16 or 32 bits given the need > to break up messages into short frames for control frame latency. > During the framing discussions, there were people that wanted to reduce load on the server by allowing an entire file in a single frame using sendfile and equivalent. Given that available bandwidth and the sizes of media files, it was argued that 4G was insufficient, and the cost to support it seems small. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5919692bbde04a07f19a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 9, 2011 at 12:33 PM, Andy Green <andy@warmcat.com&= gt; wrote:
Actually 64 bit frame length is kind of worthless AFAIK. = =C2=A0I don't care either way but it'd be fine restricting it to 16= or 32 bits given the need to break up messages into short frames for contr= ol frame latency.

During the framing discussions, there were= people that wanted to reduce load on the server by allowing an entire file= in a single frame using sendfile and equivalent. =C2=A0Given that availabl= e bandwidth and the sizes of media files, it was argued that 4G was insuffi= cient, and the cost to support it seems small. =C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd5919692bbde04a07f19a9-- From andy.warmcat.com@googlemail.com Sat Apr 9 10:30:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF5A3A6889 for ; Sat, 9 Apr 2011 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAySL4o+ZHHm for ; Sat, 9 Apr 2011 10:30:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5169D3A6876 for ; Sat, 9 Apr 2011 10:30:18 -0700 (PDT) Received: by wyb29 with SMTP id 29so4231432wyb.31 for ; Sat, 09 Apr 2011 10:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iclzSV+i5Syp6h8a/J73C3ePw/LVIwN5O0ljS7g1Kbc=; b=GqwvkSjpRWEbawvrPQaqvJyUjI9MmEmhcPbpMWNjAF5zafG/iBGRn5yJHOhxM+4Dk1 1um9benh1WnwQnatEE9m2rY8FkB2kTARUP6RF9CraVj6/63jTseFU93PPB4AppwwpuAJ 2Xx9WJepI0gwAjinqkGnnVLBJ9DjkA+Aqu2Eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=D3ue7TvPfAaF+Uz44zl59sTGBFSWEymTQ+ggJM6JA3RkI3blMKA4GwJBcWGgBGQtvO jlkfYfpweCJsB23vtcOFzSJcJJ/vxZq2H3XlYPcZivErANCrTLm0Fmwswa9dMfeAtAkS sZWihp7BQtFUfxie6mrm+f5Dyy3lC8cLlIsLo= Received: by 10.216.15.133 with SMTP id f5mr221592wef.71.1302370323549; Sat, 09 Apr 2011 10:32:03 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id e13sm2371204wbi.40.2011.04.09.10.32.02 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 10:32:02 -0700 (PDT) Sender: Andy Green Message-ID: <4DA09811.6070707@warmcat.com> Date: Sat, 09 Apr 2011 18:32:01 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Tamplin References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 17:30:19 -0000 On 04/09/2011 05:47 PM, Somebody in the thread at some point said: > On Sat, Apr 9, 2011 at 12:33 PM, Andy Green > wrote: > > Actually 64 bit frame length is kind of worthless AFAIK. I don't > care either way but it'd be fine restricting it to 16 or 32 bits > given the need to break up messages into short frames for control > frame latency. > > > During the framing discussions, there were people that wanted to reduce > load on the server by allowing an entire file in a single frame using > sendfile and equivalent. Given that available bandwidth and the sizes > of media files, it was argued that 4G was insufficient, and the cost to > support it seems small. Sure it's not any big problem. It does make people reading the spec assume it must be message size though because of the bother taken to allow the headroom, and I would have gotten the bit of my life back I wasted with people arguing about The Horror of up to 8 bytes controllable on the wire if it was just defined to be 2 bytes max. I don't believe anyone will implement systems using 63 bit frame lengths and it's almost zero cost to break a large message into multiple frames at some length ceiling. Does anyone actually plan to use 8-byte frame (nothing to do with message) lengths? -Andy From theturtle32@gmail.com Sat Apr 9 12:13:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676C23A6972 for ; Sat, 9 Apr 2011 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep7stD+4u5Gp for ; Sat, 9 Apr 2011 12:13:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id DA5243A6966 for ; Sat, 9 Apr 2011 12:13:50 -0700 (PDT) Received: by iye19 with SMTP id 19so5443445iye.31 for ; Sat, 09 Apr 2011 12:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=UN3kYJ7sAX6rRP0ZO2E8dkesH0G3sOjBh1TTM+PPd7w=; b=jFIJBR55OD1I5JoANwuWDfbp6+u4bBbPb0zGUdYGlwChGq6Qc05If0X67PVFqVV6ZX kk4MJxGFSSWJwmric3lFwlxYiJQjLZceqCgK/KJw4SLg2W0X9OP4ZjWQkCF7hLAhEg3r vTvUwo/opG/wpSHISaJQ9P+DRpiGF97VIyVcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=t21y5X23AlahiGngu4II9wnYrKwv/Mpsh1WBnTGNoqVgF9J7PXT+SMvHxbcMYl+OcV j/aKJ787Erczq5zSwp3r7wWDwP0DTVYWPzMeWpWpjMTBPAvfhho8lPt/espIdZrCKY2U rBKra2ss+k4DdjTvvLl8chqRlwLhLk2C7y6IE= Received: by 10.231.82.139 with SMTP id b11mr3478218ibl.134.1302376536759; Sat, 09 Apr 2011 12:15:36 -0700 (PDT) Received: from [10.67.157.158] ([166.205.137.186]) by mx.google.com with ESMTPS id mv26sm2832912ibb.28.2011.04.09.12.15.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 12:15:36 -0700 (PDT) References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <4DA09811.6070707@warmcat.com> In-Reply-To: <4DA09811.6070707@warmcat.com> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7B86A956-F274-4816-B201-5C307117DACF@gmail.com> X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Sat, 9 Apr 2011 12:15:29 -0700 To: Andy Green Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 19:13:51 -0000 Nope. In my as3 and JavaScript (Node.JS) implementations I actually throw a= n error if the most significant four bytes of the 64-bit length field are an= ything other than zero. At least for right now, there's no chance in hell t= hat I'll need to handle a frame that large. Brian Sent from my iPhone On Apr 9, 2011, at 10:32 AM, Andy Green wrote: > I don't believe anyone will implement systems using 63 bit frame lengths a= nd it's almost zero cost to break a large message into multiple frames at so= me length ceiling. Does anyone actually plan to use 8-byte frame (nothing t= o do with message) lengths? From gregw@intalio.com Sat Apr 9 14:48:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFFC3A6907 for ; Sat, 9 Apr 2011 14:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 0R40CejLbX+y for ; Sat, 9 Apr 2011 14:48:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id AE4C83A68CB for ; Sat, 9 Apr 2011 14:48:03 -0700 (PDT) Received: by vxg33 with SMTP id 33so4210446vxg.31 for ; Sat, 09 Apr 2011 14:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.230 with SMTP id el6mr1654315vdb.149.1302385788281; Sat, 09 Apr 2011 14:49:48 -0700 (PDT) Received: by 10.52.156.164 with HTTP; Sat, 9 Apr 2011 14:49:48 -0700 (PDT) In-Reply-To: References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> Date: Sun, 10 Apr 2011 07:49:48 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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, 09 Apr 2011 21:48:04 -0000 Currently the jetty server has a configurable buffer size. If a frame arrives that is larger than the buffer size, we close the connection with a message too large status code. This suggests to me that we should be able to declare the maximal frame size we are prepared to handle, so that a client does not need to guess, reduce, guess, reduce - or just pick a low value. Of course the server could handle large frames by streaming to disk - but then we often run in situation that have no disk, or that are disk constrained. Plus 64b frames would pretty soon be able to DOS attack most disks. cheers On 10 April 2011 02:47, John Tamplin wrote: > On Sat, Apr 9, 2011 at 12:33 PM, Andy Green wrote: >> >> Actually 64 bit frame length is kind of worthless AFAIK. =A0I don't care >> either way but it'd be fine restricting it to 16 or 32 bits given the ne= ed >> to break up messages into short frames for control frame latency. > > During the framing discussions, there were people that wanted to reduce l= oad > on the server by allowing an entire file in a single frame using sendfile > and equivalent. =A0Given that available bandwidth and the sizes of media > files, it was argued that 4G was insufficient, and the cost to support it > seems small. > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From gezelter@rlgsc.com Sat Apr 9 16:22:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4F33A697A for ; Sat, 9 Apr 2011 16:22:24 -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 sw-lj+Mxibhp for ; Sat, 9 Apr 2011 16:22:23 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id DA3143A6977 for ; Sat, 9 Apr 2011 16:22:22 -0700 (PDT) Received: (qmail 29084 invoked from network); 9 Apr 2011 23:24:07 -0000 Received: from unknown (141.157.198.38) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 09 Apr 2011 23:24:06 -0000 Message-ID: <4DA0EA91.2070003@rlgsc.com> Date: Sat, 09 Apr 2011 18:24:01 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] JavaScript WebSockets Dependencies X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 23:22:24 -0000 There have been several references recently on the dichotomy between text and binary. A recurring theme seems to be the effect that this is helpful to the JavaScript library. As a matter of protocol design, IMHO, this is a misjudgment (which is the underlying reason for the similar comments in my recent blog posting). Just because there may be implementation issues in JavaScript is (emphatically) not a reason to burden the Websocket protocol with the resulting baggage. JavaScript is not the only language in which the protocol will be implemented. The history of language-favoring APIs is not a pleasant one to contemplate. On a similar note, I would not recommend the use of Base64 encoding within the wire protocol (outside of the initial handshake, which I concur with the IETF recommendation of UTF-8). Once communications have been established, character set negotiation is properly a function of the protocol levels above the WebSocket protocol, and the WebSocket protocol should be completely agnostic in this regard. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From micheil@brandedcode.com Sat Apr 9 17:14:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D65E3A6918 for ; Sat, 9 Apr 2011 17:14:45 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTR41T0Q5rBX for ; Sat, 9 Apr 2011 17:14:44 -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 59AB23A67EE for ; Sat, 9 Apr 2011 17:14:44 -0700 (PDT) Received: by pwi5 with SMTP id 5so2067977pwi.31 for ; Sat, 09 Apr 2011 17:16:30 -0700 (PDT) Received: by 10.142.50.19 with SMTP id x19mr2198317wfx.204.1302394590679; Sat, 09 Apr 2011 17:16:30 -0700 (PDT) Received: from [192.168.46.181] (124-149-177-22.dyn.iinet.net.au [124.149.177.22]) by mx.google.com with ESMTPS id y2sm5869661wfd.8.2011.04.09.17.16.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 17:16:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Micheil Smith In-Reply-To: <4DA0EA91.2070003@rlgsc.com> Date: Sun, 10 Apr 2011 10:16:26 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <787DC682-2423-4859-ABE5-4D9B32B5ADD2@brandedcode.com> References: <4DA0EA91.2070003@rlgsc.com> To: gezelter@rlgsc.com X-Mailer: Apple Mail (2.1082) Cc: hybi@ietf.org Subject: Re: [hybi] JavaScript WebSockets Dependencies 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: Sun, 10 Apr 2011 00:14:45 -0000 [Bob, apologies for the double delivery of this response.] Despite being an author of one of the javascript websocket-server = implementations=20 out there, I agree that WebSocket's shouldn't be changed just to make = them easier=20 to implement in specific languages. If there are things that your language can't do, chances are you can = drop down to the=20 interpreter or VM or compiler, which is more then likely capable of = doing what needs=20 to be done. (eg, going from javascript down to C or C++) =96 Micheil On 10/04/2011, at 9:24 AM, Bob Gezelter wrote: > There have been several references recently on the dichotomy between = text > and binary. A recurring theme seems to be the effect that this is = helpful to > the JavaScript library. >=20 > As a matter of protocol design, IMHO, this is a misjudgment (which is = the > underlying reason for the similar comments in my recent blog posting). = Just > because there may be implementation issues in JavaScript is = (emphatically) > not a reason to burden the Websocket protocol with the resulting = baggage. > JavaScript is not the only language in which the protocol will be > implemented. The history of language-favoring APIs is not a pleasant = one to > contemplate. >=20 > On a similar note, I would not recommend the use of Base64 encoding = within > the wire protocol (outside of the initial handshake, which I concur = with the > IETF recommendation of UTF-8). Once communications have been = established, > character set negotiation is properly a function of the protocol = levels > above the WebSocket protocol, and the WebSocket protocol should be > completely agnostic in this regard. >=20 > - Bob > = +-------------------------------------------------------------------------= -+ > | Robert "Bob" Gezelter E-Mail: = gezelter@rlgsc.com | > | Robert Gezelter Software Consultant = | > | 35-20 167th Street, Suite 215 Fax: (on Request) = | > | Flushing, New York 11358-1731 = | > | United States of America http://www.rlgsc.com = | > = +-------------------------------------------------------------------------= -+ > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From w@1wt.eu Sat Apr 9 23:21:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDCF3A69D9 for ; Sat, 9 Apr 2011 23:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 tagged_above=-999 required=5 tests=[AWL=-0.987, 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 X1qtn0qb0Ln3 for ; Sat, 9 Apr 2011 23:21:58 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 306B13A69D3 for ; Sat, 9 Apr 2011 23:21:57 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3A6NbCM020356; Sun, 10 Apr 2011 08:23:37 +0200 Date: Sun, 10 Apr 2011 08:23:37 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110410062337.GI15894@1wt.eu> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.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] On Fragmentation of Frames 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: Sun, 10 Apr 2011 06:21:59 -0000 On Sun, Apr 10, 2011 at 07:49:48AM +1000, Greg Wilkins wrote: > Currently the jetty server has a configurable buffer size. If a frame > arrives that is larger than the buffer size, we close the connection > with a message too large status code. > > This suggests to me that we should be able to declare the maximal > frame size we are prepared to handle, so that a client does not need > to guess, reduce, guess, reduce - or just pick a low value. Indeed. Announcing that makes a lot of sense and is comparable to what TCP does with MSS. Both the client and the server should announce what they support, because WS is bidirectional. We could use control frames for that, and specify that any implementation should support frames of at least XXX bytes until advertised otherwise (something like 1kB seems fine, as it helps remaining below one typical MSS). That would allow both sides to start sending and to advertise their receive capabilities in the same round trip as the data. For instance : Client Server GET + Upgrade -----------------> <----------------- 101 + Upgrade + MFS + data MFS + data --------------------> MFS = Max Frame Size. Control frame to be defined. We should also mention that all sizes below the default one are forbidden. Alternatively we can decide that what is announced is the difference between the real size and the default size. The frame size should cover the mask too, it should really be the buffer size. > Of course the server could handle large frames by streaming to disk - Buffering to disk is always bad in networked environments anyway. It slows down everyone and prevents scaling. So we should do anything we can to ensure this can be avoided. Willy From andy.warmcat.com@googlemail.com Sun Apr 10 00:16:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8EF3A69DB for ; Sun, 10 Apr 2011 00:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyLKTGLE1VXT for ; Sun, 10 Apr 2011 00:16:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8BAB43A69D3 for ; Sun, 10 Apr 2011 00:16:06 -0700 (PDT) Received: by wyb29 with SMTP id 29so4453797wyb.31 for ; Sun, 10 Apr 2011 00:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rF3Dd0Vcr/nkopDap9y9GXk2pLbvNettj3SYi664LAY=; b=dk7mD5Tzmil6+N/4zLYWUBFEpcBlTdQd6/ur+Lb/HgsvsQxQlCWHG6sF7JISRLotxa 3ba+MB5JawaNy7UWxMxlCBxjaBC4s3UrknSi/I+fXbRsTpcCaOw3TbUvngFxWklRNMWH dF6+3WkZ6JhosGZRKX8cySIAheWMPNZ7Bp5qY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=K3UB3/CqIege/GusTX3nXohIei92Sj8l9ri/pOMzbchn7zpTAowVHlz6gqy3rZscVL ZmwYFX29O39UXkCYUPVRRD+TXrtlZF5MdHAY/Oo09k5ybkOaqpHydKne869cPxCOV0kQ RB5jygwIohn/nd+t5M/6OIChEQFqDZXfDSiqo= Received: by 10.216.166.67 with SMTP id f45mr1368598wel.112.1302419872487; Sun, 10 Apr 2011 00:17:52 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id u9sm2651666wbg.17.2011.04.10.00.17.49 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 00:17:50 -0700 (PDT) Sender: Andy Green Message-ID: <4DA15996.9010901@warmcat.com> Date: Sun, 10 Apr 2011 08:17:42 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Willy Tarreau References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> In-Reply-To: <20110410062337.GI15894@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 07:16:08 -0000 On 04/10/2011 07:23 AM, Somebody in the thread at some point said: > On Sun, Apr 10, 2011 at 07:49:48AM +1000, Greg Wilkins wrote: >> Currently the jetty server has a configurable buffer size. If a frame >> arrives that is larger than the buffer size, we close the connection >> with a message too large status code. libwebsockets takes the approach the user code can decide the policy and does no aggregation buffering. It passes up every packet in a frame as it comes and the user code can see if it is the last (FIN) one. That way the user code can choose to have it as it comes or do its own aggregation buffering, but either way the library is being as lightweight as possible. >> This suggests to me that we should be able to declare the maximal >> frame size we are prepared to handle, so that a client does not need >> to guess, reduce, guess, reduce - or just pick a low value. > > Indeed. Announcing that makes a lot of sense and is comparable to what > TCP does with MSS. Both the client and the server should announce what A better way to come at it is just define a sane maximum frame size in the protocol, say 64Kbytes, and require that the worst case is supported, rather than add more control messages and code and stuff to go wrong. I guess 63-bit length started off as being message size, got refined into the FIN scheme and until now did not get reassessed for still being useful for frame length job it finds itself changed to. There's another limit which is maximum message size that the client is willing to cope with. It's probably more useful to tell that in headers if telling anything. -Andy From w@1wt.eu Sun Apr 10 00:56:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05143A69DB for ; Sun, 10 Apr 2011 00:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.975, 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 7NRBUjZsyPul for ; Sun, 10 Apr 2011 00:56:42 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 159EE3A684D for ; Sun, 10 Apr 2011 00:56:41 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3A7wNpQ020489; Sun, 10 Apr 2011 09:58:23 +0200 Date: Sun, 10 Apr 2011 09:58:23 +0200 From: Willy Tarreau To: Andy Green Message-ID: <20110410075823.GJ15894@1wt.eu> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA15996.9010901@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 07:56:43 -0000 Hi Andy, On Sun, Apr 10, 2011 at 08:17:42AM +0100, Andy Green wrote: > >Indeed. Announcing that makes a lot of sense and is comparable to what > >TCP does with MSS. Both the client and the server should announce what > > A better way to come at it is just define a sane maximum frame size in > the protocol, say 64Kbytes, and require that the worst case is > supported, We'll never be able to settle on a one-size-fits-all, because many people have different requirements. 64k is already too large for large MUXes which will have to deal with 1 million concurrent connections, that's 64GB of buffers in each direction ! And this week I've been in touch with someone trying to size a system for 3 million connections. In contrast, a 64k limit prevents any server from efficiently making use of sendfile(). > rather than add more control messages and code and stuff to > go wrong. I'm not speaking about something complicated. It basically means "For your convenience, I have allocated a receive buffer of XXX bytes, feel free to send frames that large if you want, or feel free to ignore this message and keep the default value instead". > I guess 63-bit length started off as being message size, got > refined into the FIN scheme and until now did not get reassessed for > still being useful for frame length job it finds itself changed to. IIRC, the 63-bit came from the requirement by some to support more than 32-bit in one sendfile(). > There's another limit which is maximum message size that the client is > willing to cope with. It's probably more useful to tell that in headers > if telling anything. The problem with headers is that the more info we put there, the harder it will be to support WS on a dedicated port. There was a very good proposal here on the list by someone I forgot the name, who suggested to support a preamble header in each direction in order to save one RTT. This preamble could very well contain the control frames which indicate the max frame and message sizes each side can cope with. Willy From andy.warmcat.com@googlemail.com Sun Apr 10 01:54:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D191B3A693A for ; Sun, 10 Apr 2011 01:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7aBNODLxSis for ; Sun, 10 Apr 2011 01:54:40 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D7B593A684D for ; Sun, 10 Apr 2011 01:54:39 -0700 (PDT) Received: by wwa36 with SMTP id 36so3921011wwa.13 for ; Sun, 10 Apr 2011 01:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HFX2+BCDSn+nOFnSUaT9/wKm2in/kzhnTgxRVhsiR2M=; b=KqkJHKKYY9+RYKlIm8ZRk15zUVq5T4W2bpZSfbPO+gVKGmPw8jTuDF7Ujlb00MRYRc d5XZfWrTTLCIt4F4UtMWcuyY54fWxvI4AsKQXkI6g1L0VoBt4JcIirKsmcg7Nu/YCh2R AAFQPt/wGfC5tTxtChOYabWiqc8RQSc34S8Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rHBsGiUYobBtqv5afYaZCvnQY9DDeyzRsBlqbu+T8GdIOpJgg5LA4OYv+Ot2a1gGak 1YwU6CY0LWPdhFVaN8/2hFFebFYncauDll+jGr6X2HHgsgigKztAORKx0WVWfrdPtdv6 fFmHXFnBeOYD8z1Rsx8HJHzX5vZ3iIC23f3nU= Received: by 10.216.121.208 with SMTP id r58mr1446840weh.61.1302425785231; Sun, 10 Apr 2011 01:56:25 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id ed10sm2686204wbb.66.2011.04.10.01.56.22 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 01:56:23 -0700 (PDT) Sender: Andy Green Message-ID: <4DA170B6.1020503@warmcat.com> Date: Sun, 10 Apr 2011 09:56:22 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Willy Tarreau References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> In-Reply-To: <20110410075823.GJ15894@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 08:54:42 -0000 On 04/10/2011 08:58 AM, Somebody in the thread at some point said: Hi - >> A better way to come at it is just define a sane maximum frame size in >> the protocol, say 64Kbytes, and require that the worst case is >> supported, > > We'll never be able to settle on a one-size-fits-all, because many people > have different requirements. 64k is already too large for large MUXes which > will have to deal with 1 million concurrent connections, that's 64GB of > buffers in each direction ! And this week I've been in touch with someone > trying to size a system for 3 million connections. Is anything stopping a mux rewriting frames with the length of what it has received at any time? The frame length thing seems completely bogus, directly analogous to people attending to packet boundaries in a streamed protocol and the frame length is just as amorphous as coalescing packets or fragmenting them further. Otherwise I do see the point there is an implicit MTU for frames. Anyway in the x-google-mux case there are other flow control arrangements above all this that render simple max frame buffer case not relevant even for 'back of the envelope' calculations as you are doing above. > In contrast, a 64k limit prevents any server from efficiently making use of > sendfile(). I do not understand that at all, maybe I am missing the point. If someone has a big array or file in Javascript and wants to send it as one message, why does he care about frame fragmentation detail? It's directly analogous to packetization one level below. If you mean by "efficiently" that adding a few bytes every 64KByte is inefficient then I think you find the math disagrees with that. >> rather than add more control messages and code and stuff to >> go wrong. > > I'm not speaking about something complicated. It basically means "For your > convenience, I have allocated a receive buffer of XXX bytes, feel free to > send frames that large if you want, or feel free to ignore this message and > keep the default value instead". Intermediaries will need to rewrite this stuff according to the floor() of their buffer arrangements. >> I guess 63-bit length started off as being message size, got >> refined into the FIN scheme and until now did not get reassessed for >> still being useful for frame length job it finds itself changed to. > > IIRC, the 63-bit came from the requirement by some to support more than > 32-bit in one sendfile(). As I say I don't understand the use of sendfile() to demonstrate anything about framing. Message size I can see must consider it but actually there is no limit about message size in the protocol. It sounds like you're saying TCP/IP must allow 63-bit length packets because otherwise it's 'not efficient' to send large files. >> There's another limit which is maximum message size that the client is >> willing to cope with. It's probably more useful to tell that in headers >> if telling anything. > > The problem with headers is that the more info we put there, the harder it > will be to support WS on a dedicated port. There was a very good proposal > here on the list by someone I forgot the name, who suggested to support a > preamble header in each direction in order to save one RTT. This preamble > could very well contain the control frames which indicate the max frame > and message sizes each side can cope with. Maybe I am just stupid today (or every day) but that logic makes no sense either. Today the protocol mandates http header based startup and I didn't understand why putting the same stuff in binary frames is better. That idea certainly isn't matured to the point that we use it to argue against other things just because it conflicts. -Andy From w@1wt.eu Sun Apr 10 02:22:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9943D3A69EB for ; Sun, 10 Apr 2011 02:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.007 X-Spam-Level: X-Spam-Status: No, score=-3.007 tagged_above=-999 required=5 tests=[AWL=-0.964, 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 GeYhlYNJf04C for ; Sun, 10 Apr 2011 02:22:03 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 77BAA3A693A for ; Sun, 10 Apr 2011 02:22:01 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3A9NjvG020653; Sun, 10 Apr 2011 11:23:45 +0200 Date: Sun, 10 Apr 2011 11:23:45 +0200 From: Willy Tarreau To: Andy Green Message-ID: <20110410092345.GK15894@1wt.eu> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA170B6.1020503@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 09:22:03 -0000 On Sun, Apr 10, 2011 at 09:56:22AM +0100, Andy Green wrote: > >We'll never be able to settle on a one-size-fits-all, because many people > >have different requirements. 64k is already too large for large MUXes which > >will have to deal with 1 million concurrent connections, that's 64GB of > >buffers in each direction ! And this week I've been in touch with someone > >trying to size a system for 3 million connections. > > Is anything stopping a mux rewriting frames with the length of what it > has received at any time? Probably not, you might be right. > The frame length thing seems completely bogus, directly analogous to people > attending to packet boundaries in a streamed protocol and the frame length > is just as amorphous as coalescing packets or fragmenting them further. I disagree on this point. In order to support multiplexing, we need frame length. And even on a single stream it makes sense when you send compressed data and don't know the length in advance. It's akin to a chunk size in HTTP. > >In contrast, a 64k limit prevents any server from efficiently making use of > >sendfile(). > > I do not understand that at all, maybe I am missing the point. If > someone has a big array or file in Javascript and wants to send it as > one message, why does he care about frame fragmentation detail? It's > directly analogous to packetization one level below. If you mean by > "efficiently" that adding a few bytes every 64KByte is inefficient then > I think you find the math disagrees with that. No I don't mean that. I mean that having an application wake up every 64kB to call sendfile() to send the next chunk is expensive. That's basically 20k wakeups+sendfile() calls per second at 10 Gbps while the application could get rid of this when it sends, say, a video from disk. (...) > >The problem with headers is that the more info we put there, the harder it > >will be to support WS on a dedicated port. There was a very good proposal > >here on the list by someone I forgot the name, who suggested to support a > >preamble header in each direction in order to save one RTT. This preamble > >could very well contain the control frames which indicate the max frame > >and message sizes each side can cope with. > > Maybe I am just stupid today (or every day) but that logic makes no > sense either. Today the protocol mandates http header based startup and > I didn't understand why putting the same stuff in binary frames is > better. Right now we have two things : - an HTTP Upgrade handshake - a bidirectional WS stream There will be some situations where the HTTP Upgrade will not be needed nor desirable. WS over TCP on a dedicated port will not rely on Upgrade. Similarly when we can make use of TLS NPN, we'll be able to talk WS over TLS. The more WS-specific info we put in HTTP headers, the more we'll have to find a different way to transport when switching to a different transport protocol. As long as we can have the WS stream independant of the HTTP hanshake, it'll be easier to provide alternative transport schemes and get rid of the masking. Therefore, I think we should be very careful not to put WS-specific information into the HTTP handshake, and instead make provisions in the WS protocol to carry these information. Regards, Willy From andy.warmcat.com@googlemail.com Sun Apr 10 02:54:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7F43A693A for ; Sun, 10 Apr 2011 02:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAWbTRIbHVBE for ; Sun, 10 Apr 2011 02:54:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id ED2D13A68AA for ; Sun, 10 Apr 2011 02:54:38 -0700 (PDT) Received: by wyb29 with SMTP id 29so4503457wyb.31 for ; Sun, 10 Apr 2011 02:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p3BZLiPIH6JwloFG3RTR9hSXsyQpo0yJDd6t6k79U/g=; b=vo8FVb31Ul0CTm3OhwW603LX2xEP2hh517dGkjQny0J2QIWucsJDdQofopophHCW0L 7BHQyQIl7+gVd6r/Uy2mPSrZIVwqr2QMMtdsO04xeOAh8ZMitwYuxsxHAoTU5vVdP694 LML9BRrDsudma+M4bQvQ2bmBaiZPGpINyPT4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MVpVCZ3CiBbtztghQaa4BWMBBaCWx7TX8QRZoUx+Zsc7cEp4O2LDA2WiNsp/X6YloQ 2WY56+okn2mId6XpwR/QVx1bqmysxDaliIakc00iOss1ANUvt4QvUbSt25b8d7OMN4mE rXQzktI+ox11719UOmFl3LuB5MrOyzI2VqA8w= Received: by 10.227.138.220 with SMTP id b28mr4046244wbu.87.1302429384838; Sun, 10 Apr 2011 02:56:24 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id ed10sm2710210wbb.66.2011.04.10.02.56.23 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 02:56:23 -0700 (PDT) Sender: Andy Green Message-ID: <4DA17EC6.8080503@warmcat.com> Date: Sun, 10 Apr 2011 10:56:22 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Willy Tarreau References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> In-Reply-To: <20110410092345.GK15894@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 09:54:41 -0000 On 04/10/2011 10:23 AM, Somebody in the thread at some point said: > On Sun, Apr 10, 2011 at 09:56:22AM +0100, Andy Green wrote: >>> We'll never be able to settle on a one-size-fits-all, because many people >>> have different requirements. 64k is already too large for large MUXes which >>> will have to deal with 1 million concurrent connections, that's 64GB of >>> buffers in each direction ! And this week I've been in touch with someone >>> trying to size a system for 3 million connections. >> >> Is anything stopping a mux rewriting frames with the length of what it >> has received at any time? > > Probably not, you might be right. > >> The frame length thing seems completely bogus, directly analogous to people >> attending to packet boundaries in a streamed protocol and the frame length >> is just as amorphous as coalescing packets or fragmenting them further. > > I disagree on this point. In order to support multiplexing, we need frame > length. And even on a single stream it makes sense when you send compressed > data and don't know the length in advance. It's akin to a chunk size in HTTP. I'm not suggesting getting rid of frame length, just understanding it's about as meaningful as TCP/IP packet length. We have to track it but it's otherwise meaningless and we have to actively write code to not care about it. Anyway to support muxing you do not need any frame length actually, it could be done totally blind to the semantic content of what it is muxing with arbitrary mux-decided packetization of the subchannel content. In x-google-mux it does require to parse the protocol it is carrying to determine length of the content, it doesn't manage it at the mux layer. That trades architectural simplicity for saving a few bytes per mux block. >>> In contrast, a 64k limit prevents any server from efficiently making use of >>> sendfile(). >> >> I do not understand that at all, maybe I am missing the point. If >> someone has a big array or file in Javascript and wants to send it as >> one message, why does he care about frame fragmentation detail? It's >> directly analogous to packetization one level below. If you mean by >> "efficiently" that adding a few bytes every 64KByte is inefficient then >> I think you find the math disagrees with that. > > No I don't mean that. I mean that having an application wake up every > 64kB to call sendfile() to send the next chunk is expensive. That's > basically 20k wakeups+sendfile() calls per second at 10 Gbps while > the application could get rid of this when it sends, say, a video from > disk. Hum. I think that ship has sailed, we must fragment into smaller frames to allow control frames to be seen and responded to with reasonable latency. In the mux case you're talking about above, the mux layer is going to be all over everything like a rash having to prepend mux magic to packets and so on, you can forget about some optimized single channel blasting 10Gps of video with 99% idle CPU. Whatever you do, sendfile to a local socket read by the mux layer, the mux layer must be doing the waking up per subframe and dealing with mux overhead anyway so you didn't get away from it. > Right now we have two things : > - an HTTP Upgrade handshake > - a bidirectional WS stream > > There will be some situations where the HTTP Upgrade will not be needed > nor desirable. WS over TCP on a dedicated port will not rely on Upgrade. > Similarly when we can make use of TLS NPN, we'll be able to talk WS over > TLS. The more WS-specific info we put in HTTP headers, the more we'll > have to find a different way to transport when switching to a different > transport protocol. As long as we can have the WS stream independant of > the HTTP hanshake, it'll be easier to provide alternative transport > schemes and get rid of the masking. > > Therefore, I think we should be very careful not to put WS-specific > information into the HTTP handshake, and instead make provisions in > the WS protocol to carry these information. It's a different argument about a different protocol really. Obviously we are putting "WS-specific information in the HTTP handshake" and that is how it is specified, the time to be "very careful" to not do that has gone. -Andy From zt.tmzt@gmail.com Sun Apr 10 03:32:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435E63A68E1 for ; Sun, 10 Apr 2011 03:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArKSKexRcNWW for ; Sun, 10 Apr 2011 03:32:20 -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 2D76E3A68AA for ; Sun, 10 Apr 2011 03:32:20 -0700 (PDT) Received: by vws12 with SMTP id 12so4446821vws.31 for ; Sun, 10 Apr 2011 03:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8oYlURoUDmEfe2feGQoNjdb0LosQC0vYUbbR4bczJGU=; b=mXIlK62Dpd0r12rvWWwB9JkiDRvqUszyG4kAfYSnHf2D3vdAbuJN2sPC0ghw7g4eEv URwHIBGH3AqQi99J8zI9ZA3yM+YD2TDMjiT3PonIFzSce7AX3OIBA5Tdtfrdr1HqwD+c fOKpGInpA+EFDDMOMXE09KDyxX8ghB8wVBmrM= 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=L4JcIyl9K7+pi8UGoMW+LbCf4vQTA80PamRcpNIm/heXWELrSOhSxyK6E4tGg7YQsJ E8ZhLMoCZCy19q9zPqqPdDZ4gRs2bfQk5Znwq2Q0ybdltHa9fkXy9pHp/yvz/IVzU80V bJPewSfH1C12JXa32eOudx5T/cEXJOpO920Hc= MIME-Version: 1.0 Received: by 10.52.172.5 with SMTP id ay5mr5818065vdc.155.1302431646250; Sun, 10 Apr 2011 03:34:06 -0700 (PDT) Received: by 10.220.201.3 with HTTP; Sun, 10 Apr 2011 03:34:06 -0700 (PDT) Received: by 10.220.201.3 with HTTP; Sun, 10 Apr 2011 03:34:06 -0700 (PDT) In-Reply-To: <4DA17EC6.8080503@warmcat.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.com> Date: Sun, 10 Apr 2011 06:34:06 -0400 Message-ID: From: "zt.tmzt@gmail.com" To: Andy Green Content-Type: multipart/alternative; boundary=bcaec53f971f9e788504a08dffad Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 10:32:22 -0000 --bcaec53f971f9e788504a08dffad Content-Type: text/plain; charset=ISO-8859-1 On Apr 10, 2011 5:56 AM, "Andy Green" wrote: > > On 04/10/2011 10:23 AM, Somebody in the thread at some point said: >> >> On Sun, Apr 10, 2011 at 09:56:22AM +0100, Andy Green wrote: >>>> >>>> We'll never be able to settle on a one-size-fits-all, because many people >>>> have different requirements. 64k is already too large for large MUXes which >>>> will have to deal with 1 million concurrent connections, that's 64GB of >>>> buffers in each direction ! And this week I've been in touch with someone >>>> trying to size a system for 3 million connections. >>> >>> >>> Is anything stopping a mux rewriting frames with the length of what it >>> has received at any time? >> >> >> Probably not, you might be right. >> >>> The frame length thing seems completely bogus, directly analogous to people >>> attending to packet boundaries in a streamed protocol and the frame length >>> is just as amorphous as coalescing packets or fragmenting them further. >> >> >> I disagree on this point. In order to support multiplexing, we need frame >> length. And even on a single stream it makes sense when you send compressed >> data and don't know the length in advance. It's akin to a chunk size in HTTP. > > > I'm not suggesting getting rid of frame length, just understanding it's about as meaningful as TCP/IP packet length. We have to track it but it's otherwise meaningless and we have to actively write code to not care about it. > > Anyway to support muxing you do not need any frame length actually, it could be done totally blind to the semantic content of what it is muxing with arbitrary mux-decided packetization of the subchannel content. > > In x-google-mux it does require to parse the protocol it is carrying to determine length of the content, it doesn't manage it at the mux layer. That trades architectural simplicity for saving a few bytes per mux block. > > >>>> In contrast, a 64k limit prevents any server from efficiently making use of >>>> sendfile(). >>> >>> >>> I do not understand that at all, maybe I am missing the point. If >>> someone has a big array or file in Javascript and wants to send it as >>> one message, why does he care about frame fragmentation detail? It's >>> directly analogous to packetization one level below. If you mean by >>> "efficiently" that adding a few bytes every 64KByte is inefficient then >>> I think you find the math disagrees with that. >> >> >> No I don't mean that. I mean that having an application wake up every >> 64kB to call sendfile() to send the next chunk is expensive. That's >> basically 20k wakeups+sendfile() calls per second at 10 Gbps while >> the application could get rid of this when it sends, say, a video from >> disk. > > > Hum. I think that ship has sailed, we must fragment into smaller frames to allow control frames to be seen and responded to with reasonable latency. > > In the mux case you're talking about above, the mux layer is going to be all over everything like a rash having to prepend mux magic to packets and so on, you can forget about some optimized single channel blasting 10Gps of video with 99% idle CPU. Whatever you do, sendfile to a local socket read by the mux layer, the mux layer must be doing the waking up per subframe and dealing with mux overhead anyway so you didn't get away from it. > > >> Right now we have two things : >> - an HTTP Upgrade handshake >> - a bidirectional WS stream >> >> There will be some situations where the HTTP Upgrade will not be needed >> nor desirable. WS over TCP on a dedicated port will not rely on Upgrade. >> Similarly when we can make use of TLS NPN, we'll be able to talk WS over >> TLS. The more WS-specific info we put in HTTP headers, the more we'll >> have to find a different way to transport when switching to a different >> transport protocol. As long as we can have the WS stream independant of >> the HTTP hanshake, it'll be easier to provide alternative transport >> schemes and get rid of the masking. >> >> Therefore, I think we should be very careful not to put WS-specific >> information into the HTTP handshake, and instead make provisions in >> the WS protocol to carry these information. > > > It's a different argument about a different protocol really. Obviously we are putting "WS-specific information in the HTTP handshake" and that is how it is specified, the time to be "very careful" to not do that has gone. > > -Andy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi I'm a little confused on this thread. There is a 1kb minimum frame size? That makes no sense for a chat client or other basic use of WS in the browser. As for video, even if WS was the appropriate transport, the video is likely to be a TS stream which can packetized as required, or will be converted to TS before being streamed, in which case sendfile is unusuable anyway. I think the WG should consider the prime use case for WS to be browser based real time communication and should not damage the utility of that usage to accommodate other uses. When used in the backend or from dedicated clients the use should resemble a browser client (with or without HTTP initially). Muxing should be seen as a way of efficiently serving browser clients, not as an end unto itself. Thanks, Timothy Meade Real time web developer --bcaec53f971f9e788504a08dffad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 10, 2011 5:56 AM, "Andy Green" <andy@warmcat.com> wrote:
>
> On 04/10/2011 10:23 AM, Somebody in the thread at some point said:
>>
>> On Sun, Apr 10, 2011 at 09:56:22AM +0100, Andy Green wrote:
>>>>
>>>> We'll never be able to settle on a one-size-fits-all, = because many people
>>>> have different requirements. 64k is already too large for = large MUXes which
>>>> will have to deal with 1 million concurrent connections, t= hat's 64GB of
>>>> buffers in each direction ! And this week I've been in= touch with someone
>>>> trying to size a system for 3 million connections.
>>>
>>>
>>> Is anything stopping a mux rewriting frames with the length of= what it
>>> has received at any time?
>>
>>
>> Probably not, you might be right.
>>
>>> The frame length thing seems completely bogus, directly analog= ous to people
>>> attending to packet boundaries in a streamed protocol and the = frame length
>>> is just as amorphous as coalescing packets or fragmenting them= further.
>>
>>
>> I disagree on this point. In order to support multiplexing, we nee= d frame
>> length. And even on a single stream it makes sense when you send c= ompressed
>> data and don't know the length in advance. It's akin to a = chunk size in HTTP.
>
>
> I'm not suggesting getting rid of frame length, just understanding= it's about as meaningful as TCP/IP packet length. =A0We have to track = it but it's otherwise meaningless and we have to actively write code to= not care about it.
>
> Anyway to support muxing you do not need any frame length actually, it= could be done totally blind to the semantic content of what it is muxing w= ith arbitrary mux-decided packetization of the subchannel content.
>
> In x-google-mux it does require to parse the protocol it is carrying t= o determine length of the content, it doesn't manage it at the mux laye= r. =A0That trades architectural simplicity for saving a few bytes per mux b= lock.
>
>
>>>> In contrast, a 64k limit prevents any server from efficien= tly making use of
>>>> sendfile().
>>>
>>>
>>> I do not understand that at all, maybe I am missing the point.= =A0If
>>> someone has a big array or file in Javascript and wants to sen= d it as
>>> one message, why does he care about frame fragmentation detail= ? =A0It's
>>> directly analogous to packetization one level below. =A0If you= mean by
>>> "efficiently" that adding a few bytes every 64KByte = is inefficient then
>>> I think you find the math disagrees with that.
>>
>>
>> No I don't mean that. I mean that having an application wake u= p every
>> 64kB to call sendfile() to send the next chunk is expensive. That&= #39;s
>> basically 20k wakeups+sendfile() calls per second at 10 Gbps while=
>> the application could get rid of this when it sends, say, a video = from
>> disk.
>
>
> Hum. =A0I think that ship has sailed, we must fragment into smaller fr= ames to allow control frames to be seen and responded to with reasonable la= tency.
>
> In the mux case you're talking about above, the mux layer is going= to be all over everything like a rash having to prepend mux magic to packe= ts and so on, you can forget about some optimized single channel blasting 1= 0Gps of video with 99% idle CPU. =A0Whatever you do, sendfile to a local so= cket read by the mux layer, the mux layer must be doing the waking up per s= ubframe and dealing with mux overhead anyway so you didn't get away fro= m it.
>
>
>> Right now we have two things :
>> =A0 - an HTTP Upgrade handshake
>> =A0 - a bidirectional WS stream
>>
>> There will be some situations where the HTTP Upgrade will not be n= eeded
>> nor desirable. WS over TCP on a dedicated port will not rely on Up= grade.
>> Similarly when we can make use of TLS NPN, we'll be able to ta= lk WS over
>> TLS. The more WS-specific info we put in HTTP headers, the more we= 'll
>> have to find a different way to transport when switching to a diff= erent
>> transport protocol. As long as we can have the WS stream independa= nt of
>> the HTTP hanshake, it'll be easier to provide alternative tran= sport
>> schemes and get rid of the masking.
>>
>> Therefore, I think we should be very careful not to put WS-specifi= c
>> information into the HTTP handshake, and instead make provisions i= n
>> the WS protocol to carry these information.
>
>
> It's a different argument about a different protocol really. =A0Ob= viously we are putting "WS-specific information in the HTTP handshake&= quot; and that is how it is specified, the time to be "very careful&qu= ot; to not do that has gone.
>
> -Andy
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.iet= f.org/mailman/listinfo/hybi

I'm a little confused on this thread. There is a 1kb minimum frame s= ize? That makes no sense for a chat client or other basic use of WS in the = browser.

As for video, even if WS was the appropriate transport, the video is lik= ely to be a TS stream which can packetized as required, or will be converte= d to TS before being streamed, in which case sendfile is unusuable anyway.<= /p>

I think the WG should consider the prime use case for WS to be browser b= ased real time communication and should not damage the utility of that usag= e to accommodate other uses. When used in the backend or from dedicated cli= ents the use should resemble a browser client (with or without HTTP initial= ly). Muxing should be seen as a way of efficiently serving browser clients,= not as an end unto itself.

Thanks,
Timothy Meade
Real time web developer

--bcaec53f971f9e788504a08dffad-- From w@1wt.eu Sun Apr 10 04:49:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720A63A69CF for ; Sun, 10 Apr 2011 04:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=-0.953, 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 h4VhToXaNU5S for ; Sun, 10 Apr 2011 04:49:34 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 708A43A6986 for ; Sun, 10 Apr 2011 04:49:33 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3ABpGl3020928; Sun, 10 Apr 2011 13:51:16 +0200 Date: Sun, 10 Apr 2011 13:51:16 +0200 From: Willy Tarreau To: "zt.tmzt@gmail.com" Message-ID: <20110410115116.GL15894@1wt.eu> References: <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.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 , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 11:49:35 -0000 On Sun, Apr 10, 2011 at 06:34:06AM -0400, zt.tmzt@gmail.com wrote: > I'm a little confused on this thread. There is a 1kb minimum frame size? Fortunately not! I was suggesting a minimum size that each end should be able to receive. Right now, if I send you a 4GB frame, are you able to receive it and to process it ? Maybe, maybe not. It may depend on the application. If we start seeing WS agents which arbitrarily decide that they can't support frames larger than XXX, then we'd better provide them a means for announcing that instead of letting the transfer fail. My suggestion was that once we've settled on a way to announce this frame size limit, we should fix the minimum limit that anyone should support (eg: 1 kB). > That makes no sense for a chat client or other basic use of WS in the > browser. Video conferencing certainly is one valid use. Video streaming/playing may also be one if it enables smoother controls from the client (stop/ start/skip/rewind...). > As for video, even if WS was the appropriate transport, the video is likely > to be a TS stream which can packetized as required, or will be converted to > TS before being streamed, in which case sendfile is unusuable anyway. Unless you store the TS stream. Anyway, even if this might not be the best example, there were concerns several months ago about the protocol's efficiency when dealing with large files and sendfile certainly was one this to care about. > I think the WG should consider the prime use case for WS to be browser based > real time communication and should not damage the utility of that usage to > accommodate other uses. I 100% agree with you and I really don't think we're damaging it, quite the opposite. I think you got that feeling because you thought we were suggesting a 1kB-min frame. > When used in the backend or from dedicated clients > the use should resemble a browser client (with or without HTTP initially). > Muxing should be seen as a way of efficiently serving browser clients, not > as an end untoo itself. Muxing has two uses : - better serve clients (eg: support both chat and video conferencing in a single channel) - make servers scale better. Despite how much you find it a pity, many servers nowadays can't process more than one connection per thread. If you want your server to process 1 million concurrent connections, you have to install a mux in front of it so that you run on a few hundreds or thoudands threads and process all the streams there. It will also save them a lot of network traffic by aggregating multiple streams in few TCP segments. Regards, Willy From gezelter@rlgsc.com Sun Apr 10 07:02:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FD73A6A21 for ; Sun, 10 Apr 2011 07:02:08 -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 xXN2vf4AIs-A for ; Sun, 10 Apr 2011 07:02:07 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id 7F0A13A6A2F for ; Sun, 10 Apr 2011 07:02:06 -0700 (PDT) Received: (qmail 9682 invoked from network); 10 Apr 2011 14:03:52 -0000 Received: from unknown (141.157.198.38) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 10 Apr 2011 14:03:51 -0000 Message-ID: <4DA1B8C4.8030007@rlgsc.com> Date: Sun, 10 Apr 2011 09:03:48 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 14:02:08 -0000 As everyone is well aware, I am most definitely of the opinion that multiplexing support is necessary for the WebSocket protocol to succeed in mass use. Reducing the order of the scaling curve requires it. That said, the recent thread "On Fragmentation of Frames" brings up a number of important points. Error handling is one of, if not the most, important features of a protocol. Simply dropping a connection is not an acceptable result in all but the most serious situations. For this reason, maximum frame size should absolutely be negotiated during connection establishment. If a longer frame is sent, the connection may be terminated; however, the termination must include the reason for the termination (e.g., frame of 1000000 received in excess of 65536 negotiated). Simple unexplained drops of connections creates a regression to the "dark ages" of network troubleshooting. Troubleshooting a WebSocket protocol connection should not require a wire-level trace of the underlying TCP link. Maximum frame size affects latency and resource allocation throughout the data path (e.g., transmission times, buffer sizes). I see no reason why intermediaries (e.g., traffic directors) could not re-frame traffic for reasons not apparent to either endpoint. Of course, such an intermediary is responsible for managing both the client and server relationships. Seen from this perspective, IMHO, multiplexing becomes less of a problem. Each subchannel (my term) is created with a specified quota, and the flow within that subchannel is managed using a debit/credit approach. This is fully pipelined, so it need not be a bottleneck provided the quota is appropriate for the connection. This is emphatically not the same as TCP-level flow control. TCP-level flow control is also not a substitute. One can easily imagine a client with 20 different WebSocket protocol connection under the present non- multiplexed specification creating resource problems by attempting to transmit/receive huge volumes of traffic. This approach is also a case of "beggar my neighbor", as it will tie up large numbers of TCP buffers, both at endpoints and intermediaries. TCP buffers, one should note, are often a finite resource, being allocated out of kernel space. One of the comments in this thread spoke of a 3,000,000 connection application, consider the size of the buffer pool to deal with reassembly of IP packets received out of sequence. Lastly, on the subject of sendfile and large transmissions. The simple fact is that the overhead of packetizing is there, regardless of whether sendfile is aware of it or not. Actual calls to sendfile may or may not be needed, but I suggest careful analysis of what will happen when one attempts to send a 4GB file in one piece. There are paging and a range of other issues. As economists often say, "There is no such thing as a free lunch". Having implemented a wide range of device and network interfaces, there are ways to improve the efficiency of such situations. The most time-honored example is some form of command chaining, which was very useful in the IBM System/360 IO architecture for achieving high performance. It also appeared as a way to reportedly read and de-serialize analog seismic data tapes, which were characterized by a lack of inter-record gaps. Similar approaches are used by network controllers and device drivers, to avoid excessive call overhead. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From andy.warmcat.com@googlemail.com Sun Apr 10 10:38:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66C83A6999 for ; Sun, 10 Apr 2011 10:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRgIVvU00FnK for ; Sun, 10 Apr 2011 10:38:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9111B3A6988 for ; Sun, 10 Apr 2011 10:38:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so4669313wyb.31 for ; Sun, 10 Apr 2011 10:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=B4l7BI/NReZ/zMRAGIzDHt/uoJrKj2HLWwqDrhP2Ftc=; b=ci67TuMyqA7nk2U2wIMUV8xJEcc0ggMi1nuG6ou9D3ula8viXhuGi2S/sxSOvywSTZ BFm9g0XH5OHteKfe8Au7go126IQKht6i7xCvRvmND2C+/5m6vLDbxdKPqS8M7No0dmgc 2FJW/hHP+JaKgXFhNI1uDVHyFsI1Qt0B5BOXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NXUbZjEzf4/fDqG7DjdGvVVRJQ0B36y1Ehn4jhVZeX3YWGU7iwwQwJSDT9bNsjlwwV KoRGVacuQa09LLsqpz/NybHDDh+BqDWX9fkO3HrjzHLRlkfZhY6weTt0Sc8Kn2u2LBVk U6rWHHFRcLQXlHx2Gj9Xi6saBbDkeXsFVeo4U= Received: by 10.227.159.77 with SMTP id i13mr3136800wbx.177.1302457119517; Sun, 10 Apr 2011 10:38:39 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id z13sm2900324wbd.63.2011.04.10.10.38.36 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 10:38:37 -0700 (PDT) Sender: Andy Green Message-ID: <4DA1EB1A.5040203@warmcat.com> Date: Sun, 10 Apr 2011 18:38:34 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Willy Tarreau References: <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.com> <20110410115116.GL15894@1wt.eu> In-Reply-To: <20110410115116.GL15894@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 17:38:42 -0000 On 04/10/2011 12:51 PM, Somebody in the thread at some point said: > On Sun, Apr 10, 2011 at 06:34:06AM -0400, zt.tmzt@gmail.com wrote: >> I'm a little confused on this thread. There is a 1kb minimum frame size? > > Fortunately not! I was suggesting a minimum size that each end should > be able to receive. Right now, if I send you a 4GB frame, are you able Yeah, as Willy says you are able to send any size frame you like whose length can fit in 63 bits. But nobody can actually receive that max frame atomically, buffering it all up and passing it on at the end. There's nothing about a 1KByte minimum. > to receive it and to process it ? Maybe, maybe not. It may depend on > the application. If we start seeing WS agents which arbitrarily decide > that they can't support frames larger than XXX, then we'd better provide > them a means for announcing that instead of letting the transfer fail. > My suggestion was that once we've settled on a way to announce this > frame size limit, we should fix the minimum limit that anyone should > support (eg: 1 kB). The alternative is to understand that in websockets clients, only messages matter, the detail of how they're fragmented into frames in unavailable to the client. It's like this Javascript: whole message in one hit when it has all come Websocket: message may be fragmented into as many frames as you like each of whatever size Network: websocket frames may be fragmented into as many packets as you like each of whatever size Nobody is suggesting websocket layer must particularly care about how many packets came of what size at Network layer. Similarly, I don't think we should care about how many frames came of what size at Websocket layer, not treat them espectially atomically more than we have to. >> I think the WG should consider the prime use case for WS to be browser based >> real time communication and should not damage the utility of that usage to >> accommodate other uses. > > I 100% agree with you and I really don't think we're damaging it, quite the > opposite. I think you got that feeling because you thought we were suggesting > a 1kB-min frame. Yeah this is a red herring. Willy and I are just talking about whether it's better to have an explicit frame MTU negotiated like TCP/IP MTU or if it's enough to reduce the max frame size from 2^63 to something saner like 2^16 and demand everyone can support that 64KByte max. Actually we do agree there can be a problem as it stands and someone decides to send 2GByte frame to a client who likes to buffer frames but cuts off at 1MByte, say; basically those guys can't communicate but are compliant. >> When used in the backend or from dedicated clients >> the use should resemble a browser client (with or without HTTP initially). >> Muxing should be seen as a way of efficiently serving browser clients, not >> as an end untoo itself. > > Muxing has two uses : > - better serve clients (eg: support both chat and video conferencing in a > single channel) > > - make servers scale better. Despite how much you find it a pity, many > servers nowadays can't process more than one connection per thread. If > you want your server to process 1 million concurrent connections, you > have to install a mux in front of it so that you run on a few hundreds > or thoudands threads and process all the streams there. It will also > save them a lot of network traffic by aggregating multiple streams in > few TCP segments. Right also I can imagine one script on one page might have several widgets or other dynamic content that each want a websocket. Muxing will make a nice solution where all that is one socket if it's the same server and URL serving those websockets. The notification stuff in Javascript will make that script architecture clean and simple. -Andy From andy.warmcat.com@googlemail.com Sun Apr 10 10:59:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3162C3A698B for ; Sun, 10 Apr 2011 10:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXWdiOSnpn9p for ; Sun, 10 Apr 2011 10:59:39 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AB5EF3A6988 for ; Sun, 10 Apr 2011 10:59:38 -0700 (PDT) Received: by wwa36 with SMTP id 36so4083478wwa.13 for ; Sun, 10 Apr 2011 10:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CaOI3T8TQw8bg2X/A+t/hf/8Idpuj4EIgSY/zDhRswk=; b=q2sK+xS2DclKvlQuAdEOCblb8OwZeJ5mVl0mz5bx51NarxRDirqLTfAYlwreT5T4Y1 9S9iOyG0iy1w7fGnrNT2/7Pu4Mi+KhuBuEzM2ujPMM/r0mzGXMNfpogciTCRTqA4yPuI 0F+wwNYaF/kEe0x5z6xT34/IsNKyHaa4E/QbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Rq/QMlg5PWBBqpWsvWqUDiCl8p23sEJs8PC7aKxFXG5bu6IdlrZnKOkJ3mN5jtXlPB kXJyMZB3Z1avfSaq2RuGpkMavJYUpRESNNOYHfoGlnrvB2xtEJljttXNDqTm0upBCrBK Nu1dh0/hbCK2UtzFeFmQMB0VC8GZ0GMJPde2U= Received: by 10.227.178.5 with SMTP id bk5mr4483802wbb.173.1302458377922; Sun, 10 Apr 2011 10:59:37 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id y12sm2909903wby.42.2011.04.10.10.59.34 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 10:59:37 -0700 (PDT) Sender: Andy Green Message-ID: <4DA1F004.9070208@warmcat.com> Date: Sun, 10 Apr 2011 18:59:32 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: gezelter@rlgsc.com References: <4DA1B8C4.8030007@rlgsc.com> In-Reply-To: <4DA1B8C4.8030007@rlgsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 17:59:40 -0000 On 04/10/2011 03:03 PM, Somebody in the thread at some point said: Hi - > As everyone is well aware, I am most definitely of the opinion that > multiplexing support is necessary for the WebSocket protocol to succeed in > mass use. Reducing the order of the scaling curve requires it. AFAIK everyone agrees with that. But practically we need to do it in two steps since there is surely going to be a lot of discussion about mux and plain websockets is needed right away. FWIW the plan is mux will be an extension to the current plain standard without changing it, and the subchannels are to use the plain standard protocols inside. So it has a reasonable story that doing it in two pieces won't be a disaster. > That said, the recent thread "On Fragmentation of Frames" brings up a > number > of important points. > > Error handling is one of, if not the most, important features of a > protocol. > Simply dropping a connection is not an acceptable result in all but the > most > serious situations. For this reason, maximum frame size should > absolutely be > negotiated during connection establishment. If a longer frame is sent, the > connection may be terminated; however, the termination must include the > reason for the termination (e.g., frame of 1000000 received in excess of > 65536 negotiated). Simple unexplained drops of connections creates a > regression to the "dark ages" of network troubleshooting. Troubleshooting > a WebSocket protocol connection should not require a wire-level trace of > the underlying TCP link. I would suggest focus on frame size isn't really important in websockets. As I understand it, super-big frames are in fact useless since if you want to send a 1MByte frame as in your example, you could as easily have sent it on the wire as 16 x 64KByte frames and the client can't tell the difference. If control frames were coming inbetweentime, they would also arrive with less latency. Considering someone is allowed to block the wire for 2^63 size frame, that's unreasonable from control frame latency POV so why is it allowed? Also, messages are defined to be atomic for the Javascript case, you have to sit and buffer all frame content until one comes with FIN, then you can pass it all up as one action. But for frames, there is no requirement in the standard about their needing to be buffered and managed as full frames. In fact the state machine that handles packets can pass up chunks of frames to the upper layer without aggregating the packets into a full frame. So I don't see any reason to introduce a frame MTU concept since frames themselves are not being reassembled. It does make sense to not allow the protocol to talk about antisocial or deadly (given they will block the wire beyond ping-pong keepalive limits) frame lengths. > Seen from this perspective, IMHO, multiplexing becomes less of a problem. > Each subchannel (my term) is created with a specified quota, and the flow > within that subchannel is managed using a debit/credit approach. This is > fully pipelined, so it need not be a bottleneck provided the quota is > appropriate for the connection. Well, notice first that the frame issue is not bound to mux usage, it is an issue in non-muxed connections the same. Otherwise, yeah that is the approach of x-google-mux from John Tamplin. > This is emphatically not the same as TCP-level flow control. TCP-level > flow control is also not a substitute. One can easily imagine a client > with 20 different WebSocket protocol connection under the present non- > multiplexed specification creating resource problems by attempting to > transmit/receive huge volumes of traffic. This approach is also a case > of "beggar my neighbor", as it will tie up large numbers of TCP buffers, > both at endpoints and intermediaries. TCP buffers, one should note, are > often a finite resource, being allocated out of kernel space. One of the > comments in this thread spoke of a 3,000,000 connection application, > consider the size of the buffer pool to deal with reassembly of IP packets > received out of sequence. Well, 3M connections is not a problem on my plate, if it was I would be solving it in a scalable way with a bunch of cheap servers. I think mux implementation is coming really quite soon due to the pressures you are talking about. But politically, websockets needs to lay a 1.0 egg, despite it's not technical that isn't a consideration that can be ignored. > Lastly, on the subject of sendfile and large transmissions. The simple > fact is that the overhead of packetizing is there, regardless of > whether sendfile is aware of it or not. Actual calls to sendfile may > or may not be needed, but I suggest careful analysis of what will > happen when one attempts to send a 4GB file in one piece. There are Well AFAIK there are tricks like mmap the file and then the kernel side is taking care of everything. It's still paddling hard under the water, right. But as I said if we consider the muxing action, sendfile is pointless to think about since the payload is going to be chunked up in mux blocks with their ownoverhead on the wire that must be added too. And sendfile was the only reason for allowing supersized frame lengths at all. -Andy From zt.tmzt@gmail.com Sun Apr 10 11:37:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D1B3A698B for ; Sun, 10 Apr 2011 11:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbnMc+f49WNN for ; Sun, 10 Apr 2011 11:37:19 -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 CE1853A6943 for ; Sun, 10 Apr 2011 11:37:18 -0700 (PDT) Received: by vws12 with SMTP id 12so4614164vws.31 for ; Sun, 10 Apr 2011 11:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WpB2L8F44V20pVuhn+F1zN5CTQ8Hbr+EwdvUVXE2GuQ=; b=bFmH5ooYai0ePh2S1ISw0EkNLUIhlnS3Daco61xJX4ZKaxC0frT1vF/JaKkvz8B5EI GTJbKl+8OI163Co6mZdRH15lhQSGUU/fp0PiH/jD4b+Hb6j1Sc9ihXE6rA9rO6TipJao yoxy4psXXRitijhgEXyRmoJTTHKI1NKDKJYRs= 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=tujCzIcvRr1/9z4LusmH8WoFe12XqY+OgddtNu0YoA4io9J6RI38j/5RwgXKLruxzF nueSZ2CWaHAdvI3QL3qgWV0hAzB7TQ3jXLBngxzN1lTj82NCS/u/Yi9kx3tlIe13ohhV /u04E8S/b8TOmJJXAdouLR6tB5W5GUE8J28r8= MIME-Version: 1.0 Received: by 10.220.111.194 with SMTP id t2mr1323691vcp.135.1302460637995; Sun, 10 Apr 2011 11:37:17 -0700 (PDT) Received: by 10.220.201.3 with HTTP; Sun, 10 Apr 2011 11:37:17 -0700 (PDT) Received: by 10.220.201.3 with HTTP; Sun, 10 Apr 2011 11:37:17 -0700 (PDT) In-Reply-To: <4DA1EB1A.5040203@warmcat.com> References: <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.com> <20110410115116.GL15894@1wt.eu> <4DA1EB1A.5040203@warmcat.com> Date: Sun, 10 Apr 2011 14:37:17 -0400 Message-ID: From: "zt.tmzt@gmail.com" To: Andy Green Content-Type: multipart/alternative; boundary=0016e64ec130a9627b04a094bf1e Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 18:37:20 -0000 --0016e64ec130a9627b04a094bf1e Content-Type: text/plain; charset=ISO-8859-1 On Apr 10, 2011 1:38 PM, "Andy Green" wrote: > > On 04/10/2011 12:51 PM, Somebody in the thread at some point said: >> >> On Sun, Apr 10, 2011 at 06:34:06AM -0400, zt.tmzt@gmail.com wrote: >>> >>> I'm a little confused on this thread. There is a 1kb minimum frame size? >> >> >> Fortunately not! I was suggesting a minimum size that each end should >> be able to receive. Right now, if I send you a 4GB frame, are you able > > > Yeah, as Willy says you are able to send any size frame you like whose length can fit in 63 bits. But nobody can actually receive that max frame atomically, buffering it all up and passing it on at the end. There's nothing about a 1KByte minimum. > > >> to receive it and to process it ? Maybe, maybe not. It may depend on >> the application. If we start seeing WS agents which arbitrarily decide >> that they can't support frames larger than XXX, then we'd better provide >> them a means for announcing that instead of letting the transfer fail. >> My suggestion was that once we've settled on a way to announce this >> frame size limit, we should fix the minimum limit that anyone should >> support (eg: 1 kB). > > > The alternative is to understand that in websockets clients, only messages matter, the detail of how they're fragmented into frames in unavailable to the client. It's like this > > Javascript: whole message in one hit when it has all come > > Websocket: message may be fragmented into as many frames as you like each of whatever size > > Network: websocket frames may be fragmented into as many packets as you like each of whatever size > > Nobody is suggesting websocket layer must particularly care about how many packets came of what size at Network layer. Similarly, I don't think we should care about how many frames came of what size at Websocket layer, not treat them espectially atomically more than we have to. > > >>> I think the WG should consider the prime use case for WS to be browser based >>> real time communication and should not damage the utility of that usage to >>> accommodate other uses. >> >> >> I 100% agree with you and I really don't think we're damaging it, quite the >> opposite. I think you got that feeling because you thought we were suggesting >> a 1kB-min frame. > > > Yeah this is a red herring. Willy and I are just talking about whether it's better to have an explicit frame MTU negotiated like TCP/IP MTU or if it's enough to reduce the max frame size from 2^63 to something saner like 2^16 and demand everyone can support that 64KByte max. Actually we do agree there can be a problem as it stands and someone decides to send 2GByte frame to a client who likes to buffer frames but cuts off at 1MByte, say; basically those guys can't communicate but are compliant. > Me again, why is the frame size in bytes instead of some other unit (like octets?) > >>> When used in the backend or from dedicated clients >>> the use should resemble a browser client (with or without HTTP initially). >>> Muxing should be seen as a way of efficiently serving browser clients, not >>> as an end untoo itself. >> >> >> Muxing has two uses : >> - better serve clients (eg: support both chat and video conferencing in a >> single channel) >> >> - make servers scale better. Despite how much you find it a pity, many >> servers nowadays can't process more than one connection per thread. If >> you want your server to process 1 million concurrent connections, you >> have to install a mux in front of it so that you run on a few hundreds >> or thoudands threads and process all the streams there. It will also >> save them a lot of network traffic by aggregating multiple streams in >> few TCP segments. > Another case were assumptions can be a problem, evented servers like nginx and node.js exist. It does makes sense to accommodate behind the scenes muxing of course, not saying it doesn't. > > Right also I can imagine one script on one page might have several widgets or other dynamic content that each want a websocket. Muxing will make a nice solution where all that is one socket if it's the same server and URL serving those websockets. The notification stuff in Javascript will make that script architecture clean and simple. Why same url? Are you saying that every script in the page must cooporate on a muxing scheme or require more than one TCP socket? This defeats the scaling and makes little sense in a world with multiple toolkits and widgets in the same page. Having MUXing as an extension is fine, but WS JS API should require such an extension be supported and allow multiple scripts in the same page to subscribe to channels. To not do so would be a regression over pubsub protocols like bayeux. MUXing should make a distinction between browser-server MUXing and utility MUXing performed transparently on the backend. All the discussion seems to be on the latter. > > -Andy Timothy Meade Real time web developer --0016e64ec130a9627b04a094bf1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 10, 2011 1:38 PM, "Andy Green" <andy@warmcat.com> wrote:
>
> On 04/10/2011 12:51 PM, Somebody in the thread at some point said:
>>
>> On Sun, Apr 10, 2011 at 06:34:06AM -0400, zt.tmzt@gmail.com wrote:
>>>
>>> I'm a little confused on this thread. There is a 1kb minim= um frame size?
>>
>>
>> Fortunately not! I was suggesting a minimum size that each end sho= uld
>> be able to receive. Right now, if I send you a 4GB frame, are you = able
>
>
> Yeah, as Willy says you are able to send any size frame you like whose= length can fit in 63 bits. =A0But nobody can actually receive that max fra= me atomically, buffering it all up and passing it on at the end. There'= s nothing about a 1KByte minimum.
>
>
>> to receive it and to process it ? Maybe, maybe not. It may depend = on
>> the application. If we start seeing WS agents which arbitrarily de= cide
>> that they can't support frames larger than XXX, then we'd = better provide
>> them a means for announcing that instead of letting the transfer f= ail.
>> My suggestion was that once we've settled on a way to announce= this
>> frame size limit, we should fix the minimum limit that anyone shou= ld
>> support (eg: 1 kB).
>
>
> The alternative is to understand that in websockets clients, only mess= ages matter, the detail of how they're fragmented into frames in unavai= lable to the client. =A0It's like this
>
> Javascript: =A0whole message in one hit when it has all come
>
> =A0 Websocket: =A0message may be fragmented into as many frames as you= like each of whatever size
>
> =A0 =A0 Network: =A0 websocket frames may be fragmented into as many p= ackets as you like each of whatever size
>
> Nobody is suggesting websocket layer must particularly care about how = many packets came of what size at Network layer. =A0Similarly, I don't = think we should care about how many frames came of what size at Websocket l= ayer, not treat them espectially atomically more than we have to.
>
>
>>> I think the WG should consider the prime use case for WS to be= browser based
>>> real time communication and should not damage the utility of t= hat usage to
>>> accommodate other uses.
>>
>>
>> I 100% agree with you and I really don't think we're damag= ing it, quite the
>> opposite. I think you got that feeling because you thought we were= suggesting
>> a 1kB-min frame.
>
>
> Yeah this is a red herring. =A0Willy and I are just talking about whet= her it's better to have an explicit frame MTU negotiated like TCP/IP MT= U or if it's enough to reduce the max frame size from 2^63 to something= saner like 2^16 and demand everyone can support that 64KByte max. =A0Actua= lly we do agree there can be a problem as it stands and someone decides to = send 2GByte frame to a client who likes to buffer frames but cuts off at 1M= Byte, say; basically those guys can't communicate but are compliant. >

Me again, why is the frame size in bytes instead of some other unit (lik= e octets?)

>
>>> When used in the backend or from dedicated clients
>>> the use should resemble a browser client (with or without HTTP= initially).
>>> Muxing should be seen as a way of efficiently serving browser = clients, not
>>> as an end untoo itself.
>>
>>
>> Muxing has two uses :
>> =A0 - better serve clients (eg: support both chat and video confer= encing in a
>> =A0 =A0 single channel)
>>
>> =A0 - make servers scale better. Despite how much you find it a pi= ty, many
>> =A0 =A0 servers nowadays can't process more than one connectio= n per thread. If
>> =A0 =A0 you want your server to process 1 million concurrent conne= ctions, you
>> =A0 =A0 have to install a mux in front of it so that you run on a = few hundreds
>> =A0 =A0 or thoudands threads and process all the streams there. It= will also
>> =A0 =A0 save them a lot of network traffic by aggregating multiple= streams in
>> =A0 =A0 few TCP segments.
>

Another case were assumptions can be a problem, evented servers like ngi= nx and node.js exist. It does makes sense to accommodate behind the scenes = muxing of course, not saying it doesn't.

>
> Right also I can imagine one script on one page might have several wid= gets or other dynamic content that each want a websocket. =A0Muxing will ma= ke a nice solution where all that is one socket if it's the same server= and URL serving those websockets. =A0The notification stuff in Javascript = will make that script architecture clean and simple.

Why same url? Are you saying that every script in the page must cooporat= e on a muxing scheme or require more than one TCP socket? This defeats the = scaling and makes little sense in a world with multiple toolkits and widget= s in the same page. Having MUXing as an extension is fine, but WS JS API sh= ould require such an extension be supported and allow multiple scripts in t= he same page to subscribe to channels. To not do so would be a regression o= ver pubsub protocols like bayeux.

MUXing should make a distinction between browser-server MUXing and utili= ty MUXing performed transparently on the backend. All the discussion seems = to be on the latter.

>
> -Andy

Timothy Meade
Real time web developer

--0016e64ec130a9627b04a094bf1e-- From zt.tmzt@gmail.com Sun Apr 10 11:40:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711313A69AD for ; Sun, 10 Apr 2011 11:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZRCg4oB5GhB for ; Sun, 10 Apr 2011 11:40:22 -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 C22D23A698B for ; Sun, 10 Apr 2011 11:40:21 -0700 (PDT) Received: by vws12 with SMTP id 12so4615438vws.31 for ; Sun, 10 Apr 2011 11:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qY/ZjYxmQ3Vv6V9MHqd5vQhE8e5EuOQxl45f/A206UU=; b=YUeltNKJjRBDxOKmevWsrkpcKCcwyRsv7zc5feK0Jlz6AzECWGf6YhrcVmZBnuxRHd TPwc+P7v3LNu+pbXqNF4mhR8ydZgkJKkTqyxND41A0Fd5VlzB/1vbUUoalMYv7x5/ifq Ceu5n6d+apsjKNGAbWoo3cujnx1K7gvpfNAmY= 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=LFeqogYLhKF7na0P9KJpJ6OEmVb8eMX058aaFxMWryxFvBAwytUGCaUcQSa8GZ5MTb MVwv9ei8rlv30F60DTM79LMvKrCUTtpDxuPyESoisuHX9PJQieNYDLnYXXfNkjeh48sK X/zVbnGOCC+gi+x3VuYNhCaEYJ8L3WDCPNhPg= MIME-Version: 1.0 Received: by 10.220.117.144 with SMTP id r16mr1335029vcq.65.1302460821301; Sun, 10 Apr 2011 11:40:21 -0700 (PDT) Received: by 10.220.201.3 with HTTP; Sun, 10 Apr 2011 11:40:21 -0700 (PDT) Received: by 10.220.201.3 with HTTP; Sun, 10 Apr 2011 11:40:21 -0700 (PDT) In-Reply-To: References: <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.com> <20110410115116.GL15894@1wt.eu> <4DA1EB1A.5040203@warmcat.com> Date: Sun, 10 Apr 2011 14:40:21 -0400 Message-ID: From: "zt.tmzt@gmail.com" To: Andy Green Content-Type: multipart/alternative; boundary=485b39618844966bea04a094ca27 Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 18:40:22 -0000 --485b39618844966bea04a094ca27 Content-Type: text/plain; charset=ISO-8859-1 Sorry, not octets but 8 or 16 byte groups --485b39618844966bea04a094ca27 Content-Type: text/html; charset=ISO-8859-1

Sorry, not octets but 8 or 16 byte groups

--485b39618844966bea04a094ca27-- From jat@google.com Sun Apr 10 11:46:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE363A6937 for ; Sun, 10 Apr 2011 11:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.854 X-Spam-Level: X-Spam-Status: No, score=-105.854 tagged_above=-999 required=5 tests=[AWL=0.122, 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 n7tu8pdHUWXb for ; Sun, 10 Apr 2011 11:46:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0829E3A6876 for ; Sun, 10 Apr 2011 11:46:02 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p3AIk1Ni009068 for ; Sun, 10 Apr 2011 11:46:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302461161; bh=4bxtUtStGoVq+oyYvzqMDd4+iA4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pfmWZkJKrtx4O5jBKPLGn5cO4UNFlmOA2Xj6a8UGHYfy9jpAZbthPdT5dTSPzmj1C fOHEN+dvJ3hDmXmbdXmeA== Received: from yxp4 (yxp4.prod.google.com [10.190.4.196]) by kpbe19.cbf.corp.google.com with ESMTP id p3AIjxFl015415 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 10 Apr 2011 11:45:59 -0700 Received: by yxp4 with SMTP id 4so1781138yxp.10 for ; Sun, 10 Apr 2011 11:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hkt/29qcOanoFrJPCydVzLv9MXG+o9r9HyHpIF7j2o8=; b=a30PHtK7Ag7DKfASpNo+nCeg21nguU84L7x4l6aPyvu6A72AVTr27HNff1QftOIpqo TYpLZTBbYEXp7EuCEQYA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=TpCZ+9hDWb1ViVAN6pKkHlqE5bS7oGzRZQQ39ibXsqwW+4qDgACb4qkmEcu2GzG4Ul OE53HgD6tm4NKjWWvKAg== Received: by 10.150.170.19 with SMTP id s19mr3815615ybe.67.1302461159169; Sun, 10 Apr 2011 11:45:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Sun, 10 Apr 2011 11:45:39 -0700 (PDT) In-Reply-To: References: <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.com> <20110410115116.GL15894@1wt.eu> <4DA1EB1A.5040203@warmcat.com> From: John Tamplin Date: Sun, 10 Apr 2011 14:45:39 -0400 Message-ID: To: "zt.tmzt@gmail.com" Content-Type: multipart/alternative; boundary=000e0cd4cc3cb9dd9a04a094de24 X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 18:46:04 -0000 --000e0cd4cc3cb9dd9a04a094de24 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 10, 2011 at 2:37 PM, zt.tmzt@gmail.com wrote: > Why same url? Are you saying that every script in the page must cooporate > on a muxing scheme or require more than one TCP socket? This defeats the > scaling and makes little sense in a world with multiple toolkits and widgets > in the same page. Having MUXing as an extension is fine, but WS JS API > should require such an extension be supported and allow multiple scripts in > the same page to subscribe to channels. To not do so would be a regression > over pubsub protocols like bayeux. > > MUXing should make a distinction between browser-server MUXing and utility > MUXing performed transparently on the backend. All the discussion seems to > be on the latter. > The idea would be that the JS API is totally unchanged for MUX. If there are multiple connections to the same server URL, the browser would transparently MUX them if the server accepted the MUX extension on the first connection. The server has to be the same in order to safely combine the logical channels into one physical channel. Requiring an extension to be supported is equivalent to bundling it into the base specification, and when we first discussed multiplexing it was left out of the base spec because we could not get everyone to agree. Also, some simple servers don't care about scalability and those shouldn't have to deal with the complexity. If all the user agents support MUX, then the servers that care about scalability will implement it and everything is fine, so I am not sure I see the value in making MUX support required. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4cc3cb9dd9a04a094de24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 10, 2011 at 2:37 PM, zt.tmzt@gmail.com <zt.tmzt@gmail.com> wrote:

Why same url? Are you saying that ever= y script in the page must cooporate on a muxing scheme or require more than= one TCP socket? This defeats the scaling and makes little sense in a world= with multiple toolkits and widgets in the same page. Having MUXing as an e= xtension is fine, but WS JS API should require such an extension be support= ed and allow multiple scripts in the same page to subscribe to channels. To= not do so would be a regression over pubsub protocols like bayeux.

MUXing should make a distinction between browser-server MUXing and utili= ty MUXing performed transparently on the backend. All the discussion seems = to be on the latter.

The idea would be that the = JS API is totally unchanged for MUX. =C2=A0If there are multiple connection= s to the same server URL, the browser would transparently MUX them if the s= erver accepted the MUX extension on the first connection. =C2=A0The server = has to be the same in order to safely combine the logical channels into one= physical channel.

Requiring an extension to be supported is equivalent to= bundling it into the base specification, and when we first discussed multi= plexing it was left out of the base spec because we could not get everyone = to agree. =C2=A0Also, some simple servers don't care about scalability = and those shouldn't have to deal with the complexity. =C2=A0If all the = user agents support MUX, then the servers that care about scalability will = implement it and everything is fine, so I am not sure I see the value in ma= king MUX support required.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd4cc3cb9dd9a04a094de24-- From andy.warmcat.com@googlemail.com Sun Apr 10 11:51:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067D63A6961 for ; Sun, 10 Apr 2011 11:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJWGmffIBUSV for ; Sun, 10 Apr 2011 11:51:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DFF583A6953 for ; Sun, 10 Apr 2011 11:51:27 -0700 (PDT) Received: by wwa36 with SMTP id 36so4101133wwa.13 for ; Sun, 10 Apr 2011 11:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6WtK2ux8xH53oOgPtgmMdGxVx7zN+uKPJwNaNhGWhW8=; b=Dy6c0ozX5xnnBcdxNVy81o3GMhIHGrBLEs3vr8HKQotuiCgOCC1wfNI3WcuXRJqu0h L7rbVd/VBS/Phle0tIBFFpFrn202SyHtXMsqc1TNpMlR51U2b1e0ZuIINrN/nNOtvirB lmcFfOzjDqx6f7xoedAYt+K6oJ8GmcF1NBGwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=M/sHJgpBqBFzs4iVMMcYVKTY/UhEMJ0Ckkam6A/gzcbGfkUQ6iaK/9vVuhMD1vTItQ v5S7hm/rGacmVVtbDDDMERZYsFHjHm8l9G+SvM3ofyk84mUdwkIF70VbAs/GkTydNZi3 7zibH3Oj5yHkfXw2HXG7y1TdVekWE+UX9bsiQ= Received: by 10.227.0.88 with SMTP id 24mr4499650wba.123.1302461486965; Sun, 10 Apr 2011 11:51:26 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id h11sm2932839wbc.60.2011.04.10.11.51.25 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 11:51:25 -0700 (PDT) Sender: Andy Green Message-ID: <4DA1FC2C.5050201@warmcat.com> Date: Sun, 10 Apr 2011 19:51:24 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: "zt.tmzt@gmail.com" References: <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <20110410075823.GJ15894@1wt.eu> <4DA170B6.1020503@warmcat.com> <20110410092345.GK15894@1wt.eu> <4DA17EC6.8080503@warmcat.com> <20110410115116.GL15894@1wt.eu> <4DA1EB1A.5040203@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 18:51:29 -0000 On 04/10/2011 07:40 PM, Somebody in the thread at some point said: > Sorry, not octets but 8 or 16 byte groups No idea where "8 or 16 byte groups" is coming from. The protocol counts bytes, it's byte oriented, so I talk about bytes. I guess I am too young or lucky to ever work on anything other than an 8-bit byte, so I don't use 'octet' much either. -Andy From gregw@intalio.com Sun Apr 10 15:04:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006513A69CC for ; Sun, 10 Apr 2011 15:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzJvGxCl5NRK for ; Sun, 10 Apr 2011 15:04:39 -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 2C50D3A69C6 for ; Sun, 10 Apr 2011 15:04:39 -0700 (PDT) Received: by qwc23 with SMTP id 23so3613074qwc.31 for ; Sun, 10 Apr 2011 15:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.81.85 with SMTP id w21mr3571690qck.128.1302473078678; Sun, 10 Apr 2011 15:04:38 -0700 (PDT) Received: by 10.229.9.211 with HTTP; Sun, 10 Apr 2011 15:04:38 -0700 (PDT) In-Reply-To: <4DA15996.9010901@warmcat.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> Date: Mon, 11 Apr 2011 08:04:38 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames 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: Sun, 10 Apr 2011 22:04:40 -0000 On 10 April 2011 17:17, Andy Green wrote: > On 04/10/2011 07:23 AM, Somebody in the thread at some point said: >> >> On Sun, Apr 10, 2011 at 07:49:48AM +1000, Greg Wilkins wrote: >>> >>> Currently the jetty server has a configurable buffer size. =A0If a fram= e >>> arrives that is larger than the buffer size, we close the connection >>> with a message too large status code. > > libwebsockets takes the approach the user code can decide the policy and > does no aggregation buffering. =A0It passes up every packet in a frame as= it > comes and the user code can see if it is the last (FIN) one. =A0That way = the > user code can choose to have it as it comes or do its own aggregation > buffering, but either way the library is being as lightweight as possible= . Andy, I agree that this is a good way to handle maximal message size. Jetty also gives the use the option to receive messages frame by frame. I'm more concerned by maximal frame size, as these can be 64bit and I don't really want to get into passing an application data that is only part of a frame, as it is much more likely that it will be on an unusable boundary (eg 2 bytes of a 3 bytes UTF-8 character). > A better way to come at it is just define a sane maximum frame size in th= e > protocol, say 64Kbytes, and require that the worst case is supported, rat= her > than add more control messages and code and stuff to go wrong. =A0I guess > 63-bit length started off as being message size, got refined into the FIN > scheme and until now did not get reassessed for still being useful for fr= ame > length job it finds itself changed to. There was certainly a few that argued for small fixed max frame size, but unlimited message size. However I think that a few were able to make their argument for effectively infinite frames as well, so we have both effectively infinite frames and infinite messages. So I don't wont to reopen those debates - just say that it would be useful to have some default minimal frame sizes that must be supported and a way to declare frame sizes larger than that. > There's another limit which is maximum message size that the client is > willing to cope with. =A0It's probably more useful to tell that in header= s if > telling anything. I find that less useful, as often for large messages the size will not be known, either because it is not yet generated or perhaps because the utf-8 encoding size has not been calculated. Maximal frame sizes is something that a WS implementation must deal with directly and effects buffers, APIs etc. Message size is not something that an impl ever need calculate, let alone limit. cheers From gregw@intalio.com Sun Apr 10 15:19:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8022C3A6940 for ; Sun, 10 Apr 2011 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.173, 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 fp1TEb+lHhpA for ; Sun, 10 Apr 2011 15:19:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id DEDC53A6907 for ; Sun, 10 Apr 2011 15:19:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so4633618vxg.31 for ; Sun, 10 Apr 2011 15:19:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.75.231 with SMTP id f7mr2381827vdw.158.1302473984422; Sun, 10 Apr 2011 15:19:44 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Sun, 10 Apr 2011 15:19:44 -0700 (PDT) In-Reply-To: <4DA0EA91.2070003@rlgsc.com> References: <4DA0EA91.2070003@rlgsc.com> Date: Mon, 11 Apr 2011 08:19:44 +1000 Message-ID: From: Greg Wilkins To: gezelter@rlgsc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] JavaScript WebSockets Dependencies 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: Sun, 10 Apr 2011 22:19:45 -0000 On 10 April 2011 09:24, Bob Gezelter wrote: > Once communications have been established, > character set negotiation is properly a function of the protocol levels > above the WebSocket protocol, and the WebSocket protocol should be > completely agnostic in this regard. I certainly don't disagree with you on this. However, this group did have long and hard fought discussions about being character encoding agnostic and about having meta data such as content-encoding explicitly supported in the protocol. Eventually the consensus was to not have a framing that was based on UTF-8 encoding, but to have a frame type that indicated a UTF-8 encoded payload. Binary payloads are unspecified and I'm sure(hope) subprotocols will be developed to carry arbitrary content with meta data. cheers From gregw@intalio.com Sun Apr 10 18:37:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995F33A6A37 for ; Sun, 10 Apr 2011 18:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9f5-pE9yX5J for ; Sun, 10 Apr 2011 18:36:59 -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 21F053A6A30 for ; Sun, 10 Apr 2011 18:36:57 -0700 (PDT) Received: by vws12 with SMTP id 12so4731484vws.31 for ; Sun, 10 Apr 2011 18:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.113 with SMTP id dj17mr3234884vdb.38.1302485817716; Sun, 10 Apr 2011 18:36:57 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Sun, 10 Apr 2011 18:36:57 -0700 (PDT) Date: Mon, 11 Apr 2011 11:36:57 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Draft websocket interoperability tests 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, 11 Apr 2011 01:37:00 -0000 As promised, here is a draft of the interoperability tests that I've proposed http://www.ietf.org/staging/draft-wilkins-hybi-websocket-tests-00.txt I'd really appreciate co-authors to step forward to both improve the quality of this document and to suggest more tests cheers From micheil@brandedcode.com Sun Apr 10 19:04:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B534D3A6A3F for ; Sun, 10 Apr 2011 19:04:46 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgtDeuMCFHsb for ; Sun, 10 Apr 2011 19:04:46 -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 F2DFC3A6A30 for ; Sun, 10 Apr 2011 19:04:45 -0700 (PDT) Received: by pvh1 with SMTP id 1so2310335pvh.31 for ; Sun, 10 Apr 2011 19:04:45 -0700 (PDT) Received: by 10.143.178.10 with SMTP id f10mr4759450wfp.108.1302487485727; Sun, 10 Apr 2011 19:04:45 -0700 (PDT) Received: from [192.168.46.181] (124-149-177-22.dyn.iinet.net.au [124.149.177.22]) by mx.google.com with ESMTPS id z10sm7575922wfj.12.2011.04.10.19.04.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 19:04:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Micheil Smith In-Reply-To: Date: Mon, 11 Apr 2011 12:04:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Greg Wilkins X-Mailer: Apple Mail (2.1082) Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests 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, 11 Apr 2011 02:04:46 -0000 Greg: do you have a sample implementation of a few of these tests, some = of the language used=20 is a little bit confusing here. Although, I'm sure it's just my lack of skill in reading IETF drafts. =96 Micheil On 11/04/2011, at 11:36 AM, Greg Wilkins wrote: > As promised, here is a draft of the interoperability tests that I've = proposed >=20 > = http://www.ietf.org/staging/draft-wilkins-hybi-websocket-tests-00.txt >=20 > I'd really appreciate co-authors to step forward to both improve the > quality of this document and to suggest more tests >=20 > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From duerst@it.aoyama.ac.jp Sun Apr 10 19:07:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DA13A6A3B for ; Sun, 10 Apr 2011 19:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.398 X-Spam-Level: X-Spam-Status: No, score=-100.398 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 Omux97aFJkUq for ; Sun, 10 Apr 2011 19:07:23 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by core3.amsl.com (Postfix) with ESMTP id 0C95F3A6A30 for ; Sun, 10 Apr 2011 19:07:22 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p3B27GfM012602 for ; Mon, 11 Apr 2011 11:07:16 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 40bc_1575_6c90b73e_63e0_11e0_8078_001d0969ab06; Mon, 11 Apr 2011 11:07:16 +0900 Received: from [IPv6:::1] ([133.2.210.5]:48893) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 11 Apr 2011 11:07:15 +0900 Message-ID: <4DA26244.4090701@it.aoyama.ac.jp> Date: Mon, 11 Apr 2011 11:07:00 +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.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests 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, 11 Apr 2011 02:07:24 -0000 On 2011/04/11 10:36, Greg Wilkins wrote: > As promised, here is a draft of the interoperability tests that I've proposed > > http://www.ietf.org/staging/draft-wilkins-hybi-websocket-tests-00.txt That's a strange URI. 'staging' means it may not be correctly published. Can you please make sure it's published correctly and you get an URI such as http://www.ietf.org/id/draft-wilkins-hybi-websocket-tests-00.txt or http://tools.ietf.org/html/draft-wilkins-hybi-websocket-tests-00 or so before you tell us to read it? Thanks, Martin. > I'd really appreciate co-authors to step forward to both improve the > quality of this document and to suggest more tests > > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From duerst@it.aoyama.ac.jp Sun Apr 10 20:35:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CFF3A6A5F for ; Sun, 10 Apr 2011 20:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.379 X-Spam-Level: X-Spam-Status: No, score=-100.379 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 8ekNs-fGnTYY for ; Sun, 10 Apr 2011 20:35:07 -0700 (PDT) Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by core3.amsl.com (Postfix) with ESMTP id 714083A6A47 for ; Sun, 10 Apr 2011 20:35:07 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p3B3Yxqr018144 for ; Mon, 11 Apr 2011 12:34:59 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 40c3_321d_adb4d64e_63ec_11e0_8078_001d0969ab06; Mon, 11 Apr 2011 12:34:59 +0900 Received: from [IPv6:::1] ([133.2.210.5]:55409) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 11 Apr 2011 12:34:59 +0900 Message-ID: <4DA276C4.3020902@it.aoyama.ac.jp> Date: Mon, 11 Apr 2011 12:34:28 +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.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: gezelter@rlgsc.com References: <4DA0EA91.2070003@rlgsc.com> In-Reply-To: <4DA0EA91.2070003@rlgsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] JavaScript WebSockets Dependencies 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, 11 Apr 2011 03:35:09 -0000 Hello Bob, On 2011/04/10 8:24, Bob Gezelter wrote: > There have been several references recently on the dichotomy between text > and binary. A recurring theme seems to be the effect that this is > helpful to > the JavaScript library. That was one of the reasons to do it, but not the only one. > Once communications have been established, > character set negotiation is properly a function of the protocol levels > above the WebSocket protocol, and the WebSocket protocol should be > completely agnostic in this regard. First, I'd just say that this is for WebSockets to decide (and essentially already has been decided). Because ultimately, characters are encoded as binary, it's certainly possible to claim that at a certain level, everything is, or should be, just binary. But the idea of binary with character *encoding* negotiation on top is just one way to deal with the binary/textual division. (Caution, what's negotiated are not character *sets*, although the parameter name for it is often "charset".) This negotiation didn't exist a long time ago, and it may fall out of favor in the future. As an example of the past, ftp has a binary/textual distinction, but no character encoding negotiation. Character encoding has been a big mess for a long time. Character labeling (and negotiation, although there's rather few negotiation going on even in HTTP, where it's available in the protocol) was an attempt deal with this. It was only partially successful. But with Unicode/ISO 10646 and UTF-8, we may be slowly but steadily see the light at the end of the tunnel. The IETF essentially knew that the tunnel would end at UTF-8 in 1998 (see http://tools.ietf.org/html/rfc2277). The fact that UTF-8 is preferred for text interchange, but that many important frameworks (Java, JavaScript, .Net,...) store Unicode internally as UTF-16 increases the benefit of distinguishing text and binary, because the application programmer gets the conversion for free and has one less thing to worry about or mess up. Also, programming languages that don't have something like a 'string' datatype are very few and very far between. It's not at all that we are adapting to a peculiar API in a single programming language. The way the WebSocket protocol does away with character encoding negotiation may be seen as a big problem when looking backwards, but when looking forwards, it should turn out to be something that will be followed by other protocols. There are already quite a few XML formats for example that just say "always UTF-8", although XML itself would allow more variation. And once we are rid of character encoding negotiation, the distinction between binary and text makes quite a bit more sense. It actually exists in many protocols. I have already mentioned ftp. In email, there are textual headers, and a textual body if it's ASCII. In WebSockets, I imagine textual data being used for things such as commands (e.g. as in SMTP), short textual data (e.g. something like irc messages) and longer textual blobs (e.g. HTML, XML, JSON,... in UTF-8). Binary will be used for everything else, mostly binary blobs (e.g. images) and binary bits and pieces of continuous media (audio, video). Regards, Martin. From gregw@intalio.com Sun Apr 10 23:05:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43F83A6A81 for ; Sun, 10 Apr 2011 23:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nOfq9e8CphC for ; Sun, 10 Apr 2011 23:05:34 -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 8812E3A69D8 for ; Sun, 10 Apr 2011 23:05:34 -0700 (PDT) Received: by vws12 with SMTP id 12so4837690vws.31 for ; Sun, 10 Apr 2011 23:05:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.140 with SMTP id m12mr6879766vdu.238.1302501934379; Sun, 10 Apr 2011 23:05:34 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Sun, 10 Apr 2011 23:05:34 -0700 (PDT) In-Reply-To: <4DA26244.4090701@it.aoyama.ac.jp> References: <4DA26244.4090701@it.aoyama.ac.jp> Date: Mon, 11 Apr 2011 16:05:34 +1000 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests 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, 11 Apr 2011 06:05:36 -0000 On 11 April 2011 12:07, "Martin J. D=FCrst" wrote: > That's a strange URI. 'staging' means it may not be correctly published. I must have transgressed some written rule of ietf draft submission as it wants manual process and says that it will take 2 days. You can view status here: https://datatracker.ietf.org/idst/status.cgi?passed_filename=3Ddraft-wil= kins-hybi-websocket-tests cheers From gregw@intalio.com Sun Apr 10 23:14:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA4D3A6A89 for ; Sun, 10 Apr 2011 23:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dEQScAKHsDk for ; Sun, 10 Apr 2011 23:14:12 -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 E0B2B3A6A85 for ; Sun, 10 Apr 2011 23:14:11 -0700 (PDT) Received: by vws12 with SMTP id 12so4841679vws.31 for ; Sun, 10 Apr 2011 23:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.180.72 with SMTP id dm8mr6768265vdc.118.1302502450210; Sun, 10 Apr 2011 23:14:10 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Sun, 10 Apr 2011 23:14:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Apr 2011 16:14:10 +1000 Message-ID: From: Greg Wilkins To: Micheil Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests 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, 11 Apr 2011 06:14:13 -0000 On 11 April 2011 12:04, Micheil Smith wrote: > Greg: do you have a sample implementation of a few of these tests, some of the language used > is a little bit confusing here. > > Although, I'm sure it's just my lack of skill in reading IETF drafts. More likely my lack of skill in writing them. Jetty has an implementation of these tests and you can download and run it with: wget -O jetty-all.jar https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse/jetty/aggregate/jetty-all/7.4.0.RC0/jetty-all-7.4.0.RC0.jar wget --user-agent=something http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestServer --help java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestServer --port 8080 then in another window java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestClient --help java -cp jetty-all.jar:servlet-api-2.5.jar org.eclipse.jetty.websocket.TestClient --port 8080 --verbose --protocol echo-fragment --size 12 --fragment 3 cheers From gezelter@rlgsc.com Mon Apr 11 07:57:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3418D3A6A1F for ; Mon, 11 Apr 2011 07:57:12 -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=[AWL=0.000, 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 3ArfD4o5+luJ for ; Mon, 11 Apr 2011 07:57:10 -0700 (PDT) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) by core3.amsl.com (Postfix) with SMTP id C338C3A6889 for ; Mon, 11 Apr 2011 07:57:10 -0700 (PDT) Received: (qmail 1314 invoked from network); 11 Apr 2011 14:57:10 -0000 Received: from unknown (141.157.198.38) by p3plsmtpa07-04.prod.phx3.secureserver.net (173.201.192.233) with ESMTP; 11 Apr 2011 14:57:06 -0000 Message-ID: <4DA316BB.3050501@rlgsc.com> Date: Mon, 11 Apr 2011 09:56:59 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Multiplexing, Binary/Text; Endpoint Identification X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 14:57:12 -0000 The recent discussion concerning some of the issues raised in my blog (http://rlgsc.com/r/20110323) has been interesting. However, my point is and was not to restart discussion from the beginning, but to ensure as flexible a future as possible. The WebSocket protocol seems poised for mass adoption; significant changes following official standardization will be disruptive and painful. Past history shows that such changes are often all but unimplementable, a reality with no shortage of examples (SMTP was temporary until issues were resolved, hence the "Simple"; also see "Mythical Man Month" by Fred Brooks concerning OS/360 architectural mis-steps). The multiplexing discussion is of great interest, and I am certainly not trying to steal John's thunder, but perhaps the implications of my main points have been obscured by the history of the discussion. Many of the points raised in the ensuing discussion of multiplexing are significant, yet the concerns have little effect on the specification of multiplexing at the level of the wire protocol. My concerns do not require a complete definition of multiplexing behavior, nor do I intend to imply that all WebSocket protocol implementations support large-scale multiplexing. Rather, I see it as critical to define the structural framework within which multiplexing is implemented. The issues of implementation can then be appropriately resolved at a future time. These concerns only require a modest change in the wire protocol and related parts of the the specification (these are not suggested text, merely checklist items): - Addition of two frame types: o Open WebSocket subChannel (endpoint ID, quota, UTF-8/binary) o Close WebSocket subChannel - Small modification to Close frame ("close all subChannels") - Addition to the opening WebSocket protocol handshake ("SubChannels: n"; baseline, non-multiplexed implementations use "SubChannels: 1"). From both sides, count is minimum of exchanged values. - Coalesce frame types for UTF-8/binary data into a single frame type; "Data" (mode is associated with the subChannel and specified in the Open WebSocket subChannel control frame). - Addition of subChannel identification to a new "Switch SubChannel" control frame. I know that many prefer to implement communication schemes based upon printable representations (e.g., UTF-8). While this is not my preferred approach for inter-machine communications (I personally prefer binary specifications), I have no desire to have a "Coke vs. Pepsi" dispute. I would prefer to enable all constituencies to have their favorite flavor. That said, I do not see many applications routinely switching back and forth on a frame-by-frame basis between UTF-8 and binary. If that capability is desired, it can parsimoniously be provided by implementing a "Switch Mode" control frame (it could also be included as part of the "Switch subChannel" control frame). This approach also removes the need for the restriction (at the end of 4.4 in the -06 draft) that all fragments within a message must be either text or binary. The current specification does not permit intra-message mode switching and this proposal does not change that rule. Under my proposal the mode of a subchannel is established at open, and can be changed. Intra-message mode switching is not permitted by definition. The Open SubChannel command frame type now has three minimal requirements: - definition of endpoint (suggestion: TAG URI of desired partner; this allows a wide degree of flexibility in design and implementation without imposing anything more than an IETF-sanctioned way to hierarchically distinguish names for endpoints; including explicit ways to define "well-known" services, should they evolve; for example: WebSocket.ietf.org:ftp for an ftp portal over an existing WebSocket protocol connection). - Transfer quota specification (default value permissible). - specifying UTF-8 or binary mode for the subChannel. Note that the above does not discuss the "Hows" of multiplexing, it merely establishes a framework. Different multiplexing schemes can be used as extensions, and it is certainly possible to enhance the Open subchannel control frame with supplemental commands specifying options. Needless to say, the existence of multiplexing at the WebSocket protocol level is all but invisible to the JavaScript user/developer. The modest changes are limited to the WebSockets library-class layer. My reasoning is straightforward. Supersetting has a very poor track record. Unintended mutually incompatible supersetting has been the bane of interoperability since the long before the Internet protocol suite. Defining an architectural space with multiple viable subset implementations enable interoperability in the long term with few side effects at the outset. Needless to say, I will be happy to clarify any of my thoughts on the above. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From jat@google.com Mon Apr 11 08:20:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E29628B23E for ; Mon, 11 Apr 2011 08:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.857 X-Spam-Level: X-Spam-Status: No, score=-105.857 tagged_above=-999 required=5 tests=[AWL=0.119, 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 BNgOrE-4feHN for ; Mon, 11 Apr 2011 08:20:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1F4023A6889 for ; Mon, 11 Apr 2011 08:20:30 -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 p3BFKTJt004818 for ; Mon, 11 Apr 2011 08:20:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302535230; bh=eM/YsCQP9C2O4Ug5lpdb7Myfd1k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZXPwprJMEcTjUiEg9J2BXibmZ9i/eYCT+T7ltxhFkABG03f1xYx6JcmhuM4pZOIW0 M+pEOtXJvy8et2xNX0xFA== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by wpaz17.hot.corp.google.com with ESMTP id p3BFKS1Z030528 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 11 Apr 2011 08:20:28 -0700 Received: by gxk27 with SMTP id 27so2666520gxk.29 for ; Mon, 11 Apr 2011 08:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rcq6e2YB9/lRFQ/UtcOUVKP1oiR8iCMtV01xuL1dS+o=; b=c1uwuA916E6VVe+a0ic5ZGX/HtjD0evQ/jewmE4dCRFL633uioZur4Wtoj3Il85Nif T6Tam4TWrt73MjgLqlVA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lymvWPOuhRMPLJYVNQoIeJ4qCu8IroxnW5/WP+LKuWsDi4UGRsPGLiUqo8cjVKkYqY 6DIBTTvcTx6JBuuBVbfA== Received: by 10.150.61.9 with SMTP id j9mr4634903yba.238.1302535226111; Mon, 11 Apr 2011 08:20:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Mon, 11 Apr 2011 08:20:06 -0700 (PDT) In-Reply-To: <4DA316BB.3050501@rlgsc.com> References: <4DA316BB.3050501@rlgsc.com> From: John Tamplin Date: Mon, 11 Apr 2011 11:20:06 -0400 Message-ID: To: gezelter@rlgsc.com Content-Type: multipart/alternative; boundary=000e0cd4c0e075b64904a0a61d35 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing, Binary/Text; Endpoint Identification 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, 11 Apr 2011 15:20:33 -0000 --000e0cd4c0e075b64904a0a61d35 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 11, 2011 at 10:56 AM, Bob Gezelter wrote: > My concerns do not require a complete definition of multiplexing > behavior, nor do I intend to imply that all WebSocket protocol > implementations support large-scale multiplexing. Rather, I see it > as critical to define the structural framework within which > multiplexing is implemented. The issues of implementation can then > be appropriately resolved at a future time. These concerns only > require a modest change in the wire protocol and related parts of the > the specification (these are not suggested text, merely checklist > items): > I believe the current extension model supplies the necessary infrastructure. If an endpoint does not support multiplexing, then having these new frame types defined isn't going to help any more anyway. > - Addition of two frame types: > o Open WebSocket subChannel (endpoint ID, quota, UTF-8/binary) > o Close WebSocket subChannel > > - Small modification to Close frame ("close all subChannels") > > - Addition to the opening WebSocket protocol handshake > In the non-MUXed case, we already have this: the open subchannel is the handshake (and there is no quota for non-MUXed channels, as that would complicate simple uses), close subchannel is just a close frame, and since there is only one subchannel it automatically means to close all of them. > ("SubChannels: n"; baseline, non-multiplexed implementations use > "SubChannels: 1"). From both sides, count is minimum of exchanged > values. > > - Coalesce frame types for UTF-8/binary data into a single frame type; > "Data" (mode is associated with the subChannel and specified in the > Open WebSocket subChannel control frame). > This seems totally independent of MUX discussions. As mentioned, the JSAPI receives a callback when a message is complete, and that callback receives an object of the proper type -- until binary frames are supported, that is only a string. Given the API choices there, which if you disagree with them should be discussed in WHATWG, a text frame has to be differentiated from a binary frame. > - Addition of subChannel identification to a new "Switch SubChannel" > control frame. > I strongly disagree with relying on context to know which channel a particular frame should be delivered to - I think it is much better to keep the logical channel associated with a frame. > I know that many prefer to implement communication schemes based upon > printable representations (e.g., UTF-8). While this is not my preferred > approach for inter-machine communications (I personally prefer binary > specifications), I have no desire to have a "Coke vs. Pepsi" dispute. > I would prefer to enable all constituencies to have their favorite flavor. > At an application level, many of them want to exchange text information, such as JSON objects, text in a chat program, etc. > This approach also removes the need for the restriction (at the end of 4.4 in the -06 draft) that all fragments within a message must be either text or > binary. The current specification does not permit intra-message mode > switching and this proposal does not change that rule. Under my proposal > the mode of a subchannel is established at open, and can be changed. > Intra-message mode switching is not permitted by definition. > Not just that all fragments must be text or binary, but that a message has a single opcode type, and the fragments are all fragments of one message. If the first fragment is of some extension opcode, then all remaining fragments are of that same opcode, with the exception that control frames can be injected into the middle of a fragmented message. The point of mixing message/frame information like this is to keep things simple and allow small frames to remain very small (with a 2-byte overhead, plus masking for client->server). -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4c0e075b64904a0a61d35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 11, 2011 at 10:56 AM, Bob Gezelter <= span dir=3D"ltr"><gezelter@rlgsc.c= om> wrote:
My concerns do not require a complete definition of multiplexing
behavior, nor do I intend to imply that all WebSocket protocol implementati= ons support large-scale multiplexing. Rather, I see it
as critical to define the structural framework within which
multiplexing is implemented. The issues of implementation can then
be appropriately resolved at a future time. These concerns only
require a modest change in the wire protocol and related parts of the
the specification (these are not suggested text, merely checklist
items):

I believe the current extension= model supplies the necessary infrastructure. =C2=A0If an endpoint does not= support multiplexing, then having these new frame types defined isn't = going to help any more anyway. =C2=A0
=C2=A0
=C2=A0- Addition of two frame types:
=C2=A0 =C2=A0o Open WebSocket subChannel (endpoint ID, quota, UTF-8/binary= )
=C2=A0 =C2=A0o Close WebSocket subChannel

=C2=A0- Small modification to Close frame ("close all subChannels&quo= t;)

=C2=A0- Addition to the opening WebSocket protocol handshake

In the non-MUXed case, we already have this: =C2=A0t= he open subchannel is the handshake (and there is no quota for non-MUXed ch= annels, as that would complicate simple uses), close subchannel is just a c= lose frame, and since there is only one subchannel it automatically means t= o close all of them.
=C2=A0
=C2=A0 =C2=A0("SubChannels: n"; baseline, non-multiplexed implem= entations use
=C2=A0 =C2=A0"SubChannels: 1"). From both sides, count is minimu= m of exchanged
=C2=A0 =C2=A0values.

=C2=A0- Coalesce frame types for UTF-8/binary data into a single frame typ= e;
=C2=A0 =C2=A0"Data" (mode is associated with the subChannel and = specified in the
=C2=A0 =C2=A0Open WebSocket subChannel control frame).

This seems totally independent of MUX discussions. =C2=A0A= s mentioned, the JSAPI receives a callback when a message is complete, and = that callback receives an object of the proper type -- until binary frames = are supported, that is only a string. =C2=A0Given the API choices there, wh= ich if you disagree with them should be discussed in WHATWG, a text frame h= as to be differentiated from a binary frame.
=C2=A0
=C2=A0- Addition of subChannel identification to a new "Switch SubCha= nnel"
=C2=A0 =C2=A0control frame.

I strongly= disagree with relying on context to know which channel a particular frame = should be delivered to - I think it is much better to keep the logical chan= nel associated with a frame.
=C2=A0
I know that many prefer to implement communication schemes based upon
printable representations (e.g., UTF-8). While this is not my preferred
approach for inter-machine communications (I personally prefer binary
specifications), I have no desire to have a "Coke vs. Pepsi" disp= ute.
I would prefer to enable all constituencies to have their favorite flavor.<= br>

At an application level, many of them w= ant to exchange text information, such as JSON objects, text in a chat prog= ram, etc. =C2=A0
=C2=A0
This approach also removes= the need for the restriction (at the end of 4.4
in the -06 draft) that all fragments within a message must be either text o= r
binary. The current specification does not permit intra-message mode
switching and this proposal does not change that rule. Under my proposal the mode of a subchannel is established at open, and can be changed.
Intra-message mode switching is not permitted by definition.

Not just that all fragments must be text or binary, b= ut that a message has a single opcode type, and the fragments are all fragm= ents of one message. =C2=A0If the first fragment is of some extension opcod= e, then all remaining fragments are of that same opcode, with the exception= that control frames can be injected into the middle of a fragmented messag= e. =C2=A0The point of mixing message/frame information like this is to keep= things simple and allow small frames to remain very small (with a 2-byte o= verhead, plus masking for client->server).

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd4c0e075b64904a0a61d35-- From ferg@caucho.com Mon Apr 11 08:59:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E730B28C12E for ; Mon, 11 Apr 2011 08:59:04 -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=[AWL=0.000, 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 J1B-flWvz2Pk for ; Mon, 11 Apr 2011 08:59:04 -0700 (PDT) Received: from nm21.bullet.mail.sp2.yahoo.com (nm21.bullet.mail.sp2.yahoo.com [98.139.91.91]) by core3.amsl.com (Postfix) with SMTP id E835C28C134 for ; Mon, 11 Apr 2011 08:59:03 -0700 (PDT) Received: from [98.139.91.64] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 11 Apr 2011 15:59:04 -0000 Received: from [98.139.91.35] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 11 Apr 2011 15:59:04 -0000 Received: from [127.0.0.1] by omp1035.mail.sp2.yahoo.com with NNFMP; 11 Apr 2011 15:59:04 -0000 X-Yahoo-Newman-Id: 569133.40659.bm@omp1035.mail.sp2.yahoo.com Received: (qmail 2031 invoked from network); 11 Apr 2011 15:59:04 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 11 Apr 2011 08:59:04 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: Lhv7H_wVM1m4Vae9P_em8TWMY3eFU3SD6xsugbrsveXZEj5 jTov.MuRK6wRuY4fEHHW_CKFWxq5z9LmvX5LgPc58mXHFWFj2K4jQ_4FoK86 3P80oqdhD7.U3v.zf3NXHm7y_x92JJNhdUsaO9Tne7Tc4KAvGC69Pv3WTXIw V.ymD.DHqDhN7ry9FsFESRZzvri6JrbaOt3QU7xg4MdKGJy1tbt_YTUzimEo RM5OAAEVsVons4pD6ZnczPNp3Be1hzt.thiYP1Z1eiZ2.HZHn.ztPqBHb.WO eUEyHqI_0M71Vpoe_FiNrpOBvJU3hJSkCMULt8etmnK__8M2Bm2XW2UIjv5Q 0Xu_5_IuLu6VxqHl4gGQ.4Q4j8Ncb6luztTIgVIA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DA32543.7050709@caucho.com> Date: Mon, 11 Apr 2011 08:58:59 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4DA0EA91.2070003@rlgsc.com> <4DA276C4.3020902@it.aoyama.ac.jp> In-Reply-To: <4DA276C4.3020902@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [hybi] JavaScript WebSockets Dependencies 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, 11 Apr 2011 15:59:05 -0000 On 04/10/2011 08:34 PM, "Martin J. Dürst" wrote: > Hello Bob, > > On 2011/04/10 8:24, Bob Gezelter wrote: > >> Once communications have been established, >> character set negotiation is properly a function of the protocol levels >> above the WebSocket protocol, and the WebSocket protocol should be >> completely agnostic in this regard. > > First, I'd just say that this is for WebSockets to decide (and > essentially already has been decided). Because ultimately, characters > are encoded as binary, it's certainly possible to claim that at a > certain level, everything is, or should be, just binary.... > > Character encoding has been a big mess for a long time. Character > labeling (and negotiation, although there's rather few negotiation > going on even in HTTP, where it's available in the protocol) was an > attempt deal with this. It was only partially successful. But with > Unicode/ISO 10646 and UTF-8, we may be slowly but steadily see the > light at the end of the tunnel. The IETF essentially knew that the > tunnel would end at UTF-8 in 1998 (see > http://tools.ietf.org/html/rfc2277). Solving the encoding negotiation problem is a big win for the WebSocket text encoding. I've seen (and been forced to implement) far too many failures of character encoding negotiation to want to ever deal with it again. For example, the HTTP URL encoding (or rather lack of encoding) has been a recurring painful experience. The full-blown character negotiation of IIOP/CORBA was a genuine horror. That IIOP example shows, in full gory detail, that adding full flexibility for encoding choice is a far worse solution than mandating UTF-8. Also, PHP's encoding is in such a difficult state because it initially used binary strings. In contrast, the Java decision to always use UTF-8 for its strings encoding in .class files, serialization, etc. has been very successful and easy to work with. Those aren't theoretical concerns; they're examples of other protocols and systems that choose to start with binary and put off text encoding for later. I would strongly discourage following those mistakes. -- Scott From ferg@caucho.com Mon Apr 11 09:02:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B9F28C13A for ; Mon, 11 Apr 2011 09:02:52 -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=[AWL=0.000, 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 Nm2JiKIcuLnk for ; Mon, 11 Apr 2011 09:02:51 -0700 (PDT) Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by core3.amsl.com (Postfix) with SMTP id 9900728C135 for ; Mon, 11 Apr 2011 09:02:51 -0700 (PDT) Received: from [98.139.52.189] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 11 Apr 2011 16:02:51 -0000 Received: from [98.139.52.160] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 11 Apr 2011 16:02:51 -0000 Received: from [127.0.0.1] by omp1043.mail.ac4.yahoo.com with NNFMP; 11 Apr 2011 16:02:51 -0000 X-Yahoo-Newman-Id: 907458.54776.bm@omp1043.mail.ac4.yahoo.com Received: (qmail 75792 invoked from network); 11 Apr 2011 16:02:51 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 11 Apr 2011 09:02:51 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: kcyoJpgVM1lnf.PQV44c5g9kZWkzSbv24wqfmhZpOAEo60Q Na7Xaf61Jly3_LUKINoIKwLl7fltZPdsTo0xE6eJG6mu7te9PT5XIFaL9pyZ h29hgeXQc_jbsnaUH1FfMvSOG2R22hkEOMWLgH3rxWxGWfDvaHnor8_XwiNm DTv6GVSDX4lMoO8eTvw9a68Uyz46XIMUX8I1b8YWLg5CrvlKzaikLrR6YS1m amwDH_2ZaXHhCqHSH9V.QY_oqYxk9ASehnGXh48fYU3aModjCJ4w2X6vgKQz qy8IJEAe6sGmPx6Eeel39XrS1YJSmKL4hDhEppzdHfP51wm5vykLfmP_E.Lf Svj0z X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DA3262A.5030406@caucho.com> Date: Mon, 11 Apr 2011 09:02:50 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] On Fragmentation of Frames 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, 11 Apr 2011 16:02:52 -0000 On 04/10/2011 03:04 PM, Greg Wilkins wrote: > On 10 April 2011 17:17, Andy Green wrote: >> On 04/10/2011 07:23 AM, Somebody in the thread at some point said: >>> On Sun, Apr 10, 2011 at 07:49:48AM +1000, Greg Wilkins wrote: >>>> Currently the jetty server has a configurable buffer size. If a frame >>>> arrives that is larger than the buffer size, we close the connection >>>> with a message too large status code. >> libwebsockets takes the approach the user code can decide the policy and >> does no aggregation buffering. It passes up every packet in a frame as it >> comes and the user code can see if it is the last (FIN) one. That way the >> user code can choose to have it as it comes or do its own aggregation >> buffering, but either way the library is being as lightweight as possible. > Andy, > > I agree that this is a good way to handle maximal message size. > Jetty also gives the use the option to receive messages frame by frame. > > I'm more concerned by maximal frame size, as these can be 64bit and I > don't really want to get into passing an application data that is only > part of a frame, as it is much more likely that it will be on an > unusable boundary (eg 2 bytes of a 3 bytes UTF-8 character). You shouldn't be passing frames to the application. The application should only see messages. The receiver can always support any frame length, even with a fixed receiving buffer. The frame length is only required for the sender. -- Scott From timeless.bmo2@gmail.com Sun Apr 10 15:38:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EECD3A6940 for ; Sun, 10 Apr 2011 15:38:24 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2rKv9Ag22+q for ; Sun, 10 Apr 2011 15:38:23 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id CEE173A6907 for ; Sun, 10 Apr 2011 15:38:22 -0700 (PDT) Received: by iye19 with SMTP id 19so6302735iye.31 for ; Sun, 10 Apr 2011 15:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5gfkekL2g8jDsGSuqgzKhDxG7wUcXCgf9lTP45i/y0o=; b=rXI0kzdFIy17X5JkJzqMNhmMrFHRjLw82W3kp/Xd/8VD8lz3oNMEGpFWwMyYcqXcW6 XI3+eacBSqGCztZ38Zv9tIdelD930qvzsZ2eTVW6oG7mQ2iz5XWNPqyzFiDdOwzyoqpR fFpkDRHEUcWs6rdXvDK2kbXTlXOFyA3Si8CzM= 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:cc:content-type; b=k91vM7qPR/Qjc20mSJ/ohA7GFysHLMv77VQzZQU1N0+MU+VZXI6V8gYe3Wo+bn0xpU Vpo+UcvjOQCoMVbc+aiLi8z2U973OnW82qYVYkF1G5cy4+ddltYrTI9Jg2WhrSiiQA+Q JOIOi58SwPSv0xyhq0JRm6rHYbKDgDslJufww= MIME-Version: 1.0 Received: by 10.42.144.131 with SMTP id b3mr2078760icv.13.1302475102078; Sun, 10 Apr 2011 15:38:22 -0700 (PDT) Sender: timeless.bmo2@gmail.com Received: by 10.42.229.137 with HTTP; Sun, 10 Apr 2011 15:38:22 -0700 (PDT) In-Reply-To: <4D924284.5030804@nokia.com> References: <4D924284.5030804@nokia.com> Date: Mon, 11 Apr 2011 01:38:22 +0300 X-Google-Sender-Auth: FnMHAaKmC_V_rD2XqmU6qRZuxfM Message-ID: From: timeless To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 11 Apr 2011 12:12:13 -0700 Cc: Arthur Barstow Subject: Re: [hybi] websockets protocol getting solid - cross-reviews; deadline April 15 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: Sun, 10 Apr 2011 22:42:54 -0000 On Tue, Mar 29, 2011 at 11:35 PM, Arthur Barstow wrote: > All comments should be submitted to hybi@ietf.org by April 15 at the latest. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 > This protocol is intended to fail to establish a connection with > servers of pre-existing protocols like SMTP or HTTP, while allowing s/or/and/ > 5. If the component of /uri/ is "ws", set /secure/ to > false; otherwise, if the component is "wss", set > /secure/ to true; otherwise, fail this algorithm. it seems odd to use otherwise twice, i think the first instance can be omitted > o The /resource name/ string must be a non-empty string of > characters in the range U+0021 to U+007E that starts with a U+002F > SOLIDUS character (/). s/that starts/and start/ > Any WebSocket URIs not meeting the above criteria are considered > invalid, and a client MUST NOT attempt to make a connection to an > invalid WebSocket URI. s/, and a/. A/ > Payload length: 7 bits > in network byte order. The payload length is the length of the > Extension data + the length of the Application Data. The length > of the Extension data may be zero, in which case the Payload > length is the length of the Application data. This block uses both "Application data" and "Application Data", I think the former is intended based on the definitions that follow: > Extension data: n bytes > Application data: n bytes > be counted before first byte is sent. With fragmentation, a server > or intermediary may choose a reasonable size buffer, and when the a client, server, or intermediary ? > 4. The request MUST contain a "Host" header whose value is equal to > the authority component of the WebSocket URI. Is there a reason to use 'authority component' instead of /host/ or defining '/authority component/' in
? > The steps to *parse a WebSocket URI's components* from a string /uri/ > are as follows. These steps return either a /host/, a /port/, a > /resource name/, and a /secure/ flag, or they fail. > 6. Optionally, a "Sec-WebSocket-Protocol header, with a list of > values indicating which protocols the client would like to speak, > ordered by preference. The ordered by preference part only appears to be listed in the Server portion of the spec, as it's relatively important for the client to understand that order matters, it seems useful to indicate this in the client section too. >7.2.2. Server-initiated closure > Certain algorithms require or recommend that the server _abort the > WebSocket connection_ during the opening handshake. To do so, the > server must simply _close the WebSocket connection_ (Section 7.1.1). Is there a reason 'must' here isn't in caps? > 1003 > 1003 indicates that an endpoint is terminating the connection > because it has received a type of data it cannot accept (e.g. an > endpoint that understands only text data may send this if it > receives a binary message.) s/.)/)./ > 8.1. Negotiating extensions > extension-list = 1#extension > extension = extension-token *( ";" extension-param ) > extension-token = registered-token | private-use-token > registered-token = token > private-use-token = "x-" token > extension-param = token [ "=" ( token | quoted-string ) ] .. > is exactly equivalent to > Sec-WebSocket-Extensions: foo, bar; baz=2 I don't see <,> covered by the ABNF > Note that the client is only offering to > use any advertised extensions, and MUST NOT use them unless the > server accepts the extension. perhaps s/accepts/responds indicating that it wants to use/ > The extensions > listed by the server in response represent the extensions actually in > use. perhaps s/use/use for the connection/ > corresponding bytes using their percent-encoded form as defined in > the URI and IRI specification. [RFC3986] [RFC3987] "specifications" ? ---- The IETF, IANA (10.1/10.2/10.3) and [RFC3864] (10.4-10.9) sections each use different section header formats in the version of the document I'm reviewing, which seems unfortunate, but I guess that each agency has defined its own style. ---- > accept connections from non-WebSocket clients (e.g. HTTP clients) s/ HTTP/ HTTP/ -- "e.g." is not a sentence terminator. > set of protocol-level extensions to use during the connection. "during" seems odd. Perhaps "for" or "for the duration of" or ...? -- to me, "during" almost implies "during [set up of] the connection" From gregw@intalio.com Mon Apr 11 15:31:37 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EEDE8E06CB for ; Mon, 11 Apr 2011 15:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WK-5hZSwD4P for ; Mon, 11 Apr 2011 15:31:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 7D035E0669 for ; Mon, 11 Apr 2011 15:31:22 -0700 (PDT) Received: by vws12 with SMTP id 12so5687335vws.31 for ; Mon, 11 Apr 2011 15:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.113 with SMTP id dj17mr4821505vdb.38.1302559202529; Mon, 11 Apr 2011 15:00:02 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Mon, 11 Apr 2011 15:00:02 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110411123359.066dd7a8@resistor.net> References: <6.2.5.6.2.20110411123359.066dd7a8@resistor.net> Date: Tue, 12 Apr 2011 08:00:02 +1000 Message-ID: From: Greg Wilkins To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:31:38 -0000 On 12 April 2011 05:43, SM wrote: > Hi Greg, > At 18:36 10-04-2011, Greg Wilkins wrote: >> >> As promised, here is a draft of the interoperability tests that I've >> proposed > > I suggest taking a look at RFC 5657 as it provides some guidance about > interoperability and implementation reports. Well I wasn't intending to presume to be making an interoperability report for the protocol (but it looks like such a thing would be helpful to move the protocol through the process). RFC5657 does briefly talk about tests and appears to imply that for report purposes it prefers either realworld feedback or tests derived from real world data, rather than unit tests designed to test particular features. This suggests that the testing approach I'm advocating may have limited applicability when the time comes for writing the real interoperability report. However, I do believe it is very useful to have a series of known tests so that we can quickly check at least the basics between implementations. If such testing does not fit in the IETF process, I'm more than happy to drop the ietf from these test names and make them an informal agreement between implementers. cheers From sm@resistor.net Mon Apr 11 23:45:54 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 73BB9E074A for ; Mon, 11 Apr 2011 23:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDAX38t8F0X9 for ; Mon, 11 Apr 2011 23:45:50 -0700 (PDT) Received: from mx.elandsys.com (eland-1-pt.tunnel.tserv15.lax1.ipv6.he.net [IPv6:2001:470:c:d43::2]) by ietfc.amsl.com (Postfix) with ESMTP id CE283E075D for ; Mon, 11 Apr 2011 23:45:48 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3C6jeWM020142; Mon, 11 Apr 2011 23:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1302590747; bh=9IfD+hTTrS8UVr20/evcfZPph6mVv5/L5hu++JdU1Iw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=vGa6nEs8Alk0gRQJMZlM96TG9+Yjha5oaCEOj8XyAZOLyMkT70cGITBB7vhKtuJaA KmJGX32Boj8hmqVxyVskHqA9IF96YgFERr7YrdjQuSsMJ6awyyHVc1Ye7wXHAmh19D AvFm41dDWRwZeqyahJN9Ou7sInVY8EZzQfS1Yn+s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1302590747; bh=9IfD+hTTrS8UVr20/evcfZPph6mVv5/L5hu++JdU1Iw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=T1qVugfOH+LPFuf9OIrXcjCTN9p6dSbNPz+byKKMLRxMsGVqToToLF1VSaCmSHT1G qD+FbyuQ4URu2iDsLu4VpFrEq3FiMtbexDa0WsnpiQLWvnniCffK6w9wf2YNExGRas 5sGhOJ1NN72IZJc1YGTZ6BWyWzGIO4S59DxXGEgU= Message-Id: <6.2.5.6.2.20110411231103.051468f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 11 Apr 2011 23:24:04 -0700 To: Greg Wilkins From: SM In-Reply-To: References: <6.2.5.6.2.20110411123359.066dd7a8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 06:45:54 -0000 Hi Greg, At 15:00 11-04-2011, Greg Wilkins wrote: >Well I wasn't intending to presume to be making an interoperability >report for the protocol (but it looks like such a thing would be >helpful to move the protocol through the process). Yes. >RFC5657 does briefly talk about tests and appears to imply that for >report purposes it prefers either realworld feedback or tests derived >from real world data, rather than unit tests designed to test >particular features. This suggests that the testing approach I'm >advocating may have limited applicability when the time comes for >writing the real interoperability report. Ok. >However, I do believe it is very useful to have a series of known >tests so that we can quickly check at least the basics between >implementations. If such testing does not fit in the IETF process, >I'm more than happy to drop the ietf from these test names and make >them an informal agreement between implementers. It can be published as an individual submission if you want that. You could leave the test names as they are and see how it goes. :-) Regards, -sm From ibc@aliax.net Tue Apr 12 00:30:28 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77882E077C for ; Tue, 12 Apr 2011 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcyTU0II+k1j for ; Tue, 12 Apr 2011 00:30:27 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id BAAD1E0792 for ; Tue, 12 Apr 2011 00:30:25 -0700 (PDT) Received: by qyk7 with SMTP id 7so4100167qyk.10 for ; Tue, 12 Apr 2011 00:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.201.133 with SMTP id fa5mr4901464qab.126.1302593425409; Tue, 12 Apr 2011 00:30:25 -0700 (PDT) Received: by 10.229.75.7 with HTTP; Tue, 12 Apr 2011 00:30:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2011 09:30:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] draft-ibc-websocket-dns-srv-00 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 07:30:28 -0000 2011/4/8 I=C3=B1aki Baz Castillo : > Hi, I've written a draft for including DNS SRV resolution in WebSocket pr= otocol: > > > =C2=A0Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DNS SRV Resource Records f= or the WebSocket Protocol > =C2=A0Filename: =C2=A0draft-ibc-websocket-dns-srv-00 > =C2=A0URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://oversip.net/public/draft-ib= c-websocket-dns-srv.html The draft is now submitted to the IETF: http://tools.ietf.org/html/draft-ibc-websocket-dns-srv Regards. --=20 I=C3=B1aki Baz Castillo From andy.warmcat.com@googlemail.com Tue Apr 12 01:04:08 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 624FCE06CB for ; Tue, 12 Apr 2011 01:04:08 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQMtW1kGrY7c for ; Tue, 12 Apr 2011 01:04:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3992CE0764 for ; Tue, 12 Apr 2011 01:04:07 -0700 (PDT) Received: by wwa36 with SMTP id 36so5232172wwa.13 for ; Tue, 12 Apr 2011 01:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7W8flHToWQbsS7dWUHO2rKueQ32mPefhuYcvZpjJ8RI=; b=xzxQWQDzazCWm7aY8tAkJLjmG3RW540p9pHaZ61hZZbTTsdY4b88AQS3BAhZlDxoR+ SOAVB+Z9QS7ibUFSpBkP2nquXwpIA+K4hObD9q1Ze1rpJ8SUNMWXZglwZrvcll+P65BR tqJ+EAHGv4Ry/KVg8QippfZezeD9T9nUtMZbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lmClZi22o+bx8dsgTloIfbuqVPDN2Fr2exS4ifeI1SuLrL/7c1O0084xBVC5p3Inop GbsgTPDQ1DD79SGPi6I/K0/TiHICpxDu1ZVX/T8fAE2KMVMTSX+JkQ7RyQLntvI+FUa3 7zwYrabHE9HR8T5kEILiqY2+7eF7f6nAmMG/s= Received: by 10.216.144.205 with SMTP id n55mr3746804wej.5.1302595446486; Tue, 12 Apr 2011 01:04:06 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id o6sm3858633wbo.20.2011.04.12.01.04.04 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 01:04:05 -0700 (PDT) Sender: Andy Green Message-ID: <4DA40773.7000702@warmcat.com> Date: Tue, 12 Apr 2011 09:04:03 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: gezelter@rlgsc.com References: <4DA316BB.3050501@rlgsc.com> In-Reply-To: <4DA316BB.3050501@rlgsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing / some implementation stories X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:04:08 -0000 On 04/11/2011 03:56 PM, Somebody in the thread at some point said: Hi - > My reasoning is straightforward. Supersetting has a very poor track > record. Unintended mutually incompatible supersetting has been the bane of > interoperability since the long before the Internet protocol suite. > Defining > an architectural space with multiple viable subset implementations enable > interoperability in the long term with few side effects at the outset. The danger here is that we instead introduce a sclerosis about the mux approach too early in the base spec. And we cannot put other things in the base spec to support extensions that we did not think of yet, so it's questionable to do it for mux. Leaving the reserved opcode wormhole for extension basis seems the better bet. Actually, partway through implementing x-google-mux, the mux stuff is pretty scary and not lacking in implications all over the place. Here are some examples. They're not killers just hidden implications. 1) Existing libwebsockets is heavily using states and POLLOUT from poll() to rate-limit sending, I think it is best practice. Trying to keep that good structure in mux world means nothing works properly until intra-mux quotas are implemented, since then you don't know when to make the synthetic POLLOUT event on the subchannel. I assume it's still possible to do everything driven by a real poll() POLLOUT loop with the real socket, but that is pretty subtle and not mentioned anywhere in the mux spec since it's implementation. 2) A pre-connection speculative child list is required due to racing. Say the first ws:// connection is requested from the script, we compose a handshake or contact the proxy first, mark that state and return the as-yet unconnected websocket pointer. So the client asks for the second ws:// right away. We can see it is to the same address, port, url as the first guy. But actually, we don't know then if x-google-mux extension was allowed by the server since the handshake is still pending for the first guy we would like to be our parent. By default, we would deny muxing then to all the other connections until the first guy is established, which might be 500ms or whatever, usually all the other websocket connections from the script are requested long before. So no muxing actually happens! The answer is the speculative child list, if the parent connection fails they are freed to make their own connections, likewise if it succeeds without x-google-mux accepted by the server. If the parent succeeds with x-google-mux only then do the children move to the state of having the MUX addchannel being sent for them and so on. 3) I already hated masking but x-google-mux correctly defines mux content is unmasked and you can mask the mux stream. Well it's recursive, mux streams can be muxed but somehow this masking is magic at upper level? Is that possible since my upper level may be someone else's mux subchannel and due to masking not being subordinate to framing, you don't know if you are looking at something which is masked or not just by looking at it. 4) Similar to 3), mux stream is a bunch of recursively-parse-it-to-determine-length random junk. I have no idea how people will manage to debug and interoperate these streams. Traditionally here that concern has everyone sniggering behind their handkerchiefs but really - try it. The sins so far in the lowest level protocol come right back to roost. -Andy From andy.warmcat.com@googlemail.com Tue Apr 12 01:30:01 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6E512E0673 for ; Tue, 12 Apr 2011 01:30:01 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7X0lKzK-EwP for ; Tue, 12 Apr 2011 01:30:00 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 5664AE0682 for ; Tue, 12 Apr 2011 01:30:00 -0700 (PDT) Received: by wwa36 with SMTP id 36so5247235wwa.13 for ; Tue, 12 Apr 2011 01:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3cRDRacszrYq2iAfCWkh83CG1icRfJoJbJBOIA3WSG0=; b=DjfSFP4EuFLDqVPTFLTdYPMJt2iGXiiCMqsHc9EmEk4CXx/PTJt2g9aMK1KpGzvkwc B3Qk6eHlzTARKMQ6VUOYZ4qUaz9Eg5T4a//6R6CrS6p0RRY4fHr6RqwSlNsU0czoTYtM ryGPNcaZ8G4lHLowxCnhkqjSM2h1FVPhOQH6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=b767zQ8ZZYhXLMYYjeXT7RMdRVJG13BXh8BHAZxkr0LXC9g+YBD4SeTbpQB/SBfpwE lT3T5bG/hpQi4DZ/krTogE6g5cQuAdXu1otrjs2ldtbajGKFluUE6KaSv3g5HBZdpkNt 8FauH3+iguIRVvtLnGdLxQFljuimlqAqcT9o4= Received: by 10.227.54.6 with SMTP id o6mr6274511wbg.61.1302596999710; Tue, 12 Apr 2011 01:29:59 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id h11sm3872884wbc.9.2011.04.12.01.29.57 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 01:29:58 -0700 (PDT) Sender: Andy Green Message-ID: <4DA40D84.1040407@warmcat.com> Date: Tue, 12 Apr 2011 09:29:56 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:30:01 -0000 On 04/10/2011 11:04 PM, Somebody in the thread at some point said: Hi - > I'm more concerned by maximal frame size, as these can be 64bit and I > don't really want to get into passing an application data that is only > part of a frame, as it is much more likely that it will be on an > unusable boundary (eg 2 bytes of a 3 bytes UTF-8 character). This is a bit wimpy to say "much more likely". Either you can't deal with hanging coding it and it blows up sooner or later, or you can deal with it. If you can deal with it, you don't care any more about frame reassembly. If you choose to implement in a way that breaks with legal, large frames, that's a detail about your implementation. You can adapt your implementation to not care rather than introduce frame MTU concept into the spec. > Maximal frame sizes is something that a WS implementation must deal > with directly and effects buffers, APIs etc. Message size is not > something that an impl ever need calculate, let alone limit. That is wrong. If you write an implementation that aggregates frames you introduce a fragility to legal frame length and your implementation has a problem. If you implement it in a better way, it is not sensitive to frame size. Separately, the maximum legal frame length is meaningless in the real world. It can stay like it is without direct problem but it just gives ammo to the masking-fudsters. It'd be better to limit it to 16-bit or 32-bit length and make masking subordinate to framing. -Andy From gregw@intalio.com Tue Apr 12 16:57:16 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DFBFCE079A for ; Tue, 12 Apr 2011 16:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO8Jl4tomEkx for ; Tue, 12 Apr 2011 16:57:16 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 18144E076C for ; Tue, 12 Apr 2011 16:57:15 -0700 (PDT) Received: by vxg33 with SMTP id 33so76442vxg.31 for ; Tue, 12 Apr 2011 16:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.113 with SMTP id dj17mr6730767vdb.38.1302652635589; Tue, 12 Apr 2011 16:57:15 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Tue, 12 Apr 2011 16:57:15 -0700 (PDT) In-Reply-To: <4DA40D84.1040407@warmcat.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> Date: Wed, 13 Apr 2011 09:57:15 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 23:57:17 -0000 On 12 April 2011 18:29, Andy Green wrote: > This is a bit wimpy to say "much more likely". =A0Either you can't deal w= ith > hanging coding it and it blows up sooner or later, or you can deal with i= t. true. Hmmm I guess if we allow intermediaries to fragment arbitrarily - even without knowledge of the extensions being applied, then any limits on handling atomic chunks needs to be based on message size and not frame size. Eitherway, I think there are going to be implementations that have at least message size limits (if not frame size as well), and unless we have a way to declare that, then we will have interoperability problems. cheers From andy.warmcat.com@googlemail.com Wed Apr 13 00:45:18 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7305E073C for ; Wed, 13 Apr 2011 00:45:18 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2h9DIhaR3-j for ; Wed, 13 Apr 2011 00:45:18 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id C28A7E06E6 for ; Wed, 13 Apr 2011 00:45:17 -0700 (PDT) Received: by wwa36 with SMTP id 36so244098wwa.13 for ; Wed, 13 Apr 2011 00:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uFyq1YxO/2BZvtJdDjhavVv+hT6iQb0lTwkIM13fSzs=; b=O4qTPO4zsG92HIyBUvjp3IPJDI2j9u3bqOdwlCnPbUDHphO62LvvaPXggAClOSIlkJ KEEf0+J5OxfJFxp+Pd46Lk+E6QkUlLbTFublfJ8qIkh2KAHsGTBxfzv+qNOH0RPm88ET jsviDfWKbakVu+N5DnP89NyLprosQToXdvbbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oLaRaiDN1keEghDA5Z9+HIYFHvGr/nmUT2gfyQuaefb8FTXCsHxW3jbh4orEWCUm7J 4cqxfT/Ze2g4TtS/Dn3PzkrQP61/1BHZlXOR1kbOOFn1FgkD3M5gE/HB0XOlA5T7u5T8 Kc4k38W/DTbGcpfzqIpa/vSfRuomFmc7RM1Qk= Received: by 10.227.198.5 with SMTP id em5mr6381041wbb.163.1302680717089; Wed, 13 Apr 2011 00:45:17 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id w25sm151360wbd.56.2011.04.13.00.45.15 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 00:45:15 -0700 (PDT) Sender: Andy Green Message-ID: <4DA5548A.2080401@warmcat.com> Date: Wed, 13 Apr 2011 08:45:14 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:45:19 -0000 On 04/13/2011 12:57 AM, Somebody in the thread at some point said: Hi - > Eitherway, I think there are going to be implementations that have at > least message size limits (if not frame size as well), and unless we > have a way to declare that, then we will have interoperability > problems. Yeah. It only applies to cases where the peer wants to hold atomic messages. But I'm not sure if telling a magic limit reflects reality at the client if there is a shared pool of memory like malloc, many websocket connections are opened saying 10MB is the limit, potentially overcommitting the pool and then suddenly all of them get a max size message exhausting the pool or something else that uses the pool commits most of it and big messages come, etc. So it can still fail unless you really preallocated 10MB per conn just in case which is unrealistic. Or, it might be a file transfer protocol, the message is a file coming, but you are out of disk space partway. So it doesn't solve the issue of messages coming that can't be handled for whatever reason. If the peers tell their in headers, it does genuinely tell you that you can't send a message above that limit, but it does not tell you that you can succeed to send a message below. It might be worth having that optional "Don't send me messages bigger than X" header anyway and if it's not there it defaults to accepting any size message because it doesn't buffer them. I think if the other peer, dynamically, finds it can't cope with what ends up coming all being called one message, it's OK if the websocket connection closes due to that. It can't actually cope. -Andy From arman@noemax.com Wed Apr 13 03:48:01 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88EA1E0700 for ; Wed, 13 Apr 2011 03:48:01 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7gfCoMFguNk for ; Wed, 13 Apr 2011 03:48:00 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfc.amsl.com (Postfix) with ESMTP id AEB8DE0692 for ; Wed, 13 Apr 2011 03:48:00 -0700 (PDT) Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id WOJ79805; Wed, 13 Apr 2011 13:48:05 +0300 From: "Arman Djusupov" To: "'Andy Green'" , "'Greg Wilkins'" References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> In-Reply-To: <4DA40D84.1040407@warmcat.com> Date: Wed, 13 Apr 2011 13:47:50 +0300 Message-ID: <001601cbf9c8$408b5680$c1a20380$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMGw91Y1ldIKC4JkeWR/Yjplmn+tAKVoDb7ASux1ssBjWgYNAJlGvW/AGplhA8CTIdBIgGe+zf+kYW55xA= Content-Language: en-us Cc: 'Hybi' Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:48:01 -0000 As far as I remember the huge frame length header was introduced in order to support TransferFile or similar routines that allow the kernel to transfer data directly from the file IO handle into the socket. In such cases the file would be sent as one huge frame. But since the introduction of payload masking I'm not sure if this approach in sending data is still applicable. I think we should reconsider the frame length field again. I don't have any specific preference but I agree than a 32 bit frame length field would be sufficient. I also agree that it would a good idea to have the communicating sides negotiate the maximum allowed message size (i.e. the total size of all frames for a message). Not negotiating this option will result in the communicating sides being forced to drop the connection when their limit is reached. Sending some error code is not always an option since in many cases simple applications do not read when sending data so they would not receive the error until the connection is aborted by the remote side. Maybe the two sides could exchange such properties during the WS handshake? With best regards, Arman -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Andy Green Sent: Tuesday, April 12, 2011 11:30 AM To: Greg Wilkins Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames On 04/10/2011 11:04 PM, Somebody in the thread at some point said: Hi - > I'm more concerned by maximal frame size, as these can be 64bit and I > don't really want to get into passing an application data that is only > part of a frame, as it is much more likely that it will be on an > unusable boundary (eg 2 bytes of a 3 bytes UTF-8 character). This is a bit wimpy to say "much more likely". Either you can't deal with hanging coding it and it blows up sooner or later, or you can deal with it. If you can deal with it, you don't care any more about frame reassembly. If you choose to implement in a way that breaks with legal, large frames, that's a detail about your implementation. You can adapt your implementation to not care rather than introduce frame MTU concept into the spec. > Maximal frame sizes is something that a WS implementation must deal > with directly and effects buffers, APIs etc. Message size is not > something that an impl ever need calculate, let alone limit. That is wrong. If you write an implementation that aggregates frames you introduce a fragility to legal frame length and your implementation has a problem. If you implement it in a better way, it is not sensitive to frame size. Separately, the maximum legal frame length is meaningless in the real world. It can stay like it is without direct problem but it just gives ammo to the masking-fudsters. It'd be better to limit it to 16-bit or 32-bit length and make masking subordinate to framing. -Andy _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From andy.warmcat.com@googlemail.com Wed Apr 13 04:00:27 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC716E06C2 for ; Wed, 13 Apr 2011 04:00:27 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clkYNeVK+E0r for ; Wed, 13 Apr 2011 04:00:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id B5709E06FE for ; Wed, 13 Apr 2011 04:00:26 -0700 (PDT) Received: by wwa36 with SMTP id 36so362360wwa.13 for ; Wed, 13 Apr 2011 04:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5uG1tl0arNXBUdonbAoIfip97dv3Vb8NQvWYnlNz17Y=; b=pB/p4DnPn7SzvjUZc3hkl6yk6DcTRVQ6/8/ADIXcV5n+P5aZY/1D8MMy8v2pOMqHi0 K5v6fTC35p99NNVsyEnPDkFOaiQGAdKRnjIfewh30phakpcWmwW0bkLJSQY2Vxu9QNUh vg7wv+gJswK6eP6XwRGcMH6u1myQ48Z51AWdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=orElxwd84XRIbB5QfLqE7Eg1qrwZjedcqVN+2p0s6WMDWDlUe1E++BUnc6b90oXVs8 yWIKQ/4ic0rwQECnGD4Ei1jADqXMuB8XH6ve1VYyQPF0r1XEqoH9ZBIuKAJzRE6/smxN qBhm3bPjN5638twZZAi1/yVj58wpgHS9s7rkk= Received: by 10.227.13.135 with SMTP id c7mr3670612wba.111.1302692426086; Wed, 13 Apr 2011 04:00:26 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id u9sm260475wbg.17.2011.04.13.04.00.24 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 04:00:25 -0700 (PDT) Sender: Andy Green Message-ID: <4DA58243.1090204@warmcat.com> Date: Wed, 13 Apr 2011 12:00:19 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Arman Djusupov References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> In-Reply-To: <001601cbf9c8$408b5680$c1a20380$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Hybi' , 'Greg Wilkins' Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:00:27 -0000 On 04/13/2011 11:47 AM, Somebody in the thread at some point said: > As far as I remember the huge frame length header was introduced in order to > support TransferFile or similar routines that allow the kernel to transfer > data directly from the file IO handle into the socket. In such cases the > file would be sent as one huge frame. But since the introduction of payload > masking I'm not sure if this approach in sending data is still applicable. > > I think we should reconsider the frame length field again. I don't have any > specific preference but I agree than a 32 bit frame length field would be > sufficient. Yeah I don't mind either 16-bit or 32-bit either, although I don't really see what I will do with the extra 16 bits when I can just spam extra frames without limit and other pressures make me not want to have particularly long frames. > I also agree that it would a good idea to have the communicating sides > negotiate the maximum allowed message size (i.e. the total size of all > frames for a message). > > Not negotiating this option will result in the communicating sides being > forced to drop the connection when their limit is reached. > Sending some error code is not always an option since in many cases simple > applications do not read when sending data so they would not receive the > error until the connection is aborted by the remote side. > > Maybe the two sides could exchange such properties during the WS handshake? That also sounds fine, but we need to be clear just telling the maximum doesn't mean the peer can always actually take a message below the maximum, ie, it doesn't get us out of handing the same error conditions coming randomly because the peer has exhausted some resource it depended on to take the max message on that connection at that moment. It will help that at least the other peer will presumably never issue a message larger than the maximum his partner could even imagine to handle at any time. -Andy From simonp@opera.com Wed Apr 13 04:28:53 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DEA37E06E0 for ; Wed, 13 Apr 2011 04:28:53 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS5Gny4RaItO for ; Wed, 13 Apr 2011 04:28:53 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfc.amsl.com (Postfix) with ESMTP id 2DC4EE068E for ; Wed, 13 Apr 2011 04:28:52 -0700 (PDT) Received: from simon-pieterss-macbook.local (c-039ee355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.158.3]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3DBSoKr013749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Apr 2011 11:28:51 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "'Andy Green'" , "'Greg Wilkins'" , "Arman Djusupov" References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> Date: Wed, 13 Apr 2011 13:28:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: <001601cbf9c8$408b5680$c1a20380$@noemax.com> User-Agent: Opera Mail/11.10 (MacIntel) Cc: 'Hybi' Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:28:54 -0000 On Wed, 13 Apr 2011 12:47:50 +0200, Arman Djusupov wrote: > As far as I remember the huge frame length header was introduced in > order to > support TransferFile or similar routines that allow the kernel to > transfer > data directly from the file IO handle into the socket. In such cases the > file would be sent as one huge frame. But since the introduction of > payload > masking I'm not sure if this approach in sending data is still > applicable. The masking is only from client to server. -- Simon Pieters Opera Software From arman@noemax.com Wed Apr 13 08:35:53 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D61B7E07D0 for ; Wed, 13 Apr 2011 08:35:53 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9PcYABv9EdD for ; Wed, 13 Apr 2011 08:35:53 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfc.amsl.com (Postfix) with ESMTP id 12215E076F for ; Wed, 13 Apr 2011 08:35:53 -0700 (PDT) Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id WTW52958; Wed, 13 Apr 2011 18:35:58 +0300 From: "Arman Djusupov" To: "'Andy Green'" References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> In-Reply-To: <4DA58243.1090204@warmcat.com> Date: Wed, 13 Apr 2011 18:35:41 +0300 Message-ID: <000201cbf9f0$77786fc0$66694f40$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMGw91Y1ldIKC4JkeWR/Yjplmn+tAKVoDb7ASux1ssBjWgYNAJlGvW/AGplhA8CTIdBIgGe+zf+AYAgE+sCPluPxJFoFH2w Content-Language: en-us Cc: 'Hybi' , 'Greg Wilkins' Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:35:54 -0000 >Yeah I don't mind either 16-bit or 32-bit either, although I don't really see what I will do with the extra 16 bits when I can just spam extra frames without limit and other pressures make me not want to have particularly long frame 64KB (16 bits) is too small for a single frame. There is often a need to send an already buffered message that exceeds 64KB, in such cases the message that is otherwise prepared for sending would need to be chunked. This would require spending additional processing on splitting it. Receiving such a message would also require additional processing for reading each frame's header and concatenating the payload. In my opinion this continuous splitting/concatenating is unnecessary just for saving 16 bits in the frame header. Note that my background is in non-browser communications where medium/large/super large messages are the norm. A 32 bit header would permit the sending of 2GB as a single-frame message which is more than enough for today and is probably going to be a reasonable frame size for the foreseeable future. This not a big deal, if the WG doesn't feel like changing the frame header I can live with what we have now. > That also sounds fine, but we need to be clear just telling the maximum doesn't mean the peer can always actually take a message below the maximum, ie, it doesn't get us out of handing the same error conditions coming randomly because the peer has exhausted some resource it depended on to take the max message on that connection at that moment. > > It will help that at least the other peer will presumably never issue a message larger than the maximum his partner could even imagine to handle at any time. If the message is below the maximum limit, the peer can stop receiving and wait for either a timeout or some resources to become available. However if the message is above the maximum the receiver will have to either drop the connection or waste a lot of time by receiving and discarding the frames of the message that it can't process due to its too large size. This is presently a problem with some HTTP services where time is wasted uploading a file only to get an HTTP error reporting that the file is too big. I would say that negotiating the max message size is not a requirement, but it would definitely be a good-to-have feature. Support for this feature could be optional, but the feature itself should be in the standard so that everyone who supports it does so in an interoperable manner. With best regards, Arman From andy.warmcat.com@googlemail.com Wed Apr 13 09:15:26 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7EEDE081C for ; Wed, 13 Apr 2011 09:15:26 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCjnFRDJlT58 for ; Wed, 13 Apr 2011 09:15:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id D3F3DE0815 for ; Wed, 13 Apr 2011 09:15:25 -0700 (PDT) Received: by wwa36 with SMTP id 36so617680wwa.13 for ; Wed, 13 Apr 2011 09:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R77/eenaOPbufQRYmO+7hrH7/le7kQyL7NjQi2yZoyA=; b=Yj9SrZFyJClJus8zZeHxGTIMj+8fksKX5DFb4sl60n9eZl/r4dw1s+FqbfCikz3R9h 495b+J3bETOY18jmkIWKwQ2NjcEFdl/ZKYRmhcz8pq7CZpNcgVkfhyIpv5YdjXf82/Go LiJFfqW78Xs5E3khfIvof/LomJtY1Hu6KWVkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fJusMb6TY5KC/AqV7lmHcqLqFRow2nKDLH+XhFR8RjcL7QTPuWV7PT9K8BYGe0Y6HN diTPPHeOVJC/Nn4yIWezpnzpKqtN2+OJ3iCx3CRpUrXZaItETe94iKIL2ycYW7s4+rA7 jPXy62szrmy4thvtTfjcy6ycSLr24YZ4YgMSg= Received: by 10.227.201.9 with SMTP id ey9mr7090415wbb.41.1302711324450; Wed, 13 Apr 2011 09:15:24 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id l24sm437839wbc.13.2011.04.13.09.15.22 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 09:15:23 -0700 (PDT) Sender: Andy Green Message-ID: <4DA5CC19.8070201@warmcat.com> Date: Wed, 13 Apr 2011 17:15:21 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Arman Djusupov References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> <000201cbf9f0$77786fc0$66694f40$@noemax.com> In-Reply-To: <000201cbf9f0$77786fc0$66694f40$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Hybi' , 'Greg Wilkins' Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:15:27 -0000 On 04/13/2011 04:35 PM, Somebody in the thread at some point said: >> Yeah I don't mind either 16-bit or 32-bit either, although I don't > really see what I will do with the extra 16 bits when I can just spam extra > frames without limit and other pressures make me not want to have > particularly long frame > > 64KB (16 bits) is too small for a single frame. There is often a need to I don't see why it is "too small", too small for what? Obviously it works fine with 16 bits. Anyway I don't mind either way. > send an already buffered message that exceeds 64KB, in such cases the > message that is otherwise prepared for sending would need to be chunked. > This would require spending additional processing on splitting it. Receiving > such a message would also require additional processing for reading each > frame's header and concatenating the payload. In my opinion this continuous > splitting/concatenating is unnecessary just for saving 16 bits in the frame > header. Note that my background is in non-browser communications where > medium/large/super large messages are the norm. I don't mind much if it's 32 bits but don't forget there are pressures to keep frames small. In the mux case, there is going to be all kind of chopping and tagging and management overhead going on so cutting at 64Kbytes is irrelevant there. > A 32 bit header would permit the sending of 2GB as a single-frame message > which is more than enough for today and is probably going to be a reasonable > frame size for the foreseeable future. I didn't really understand what bad thing happens with smaller maximum frame size. It's not like it stops working or there's massive overhead, nor is there any real value in getting 2GByte in one blob blocking control messages for minutes on a typical connection. Anyway it doesn't matter either way. >> It will help that at least the other peer will presumably never > issue a message larger than the maximum his partner could even imagine to > handle at any time. > > If the message is below the maximum limit, the peer can stop receiving and > wait for either a timeout or some resources to become available. I guess, although then the standard might need to talk about timeouts being mandatory if it is expected one end will use stalling forever as flow control. > I would say that negotiating the max message size is not a requirement, but > it would definitely be a good-to-have feature. > Support for this feature could be optional, but the feature itself should be > in the standard so that everyone who supports it does so in an interoperable > manner. Yeah it makes sense to define it, unlike frame MTU case. -Andy From ferg@caucho.com Wed Apr 13 09:17:08 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 56DD9E07B8 for ; Wed, 13 Apr 2011 09:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rofOVg7S2W27 for ; Wed, 13 Apr 2011 09:17:05 -0700 (PDT) Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfc.amsl.com (Postfix) with SMTP id 29AAAE0823 for ; Wed, 13 Apr 2011 09:17:05 -0700 (PDT) Received: from [98.139.212.150] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2011 16:17:01 -0000 Received: from [98.139.212.198] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2011 16:17:01 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 13 Apr 2011 16:17:01 -0000 X-Yahoo-Newman-Id: 898815.62414.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 61234 invoked from network); 13 Apr 2011 16:17:01 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp102.biz.mail.bf1.yahoo.com with SMTP; 13 Apr 2011 09:17:01 -0700 PDT X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: 7itmD.QVM1kHy4bGx2ziSS7bnjPeuD8YnibxV6haRpwIuvS uZbhTjj40ugdZhVBnQ.DaKGR.MkFiKwrL4Hio8NRF91WwOa.TObO93CEWOtq sMO4oRXnrC8eIIGUwgrvtaXNQ6_hQ4KAOTgmJD3RlE31z2tBSzRByiyX5DD4 TZCZ4q20.8Dnm0ggjS50gbxoQpZ18w_UMgrzlO2jm8SlecIte_5GOxpbeARK Lc5EaloTs2t9mL63OWrjZQoqNtxV95QPTCfOht1dYtsszGe3IR.SJizP.mi8 JGfhC5H._AQkTauPBFWbI3vpg_Xw6GQ8Oj2IeUy9Q1BHxxMNJOQQ8mbyC2sH J5NlaUaX0SZCuphMhS8U4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DA5CC7C.4090600@caucho.com> Date: Wed, 13 Apr 2011 09:17:00 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> <000201cbf9f0$77786fc0$66694f40$@noemax.com> In-Reply-To: <000201cbf9f0$77786fc0$66694f40$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:17:08 -0000 On 04/13/2011 08:35 AM, Arman Djusupov wrote: > > I would say that negotiating the max message size is not a requirement, but > it would definitely be a good-to-have feature. > Support for this feature could be optional, but the feature itself should be > in the standard so that everyone who supports it does so in an interoperable > manner. Postponing until after mux might be a good idea. mux needs frame/channel limits intrinsically as part of its basic requirements, and having two separate max size mechanisms may be a bit of a mess. -- Scott > With best regards, > Arman > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > From andy.warmcat.com@googlemail.com Wed Apr 13 09:42:07 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DF73E0809 for ; Wed, 13 Apr 2011 09:42:07 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxeZOalX3y2h for ; Wed, 13 Apr 2011 09:42:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 53A14E07A1 for ; Wed, 13 Apr 2011 09:42:06 -0700 (PDT) Received: by wwa36 with SMTP id 36so639269wwa.13 for ; Wed, 13 Apr 2011 09:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s0BOBCMGmtRLdMty4RqAFYm1uWI4pjf2IGZu/iuru3U=; b=Wk5NXmpYBrwFWGrrKQEz30NtUdis5gijhRZi/Nr+Za6HzJAkGIUyB/nxiw/CQqhjA7 wtpqR6r1yIn+mtTQ/lyHwVT7fsxF4JMz2YuU+rxZgq55vry1nVhM0Y2RBvhUr6gtpn3S jLQ6XB2GyNeztVLufY/IQyv9nmtsZ62kIO1ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=olm/56Xz2GwOXN+Ju7clmdWf9vUldSkzQzWKIZ4jDoCBPeCoja6COdW7ivnKNag/Nt U0s+hiSWCEIrQL4bFpkDu+hRSFrhN1aQPN5b8COU4134ZtMgftGjHMrmeugR3YftlRqK c4YR8mI5W3zKA2fTAT/fJPTtZ0gD5V3hW8kvw= Received: by 10.227.196.208 with SMTP id eh16mr5636064wbb.224.1302712925627; Wed, 13 Apr 2011 09:42:05 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id z13sm451212wbd.29.2011.04.13.09.42.03 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 09:42:03 -0700 (PDT) Sender: Andy Green Message-ID: <4DA5D25A.2060009@warmcat.com> Date: Wed, 13 Apr 2011 17:42:02 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Scott Ferguson References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> <000201cbf9f0$77786fc0$66694f40$@noemax.com> <4DA5CC7C.4090600@caucho.com> In-Reply-To: <4DA5CC7C.4090600@caucho.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:42:07 -0000 On 04/13/2011 05:17 PM, Somebody in the thread at some point said: > On 04/13/2011 08:35 AM, Arman Djusupov wrote: >> >> I would say that negotiating the max message size is not a >> requirement, but >> it would definitely be a good-to-have feature. >> Support for this feature could be optional, but the feature itself >> should be >> in the standard so that everyone who supports it does so in an >> interoperable >> manner. > > Postponing until after mux might be a good idea. mux needs frame/channel > limits intrinsically as part of its basic requirements, and having two > separate max size mechanisms may be a bit of a mess. FWIW x-google-mux currently has a scheme where differential headers are issued to override the ones that differ from the original connection set. In that way, it can use exactly the same header-based scheme for singletons and muxed child connections for this any anything else header-based. -Andy From jat@google.com Wed Apr 13 11:33:13 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 46C72E06FC for ; Wed, 13 Apr 2011 11:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.856 X-Spam-Level: X-Spam-Status: No, score=-107.856 tagged_above=-999 required=5 tests=[AWL=-1.880, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdG+o8ep6jJM for ; Wed, 13 Apr 2011 11:33:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id F04C7E06AC for ; Wed, 13 Apr 2011 11:33:11 -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 p3DIXAI3023112 for ; Wed, 13 Apr 2011 11:33:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302719591; bh=Fn+8Yj1so6Hvi92RLXd47Bqrgow=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=e329lXoirxbA17OxgZ9MedislgntYq5CdZTjVYGmHW3ErsItWx/j32g16fv3zmpd0 w0ElN3rjC5bHAnP8JK37g== Received: from ywi6 (ywi6.prod.google.com [10.192.9.6]) by wpaz24.hot.corp.google.com with ESMTP id p3DIW6oa028073 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Apr 2011 11:33:09 -0700 Received: by ywi6 with SMTP id 6so378216ywi.3 for ; Wed, 13 Apr 2011 11:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Gu53coSELixzA/vfHRMqiDxwl0JPV16FNsKB7+uC5HM=; b=JnkPDDp46n4bchY5Aku1PvTtktESpSDPWg0fr1PSoTSzP9KGPgGXCJ2xk4nFxetQoJ HY2ztKq5RLozFbgD2Nmw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rUArvIhY/9eOzpA1sULP/WLQml7HsswCXEHDf93pOXvjFHtEZbcBaGE3kX68Hiskn2 1zbyf2yg53TKS48eZBFQ== Received: by 10.150.162.2 with SMTP id k2mr904839ybe.10.1302719589187; Wed, 13 Apr 2011 11:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Wed, 13 Apr 2011 11:32:49 -0700 (PDT) In-Reply-To: <4DA5CC19.8070201@warmcat.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> <000201cbf9f0$77786fc0$66694f40$@noemax.com> <4DA5CC19.8070201@warmcat.com> From: John Tamplin Date: Wed, 13 Apr 2011 14:32:49 -0400 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=000e0cd60ae45b06cd04a0d10a0f X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:33:13 -0000 --000e0cd60ae45b06cd04a0d10a0f Content-Type: text/plain; charset=UTF-8 On Wed, Apr 13, 2011 at 12:15 PM, Andy Green wrote: > > I would say that negotiating the max message size is not a requirement, but >> it would definitely be a good-to-have feature. >> Support for this feature could be optional, but the feature itself should >> be >> in the standard so that everyone who supports it does so in an >> interoperable >> manner. >> > > Yeah it makes sense to define it, unlike frame MTU case. > It seems hard to imagine how an endpoint would determine this value, and it goes back to when we were discussing sending the total message length in the initial frame. If I am going to convert text messages to UTF16, how do I know what to advertise as my maximum message length? Do I play it conservative, assuming that all text messages are US-ASCII, so I send floor(bufsize/2)? Do I assume the best case of floor(bufsize*3/2) [fitting 3-byte UTF8 characters in one UTF16 character] so a message that might fit won't be rejected? Do I assume some probabilistic value based on the expected distribution of characters in received messages? If I just allocate buffers from the heap, how can I get a reasonable value for this maximum message size? Even if I can, how can one value be correct for the life of the connection, as other things will be using/freeing heap unrelated to the WebSocket message stream. If I am a busy server handling lots of connections, It seems likely that if such a message size limit were required, endpoints would simply pick some arbitrary value and advertise that, and I don't think that is any better than not advertising any value. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd60ae45b06cd04a0d10a0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 13, 2011 at 12:15 PM, Andy Green <andy@warmcat.com= > wrote:
I would say that negotiati= ng the max message size is not a requirement, but
it would definitely be a good-to-have feature.
Support for this feature could be optional, but the feature itself should b= e
in the standard so that everyone who supports it does so in an interoperabl= e
manner.

Yeah it makes sense to define it, unlike frame MTU case.

It seems hard to imagine how an endpoint would determine this value, and = it goes back to when we were discussing sending the total message length in= the initial frame.

If I am going to convert text messages to UTF16, how do I kn= ow what to advertise as my maximum message length? =C2=A0Do I play it conse= rvative, assuming that all text messages are US-ASCII, so I send floor(bufs= ize/2)? =C2=A0Do I assume the best case of floor(bufsize*3/2) [fitting 3-by= te UTF8 characters in one UTF16 character] so a message that might fit won&= #39;t be rejected? =C2=A0Do I assume some probabilistic value based on the = expected distribution of characters in received messages?

If I just allocate buffers from the heap, how can I get= a reasonable value for this maximum message size? =C2=A0Even if I can, how= can one value be correct for the life of the connection, as other things w= ill be using/freeing heap unrelated to the WebSocket message stream. =C2=A0= If I am a busy server handling lots of connections,=C2=A0

It seems likely that if such a message size limit were requi= red, endpoints would simply pick some arbitrary value and advertise that, a= nd I don't think that is any better than not advertising any value.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd60ae45b06cd04a0d10a0f-- From andy.warmcat.com@googlemail.com Wed Apr 13 12:00:17 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C4B4E098E for ; Wed, 13 Apr 2011 12:00:17 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJDiAqFis33F for ; Wed, 13 Apr 2011 12:00:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 4EC05E08D9 for ; Wed, 13 Apr 2011 12:00:09 -0700 (PDT) Received: by wyb29 with SMTP id 29so854119wyb.31 for ; Wed, 13 Apr 2011 12:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W5OH4ewjng16pxNPdfTCGjOhiqjk2CBqCTdDpJ+c8V4=; b=OZFZlsmKMo8ad+jeCe/euX7QCX6HzVUShabdQBvggZYfH/vg3kTAl5XbvuBQDn+nmq 0WKVyjSzM444+mv7coRX1KZdAtuBoF8kOQ+C2TbKiC1tykUBTmCu2Kxbhryud8ftKrRJ 7+3TskqCfVTlVwmvzENN9joOB7Tm8au4U4OmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oop66BYSwiYYSvlGqo32qXmrkyA+WdvJmFLG8ZhyDIngfVqIQAk/7IqVARP8HCLWSc D1j5D+LVLTY120o76tnpFAQqvfT0pqT6q/15EYp06FjAZXm3btMwOrCMQfq/FMHc/Ijp 2B8DRYbhZAU0ik6VEbNeqv0bc39K6YqI7LJ0o= Received: by 10.216.240.197 with SMTP id e47mr1787025wer.11.1302721206696; Wed, 13 Apr 2011 12:00:06 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id z13sm517897wbd.63.2011.04.13.12.00.04 (version=SSLv3 cipher=OTHER); Wed, 13 Apr 2011 12:00:05 -0700 (PDT) Sender: Andy Green Message-ID: <4DA5F2B3.1090303@warmcat.com> Date: Wed, 13 Apr 2011 20:00:03 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Tamplin References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> <000201cbf9f0$77786fc0$66694f40$@noemax.com> <4DA5CC19.8070201@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , Greg Wilkins Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:00:17 -0000 On 04/13/2011 07:32 PM, Somebody in the thread at some point said: Hi - > Yeah it makes sense to define it, unlike frame MTU case. > > It seems hard to imagine how an endpoint would determine this value, and > it goes back to when we were discussing sending the total message length > in the initial frame. > > If I am going to convert text messages to UTF16, how do I know what to > advertise as my maximum message length? Do I play it conservative, If a peer has already 'picked a static number' for what they're willing to malloc on one connection, since no peer doing buffering as in browser case can live up to infinite message length, they might as well tell it to the peer. > If I just allocate buffers from the heap, how can I get a reasonable > value for this maximum message size? Even if I can, how can one value > be correct for the life of the connection, as other things will be > using/freeing heap unrelated to the WebSocket message stream. If I am a > busy server handling lots of connections, Right but I already made this point twice, that telling your maximum is not the same as guaranteeing that anything below will pass. Yet still telling the maximum could have value if the sender can adapt to the knowledge, since the alternative is you waste time sending up to the limit and then your connection is dropped. > It seems likely that if such a message size limit were required, > endpoints would simply pick some arbitrary value and advertise that, and > I don't think that is any better than not advertising any value. I think the missing ingredient is peers that are buffering the message locally absolutely cannot tolerate infinite message length the protocol allows since it lets a remote peer kill its partner. So they will take action at some point to close the connection wasting what was sent. So you may as well tell the other side, at best, you can never send me a message of more than that amount. Trying to start the message with length indication is no help either since it may be a stream the sender does not know the length of. In the end the receiving peer is always the guy that decides if and when he has had enough in part with a possible static sanity limit and in part dynamically because his malloc for the next bit failed. -Andy From salvatore.loreto@ericsson.com Wed Apr 13 12:31:22 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B175E07CB for ; Wed, 13 Apr 2011 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwK91hxO50dy for ; Wed, 13 Apr 2011 12:31:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 40870E065C for ; Wed, 13 Apr 2011 12:31:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-d9-4da5fa07f599 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B3.2F.11171.70AF5AD4; Wed, 13 Apr 2011 21:31:19 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Apr 2011 21:31:19 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 310F22329; Wed, 13 Apr 2011 22:31:19 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EE4A150BB2; Wed, 13 Apr 2011 22:31:18 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 36928507E8; Wed, 13 Apr 2011 22:31:18 +0300 (EEST) Message-ID: <4DA5FA07.9010305@ericsson.com> Date: Wed, 13 Apr 2011 21:31:19 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------010001000903050607070709" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: SM Subject: [hybi] Masking alternatives: consensus declaration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:31:22 -0000 --------------010001000903050607070709 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, Thanks everybody for your participation in the "Masking alternatives" discussion and for providing feedback on alternatives. We have highly appreciated the fact that people have shown a great deal of flexibility in this respect. Folks do have preferences (sometimes strong) one way or the other, but have expressed that they could live with the other. This is essential in terms of the larger practical issue of needing to resolve issues, and moving on towards a protocol version that is stable enough for working group last call. In light of this mail discussion, the Prague meeting and other side mail threads, Gabriel and I, as wg chairs, are declaring a rough consensus on option #2 (masking-after-length). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|R| Payload len | Extended payload length | |I|S|S|S| (4) |S| (7) | (16/63) | |N|V|V|V| |V| | (if payload len==126/127) | | |1|2|3| |4| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | | Masking-key | +---------------------------------------------------------------+ | Masking-key (continued) | Extension data | +-------------------------------+ - - - - - - - - - - - - - - - + : : +---------------------------------------------------------------+ : Application data : +---------------------------------------------------------------+ Our reading of the list discussion is that WG participants prefer option #2 because: 1. It allows for better scalability in intermediaries as they do not need necessarily to unmask the header unless they want to begin frame inspection and processing. 2. It allows for a slightly less complex software design. 3. It paves the way for improved per-frame compression later on to be applied on the payload before masking. 4. The additional attack vector via exposure of the bits in the header is thought to be minimal. cheers Gabriel and Salvatore --------------010001000903050607070709 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi there,

Thanks everybody for your participation in the "Masking alternatives" discussion
and for providing feedback on alternatives.

We have highly appreciated the fact that people have shown a great deal of flexibility in this respect.
Folks do have preferences (sometimes strong) one way or the other,
but have expressed that they could live with the other.
This is essential in terms of the larger practical issue of needing to resolve issues,
and moving on towards a protocol version that is stable enough for working group last call.
 
In light of this mail discussion, the Prague meeting and other side mail threads,
Gabriel and I, as wg chairs, are declaring a rough consensus on option #2 (masking-after-length).

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|R| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
     |N|V|V|V|       |V|             |   (if payload len==126/127)   |
     | |1|2|3|       |4|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |         Masking-key           |
     +---------------------------------------------------------------+
     |    Masking-key (continued)    |         Extension data        |
     +-------------------------------+ - - - - - - - - - - - - - - - +
     :                                                               :
     +---------------------------------------------------------------+
     :                       Application data                        :
     +---------------------------------------------------------------+ 


Our reading of the list discussion is that WG participants prefer option #2 because:

1. It allows for better scalability in intermediaries as they do not
need necessarily to unmask the header unless they want to begin frame
inspection and processing.

2. It allows for a slightly less complex software design.

3. It paves the way for improved per-frame compression later on to be
applied on the payload before masking.

4. The additional attack vector via exposure of the bits in the header
is thought to be minimal.
cheers
Gabriel and Salvatore --------------010001000903050607070709-- From theturtle32@gmail.com Wed Apr 13 12:44:30 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D339E07CB for ; Wed, 13 Apr 2011 12:44:30 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQBUsnh2+mNn for ; Wed, 13 Apr 2011 12:44:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfc.amsl.com (Postfix) with ESMTP id 507B3E075D for ; Wed, 13 Apr 2011 12:44:29 -0700 (PDT) Received: by pzk30 with SMTP id 30so427888pzk.31 for ; Wed, 13 Apr 2011 12:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cs/YC/pNnXPKkRC/otreYzp3BfTN8uTeI7+8y7HJvMM=; b=uGMF8XFfJnFrELdDnPwg21GuzzMTHR+mEFNpb6jYfR9yCD496fPhCNOceZ31oRnnup t6sEUqy0hR9IC7jLSudUIHaQ+M15ODbDjmbKgrd+PXbeTpQeCc7FPYleuMBvB06PGY9r PQ0blt1eFiY7DivlHmYjv0hEUJ8lewO4fdTlc= 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:content-transfer-encoding; b=i+tZcmxOAQ+d3vTK5MQV7Lzyi0xMcqwRJbgHprVe8jFEYXZXdLZl8e+VjOpfQ523pI EGoUBGm5mtyfbDohR7AWDlbOLZTzXmjzM9SEB4LDK0ySXqdzsY8wacnp3QA0iZBocfC8 NW4MSYUM0z4mguT4qT6PJLWcRRgxQKOYRrt6Y= MIME-Version: 1.0 Received: by 10.142.171.4 with SMTP id t4mr3044165wfe.434.1302723868378; Wed, 13 Apr 2011 12:44:28 -0700 (PDT) Received: by 10.68.44.67 with HTTP; Wed, 13 Apr 2011 12:44:28 -0700 (PDT) In-Reply-To: <4DA5FA07.9010305@ericsson.com> References: <4DA5FA07.9010305@ericsson.com> Date: Wed, 13 Apr 2011 12:44:28 -0700 Message-ID: From: Brian To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] Masking alternatives: consensus declaration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:44:30 -0000 WooHoo!! Thanks, all, for making this a reality! Brian On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto wrote: > Hi there, > > Thanks everybody for your participation in the "Masking alternatives" > discussion > and for providing feedback on alternatives. > > We have highly appreciated the fact that people have shown a great deal o= f > flexibility in this respect. > Folks do have preferences (sometimes strong) one way or the other, > but have expressed that they could live with the other. > This is essential in terms of the larger practical issue of needing to > resolve issues, > and moving on towards a protocol version that is stable enough for workin= g > group last call. > > In light of this mail discussion, the Prague meeting and other side mail > threads, > Gabriel and I, as wg chairs, are declaring a rough consensus on option #2 > (masking-after-length). > > =A0=A0=A0=A0=A0 0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A01= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3 > =A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1 > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+---------------------------= ----+ > =A0=A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Extended payload = length=A0=A0=A0 | > =A0=A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0=A0 |=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (16/63)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0 |N|V|V|V|=A0=A0=A0=A0=A0=A0 |V|=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0=A0 (if payload len=3D=3D126/127)=A0=A0 | > =A0=A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - = - - + > =A0=A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued, if payload = len =3D=3D 127=A0 | > =A0=A0=A0=A0 + - - - - - - - - - - - - - - - +---------------------------= ----+ > =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Masking-key=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0 =A0 +-------------------------------------------------------------= --+ > =A0=A0=A0=A0 |=A0=A0=A0 Masking-key (continued)=A0=A0=A0 |=A0=A0=A0=A0=A0= =A0=A0=A0 Extension data=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0 +-------------------------------+ - - - - - - - - - - - - - = - - + > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: > =A0=A0=A0=A0 +-----------------------------------------------------------= ----+ > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Application data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 : > =A0=A0=A0=A0 +-----------------------------------------------------------= ----+ > > Our reading of the list discussion is that WG participants prefer option = #2 > because: > > 1. It allows for better scalability in intermediaries as they do not > need necessarily to unmask the header unless they want to begin frame > inspection and processing. > > 2. It allows for a slightly less complex software design. > > 3. It paves the way for improved per-frame compression later on to be > applied on the payload before masking. > > 4. The additional attack vector via exposure of the bits in the header > is thought to be minimal. > > cheers > Gabriel and Salvatore > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From dendicott@gmail.com Wed Apr 13 13:05:44 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BA94E084E for ; Wed, 13 Apr 2011 13:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZeSBsqQm2aQ for ; Wed, 13 Apr 2011 13:05:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3016AE06BC for ; Wed, 13 Apr 2011 13:05:43 -0700 (PDT) Received: by wyb29 with SMTP id 29so906436wyb.31 for ; Wed, 13 Apr 2011 13:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tixviyjXkgtawsPSlZ/gBiz+PdeJbXOP8cWHrZaoiiU=; b=n8CJnxD9wvx89AXLR+LnRxYMwdhIg6ePp+cI9X7FjnJ+3HLTvn284QTIsC0kxsBfJw SN7NvHy1OliiguF8P2ugA1qxy7pdGFafVKge5vRpwtULcPWzF/hNqmCTPpxIN8B935hO AUDXjcROo4/zOXZ+zKoOclBA+m8fFvoLHAnqE= 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=ZCD6e5HHv1B8+2zFApBXCinPSZPSJzmtgaKjKD0OvFF1ZeEKNa4QgtHh1LNqdA2rKN jtok4v7gUJhPY+3B13V4gE7+T5aDOwF89FWkHYq11/138sEhnPpR75qn9zVSrFN4tdIR RLvPBgXncolGQBsEurdBaY8FgZLoKprCU/K28= MIME-Version: 1.0 Received: by 10.216.82.77 with SMTP id n55mr1930932wee.52.1302725142330; Wed, 13 Apr 2011 13:05:42 -0700 (PDT) Received: by 10.216.244.205 with HTTP; Wed, 13 Apr 2011 13:05:42 -0700 (PDT) In-Reply-To: References: <4DA5FA07.9010305@ericsson.com> Date: Wed, 13 Apr 2011 16:05:42 -0400 Message-ID: From: David Endicott To: Brian Content-Type: multipart/alternative; boundary=0016e6de1542593f2e04a0d25579 Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] Masking alternatives: consensus declaration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:05:44 -0000 --0016e6de1542593f2e04a0d25579 Content-Type: text/plain; charset=ISO-8859-1 Don't you mean.... Masking Key: WooHoo!! Content: 03 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 77 02 0E 23 06 01 46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00 On Wed, Apr 13, 2011 at 3:44 PM, Brian wrote: > WooHoo!! > > Thanks, all, for making this a reality! > > Brian > > On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto > wrote: > > Hi there, > > > > Thanks everybody for your participation in the "Masking alternatives" > > discussion > > and for providing feedback on alternatives. > > > > We have highly appreciated the fact that people have shown a great deal > of > > flexibility in this respect. > > Folks do have preferences (sometimes strong) one way or the other, > > but have expressed that they could live with the other. > > This is essential in terms of the larger practical issue of needing to > > resolve issues, > > and moving on towards a protocol version that is stable enough for > working > > group last call. > > > > In light of this mail discussion, the Prague meeting and other side mail > > threads, > > Gabriel and I, as wg chairs, are declaring a rough consensus on option #2 > > (masking-after-length). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-------+-+-------------+-------------------------------+ > > |F|R|R|R| opcode|R| Payload len | Extended payload length | > > |I|S|S|S| (4) |S| (7) | (16/63) | > > |N|V|V|V| |V| | (if payload len==126/127) | > > | |1|2|3| |4| | | > > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > > | Extended payload length continued, if payload len == 127 | > > + - - - - - - - - - - - - - - - +-------------------------------+ > > | | Masking-key | > > +---------------------------------------------------------------+ > > | Masking-key (continued) | Extension data | > > +-------------------------------+ - - - - - - - - - - - - - - - + > > : : > > +---------------------------------------------------------------+ > > : Application data : > > +---------------------------------------------------------------+ > > > > Our reading of the list discussion is that WG participants prefer option > #2 > > because: > > > > 1. It allows for better scalability in intermediaries as they do not > > need necessarily to unmask the header unless they want to begin frame > > inspection and processing. > > > > 2. It allows for a slightly less complex software design. > > > > 3. It paves the way for improved per-frame compression later on to be > > applied on the payload before masking. > > > > 4. The additional attack vector via exposure of the bits in the header > > is thought to be minimal. > > > > cheers > > Gabriel and Salvatore > > _______________________________________________ > > 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 > --0016e6de1542593f2e04a0d25579 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Don't you mean....

Masking Key: =A0WooHoo!!

Content:=A003 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 = 77 02 0E 23 06 01 46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00


On Wed, Apr 13, 2011 at 3:44 PM, Br= ian <theturtl= e32@gmail.com> wrote:
WooHoo!!

Thanks, all, for making this a reality!

Brian

On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto
<salvatore.loreto@erics= son.com> wrote:
> Hi there,
>
> Thanks everybody for your participation in the "Masking alternati= ves"
> discussion
> and for providing feedback on alternatives.
>
> We have highly appreciated the fact that people have shown a great dea= l of
> flexibility in this respect.
> Folks do have preferences (sometimes strong) one way or the other,
> but have expressed that they could live with the other.
> This is essential in terms of the larger practical issue of needing to=
> resolve issues,
> and moving on towards a protocol version that is stable enough for wor= king
> group last call.
>
> In light of this mail discussion, the Prague meeting and other side ma= il
> threads,
> Gabriel and I, as wg chairs, are declaring a rough consensus on option= #2
> (masking-after-length).
>
> =A0=A0=A0=A0=A0 0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3
> =A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
> =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+------------------------= -------+
> =A0=A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Extended paylo= ad length=A0=A0=A0 |
> =A0=A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0=A0 |=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (16/63)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0 |N|V|V|V|=A0=A0=A0=A0=A0=A0 |V|=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0 (if payload len=3D=3D126/127)=A0=A0 |
> =A0=A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
> =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - -= - - - +
> =A0=A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued, if paylo= ad len =3D=3D 127=A0 |
> =A0=A0=A0=A0 + - - - - - - - - - - - - - - - +------------------------= -------+
> =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Masking-key= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
> =A0=A0 =A0 +----------------------------------------------------------= -----+
> =A0=A0=A0=A0 |=A0=A0=A0 Masking-key (continued)=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0 Extension data=A0=A0=A0=A0=A0=A0=A0 |
> =A0=A0=A0=A0 +-------------------------------+ - - - - - - - - - - - -= - - - +
> =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:
> =A0=A0=A0=A0 +--------------------------------------------------------= -------+
> =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Application data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 :
> =A0=A0=A0=A0 +--------------------------------------------------------= -------+
>
> Our reading of the list discussion is that WG participants prefer opti= on #2
> because:
>
> 1. It allows for better scalability in intermediaries as they do not > need necessarily to unmask the header unless they want to begin frame<= br> > inspection and processing.
>
> 2. It allows for a slightly less complex software design.
>
> 3. It paves the way for improved per-frame compression later on to be<= br> > applied on the payload before masking.
>
> 4. The additional attack vector via exposure of the bits in the header=
> is thought to be minimal.
>
> cheers
> Gabriel and Salvatore
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016e6de1542593f2e04a0d25579-- From theturtle32@gmail.com Wed Apr 13 13:24:14 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CABF3E075A for ; Wed, 13 Apr 2011 13:24:14 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtvW9U1vbzif for ; Wed, 13 Apr 2011 13:24:13 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 9E8C5E05F5 for ; Wed, 13 Apr 2011 13:24:13 -0700 (PDT) Received: by pxi20 with SMTP id 20so599061pxi.27 for ; Wed, 13 Apr 2011 13:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z6oN8+xI4OkLVAltaDW5xhVayZefkK+aVQwQr8szuGg=; b=NKLms+kI9RO64SZELfmIR0NyoLJa7kqmGEFI7EyVVcvldQw08I5Flhe+j/GnwlBt/L gKOReukye69H/lOyRCCt6pGK1qAyHk6WFzkSKA9SdJ1AFdGj8p2FfZcbNXaJ2/lT0jFV IWCn4gzuZPQP0qqvl/IU5QUvXb8yFZJPvcInI= 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:content-transfer-encoding; b=XbX7Covu3TKfibVTTYBfCR/w9Py+RII9mkqmL70B8TMaJqXbnOoIpmdnwcL7FmKrQR oDKPaZNVWYOeMNb4HRyDFy538H0j+lyflhoZMm7hJZv1gQCArbeDqB5wiarLDv2JKtzr SUGvFobVJYsc5YtjTCHFGycmtfVT5ZML98Ghk= MIME-Version: 1.0 Received: by 10.142.9.9 with SMTP id 9mr7626978wfi.149.1302726252853; Wed, 13 Apr 2011 13:24:12 -0700 (PDT) Received: by 10.68.44.67 with HTTP; Wed, 13 Apr 2011 13:24:12 -0700 (PDT) In-Reply-To: References: <4DA5FA07.9010305@ericsson.com> Date: Wed, 13 Apr 2011 13:24:12 -0700 Message-ID: From: Brian To: David Endicott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] Masking alternatives: consensus declaration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:24:14 -0000 No, I suppose I mean: Masking Key: 03 07 0E 26 Content: 54 68 61 6E 6C 68 2F Brian On Wed, Apr 13, 2011 at 1:05 PM, David Endicott wrote= : > Don't you mean.... > Masking Key: =A0WooHoo!! > Content:=A003 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 77 02 0E 23 06= 01 > 46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00 > > On Wed, Apr 13, 2011 at 3:44 PM, Brian wrote: >> >> WooHoo!! >> >> Thanks, all, for making this a reality! >> >> Brian >> >> On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto >> wrote: >> > Hi there, >> > >> > Thanks everybody for your participation in the "Masking alternatives" >> > discussion >> > and for providing feedback on alternatives. >> > >> > We have highly appreciated the fact that people have shown a great dea= l >> > of >> > flexibility in this respect. >> > Folks do have preferences (sometimes strong) one way or the other, >> > but have expressed that they could live with the other. >> > This is essential in terms of the larger practical issue of needing to >> > resolve issues, >> > and moving on towards a protocol version that is stable enough for >> > working >> > group last call. >> > >> > In light of this mail discussion, the Prague meeting and other side ma= il >> > threads, >> > Gabriel and I, as wg chairs, are declaring a rough consensus on option >> > #2 >> > (masking-after-length). >> > >> > =A0=A0=A0=A0=A0 0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3 >> > =A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 >> > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+------------------------= -------+ >> > =A0=A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Extended paylo= ad length=A0=A0=A0 | >> > =A0=A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0=A0 |=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (16/63)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >> > =A0=A0=A0=A0 |N|V|V|V|=A0=A0=A0=A0=A0=A0 |V|=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0 (if payload len=3D=3D126/127)=A0=A0 | >> > =A0=A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >> > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - -= - - - + >> > =A0=A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued, if paylo= ad len =3D=3D 127=A0 | >> > =A0=A0=A0=A0 + - - - - - - - - - - - - - - - +------------------------= -------+ >> > =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Masking-key= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | >> > =A0=A0 =A0 +----------------------------------------------------------= -----+ >> > =A0=A0=A0=A0 |=A0=A0=A0 Masking-key (continued)=A0=A0=A0 |=A0=A0=A0=A0= =A0=A0=A0=A0 Extension data=A0=A0=A0=A0=A0=A0=A0 | >> > =A0=A0=A0=A0 +-------------------------------+ - - - - - - - - - - - -= - - - + >> > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: >> > =A0=A0=A0=A0 +--------------------------------------------------------= -------+ >> > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Application data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 : >> > =A0=A0=A0=A0 +--------------------------------------------------------= -------+ >> > >> > Our reading of the list discussion is that WG participants prefer opti= on >> > #2 >> > because: >> > >> > 1. It allows for better scalability in intermediaries as they do not >> > need necessarily to unmask the header unless they want to begin frame >> > inspection and processing. >> > >> > 2. It allows for a slightly less complex software design. >> > >> > 3. It paves the way for improved per-frame compression later on to be >> > applied on the payload before masking. >> > >> > 4. The additional attack vector via exposure of the bits in the header >> > is thought to be minimal. >> > >> > cheers >> > Gabriel and Salvatore >> > _______________________________________________ >> > 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 dendicott@gmail.com Wed Apr 13 13:32:16 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 100DEE075A for ; Wed, 13 Apr 2011 13:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAGiAgn9mLio for ; Wed, 13 Apr 2011 13:32:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 6AA54E05F5 for ; Wed, 13 Apr 2011 13:32:14 -0700 (PDT) Received: by wyb29 with SMTP id 29so926062wyb.31 for ; Wed, 13 Apr 2011 13:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+G2L1DGwoo6R4sS219wZlPIOY4LvcVnDWcXJRIKpWfU=; b=UP1xS1PgKuLof5Ehdyjz2iIEpSsFq85RCfcQtPn3NRbphuRVgpzhVcYHHm3hsBbbnQ VrJHN1J+IZmAvh9yQdy3Qs58lhmN7sSPJeckniTOm2JevxGHMqrZXLXPo1dJOti0X1JB VMAMhMhP0VbvaX9Qjs3hOyeObLpdsBuVCbrdg= 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=jNYsuqJMcFI8VsqaiR2IWQgj1S+tJvi4UNBGIOO+MOf1ioo9nb9kAY0vlGJlOj+Fpp 4FnNIM6EmDcUTd3ZMiKroxna+3yMwC9cDQsN+oN9Bv1noOzC8acC5ZdKfPJyN24L6mK3 dX/pcfqfNf088N85PGURlsuPY7MNUGMUo8xVc= MIME-Version: 1.0 Received: by 10.216.241.66 with SMTP id f44mr2777751wer.37.1302726733613; Wed, 13 Apr 2011 13:32:13 -0700 (PDT) Received: by 10.216.244.205 with HTTP; Wed, 13 Apr 2011 13:32:13 -0700 (PDT) In-Reply-To: References: <4DA5FA07.9010305@ericsson.com> Date: Wed, 13 Apr 2011 16:32:13 -0400 Message-ID: From: David Endicott To: Brian Content-Type: multipart/alternative; boundary=e0cb4e43d2d3324a2a04a0d2b49b Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] Masking alternatives: consensus declaration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:32:16 -0000 --e0cb4e43d2d3324a2a04a0d2b49b Content-Type: text/plain; charset=ISO-8859-1 Masking Key: 00 00 00 00 Content: 49 6E 64 65 65 64 2E 20 20 41 6E 64 20 72 65 6D 65 6D 62 65 72 20 6E 6F 74 20 74 6F 20 75 73 65 20 6C 61 6D 65 20 6D 61 73 6B 69 6E 67 20 6B 65 79 73 2E On Wed, Apr 13, 2011 at 4:24 PM, Brian wrote: > No, I suppose I mean: > > Masking Key: 03 07 0E 26 > Content: 54 68 61 6E 6C 68 2F > > > Brian > > > On Wed, Apr 13, 2011 at 1:05 PM, David Endicott > wrote: > > Don't you mean.... > > Masking Key: WooHoo!! > > Content: 03 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 77 02 0E 23 06 > 01 > > 46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00 > > > > On Wed, Apr 13, 2011 at 3:44 PM, Brian wrote: > >> > >> WooHoo!! > >> > >> Thanks, all, for making this a reality! > >> > >> Brian > >> > >> On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto > >> wrote: > >> > Hi there, > >> > > >> > Thanks everybody for your participation in the "Masking alternatives" > >> > discussion > >> > and for providing feedback on alternatives. > >> > > >> > We have highly appreciated the fact that people have shown a great > deal > >> > of > >> > flexibility in this respect. > >> > Folks do have preferences (sometimes strong) one way or the other, > >> > but have expressed that they could live with the other. > >> > This is essential in terms of the larger practical issue of needing to > >> > resolve issues, > >> > and moving on towards a protocol version that is stable enough for > >> > working > >> > group last call. > >> > > >> > In light of this mail discussion, the Prague meeting and other side > mail > >> > threads, > >> > Gabriel and I, as wg chairs, are declaring a rough consensus on option > >> > #2 > >> > (masking-after-length). > >> > > >> > 0 1 2 3 > >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> > +-+-+-+-+-------+-+-------------+-------------------------------+ > >> > |F|R|R|R| opcode|R| Payload len | Extended payload length | > >> > |I|S|S|S| (4) |S| (7) | (16/63) | > >> > |N|V|V|V| |V| | (if payload len==126/127) | > >> > | |1|2|3| |4| | | > >> > +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + > >> > | Extended payload length continued, if payload len == 127 | > >> > + - - - - - - - - - - - - - - - +-------------------------------+ > >> > | | Masking-key | > >> > +---------------------------------------------------------------+ > >> > | Masking-key (continued) | Extension data | > >> > +-------------------------------+ - - - - - - - - - - - - - - - + > >> > : : > >> > +---------------------------------------------------------------+ > >> > : Application data : > >> > +---------------------------------------------------------------+ > >> > > >> > Our reading of the list discussion is that WG participants prefer > option > >> > #2 > >> > because: > >> > > >> > 1. It allows for better scalability in intermediaries as they do not > >> > need necessarily to unmask the header unless they want to begin frame > >> > inspection and processing. > >> > > >> > 2. It allows for a slightly less complex software design. > >> > > >> > 3. It paves the way for improved per-frame compression later on to be > >> > applied on the payload before masking. > >> > > >> > 4. The additional attack vector via exposure of the bits in the header > >> > is thought to be minimal. > >> > > >> > cheers > >> > Gabriel and Salvatore > >> > _______________________________________________ > >> > 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 > > > > > --e0cb4e43d2d3324a2a04a0d2b49b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Masking Key: 00 00 00 00

Content: =A049 6E 64 65 6= 5 64 2E 20 20 41 6E 64 20 72 65 6D 65 6D 62 65 72 20 6E 6F 74 20 74 6F 20 7= 5 73 65 20 6C 61 6D 65 20 6D 61 73 6B 69 6E 67 20 6B 65 79 73 2E


On Wed, Apr 13, 2011 at 4:24 PM, Brian <theturtle32@gmail= .com> wrote:
No, I suppose I mean:

Masking Key: 03 07 0E 26
Content: 54 68 61 6E 6C 68 2F


Brian


On Wed, Apr 13, 2011 at 1:05 PM, David Endicott <dendicott@gmail.com> wrote:
> Don't you mean....
> Masking Key: =A0WooHoo!!
> Content:=A003 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 77 02 0E 23= 06 01
> 46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00
>
> On Wed, Apr 13, 2011 at 3:44 PM, Brian <theturtle32@gmail.com> wrote:
>>
>> WooHoo!!
>>
>> Thanks, all, for making this a reality!
>>
>> Brian
>>
>> On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto
>> <salvatore.lor= eto@ericsson.com> wrote:
>> > Hi there,
>> >
>> > Thanks everybody for your participation in the "Masking = alternatives"
>> > discussion
>> > and for providing feedback on alternatives.
>> >
>> > We have highly appreciated the fact that people have shown a = great deal
>> > of
>> > flexibility in this respect.
>> > Folks do have preferences (sometimes strong) one way or the o= ther,
>> > but have expressed that they could live with the other.
>> > This is essential in terms of the larger practical issue of n= eeding to
>> > resolve issues,
>> > and moving on towards a protocol version that is stable enoug= h for
>> > working
>> > group last call.
>> >
>> > In light of this mail discussion, the Prague meeting and othe= r side mail
>> > threads,
>> > Gabriel and I, as wg chairs, are declaring a rough consensus = on option
>> > #2
>> > (masking-after-length).
>> >
>> > =A0=A0=A0=A0=A0 0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3
>> > =A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
>> > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+---------------= ----------------+
>> > =A0=A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Exten= ded payload length=A0=A0=A0 |
>> > =A0=A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (16/63)=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 |
>> > =A0=A0=A0=A0 |N|V|V|V|=A0=A0=A0=A0=A0=A0 |V|=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0 (if payload len=3D=3D126/127)=A0=A0 |
>> > =A0=A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>> > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - = - - - - - - - - +
>> > =A0=A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued,= if payload len =3D=3D 127=A0 |
>> > =A0=A0=A0=A0 + - - - - - - - - - - - - - - - +---------------= ----------------+
>> > =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Mas= king-key=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
>> > =A0=A0 =A0 +-------------------------------------------------= --------------+
>> > =A0=A0=A0=A0 |=A0=A0=A0 Masking-key (continued)=A0=A0=A0 |=A0= =A0=A0=A0=A0=A0=A0=A0 Extension data=A0=A0=A0=A0=A0=A0=A0 |
>> > =A0=A0=A0=A0 +-------------------------------+ - - - - - - - = - - - - - - - - +
>> > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:
>> > =A0=A0=A0=A0 +-----------------------------------------------= ----------------+
>> > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Application data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 :
>> > =A0=A0=A0=A0 +-----------------------------------------------= ----------------+
>> >
>> > Our reading of the list discussion is that WG participants pr= efer option
>> > #2
>> > because:
>> >
>> > 1. It allows for better scalability in intermediaries as they= do not
>> > need necessarily to unmask the header unless they want to beg= in frame
>> > inspection and processing.
>> >
>> > 2. It allows for a slightly less complex software design.
>> >
>> > 3. It paves the way for improved per-frame compression later = on to be
>> > applied on the payload before masking.
>> >
>> > 4. The additional attack vector via exposure of the bits in t= he header
>> > is thought to be minimal.
>> >
>> > cheers
>> > Gabriel and Salvatore
>> > _______________________________________________
>> > 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
>
>

--e0cb4e43d2d3324a2a04a0d2b49b-- From theturtle32@gmail.com Wed Apr 13 13:39:09 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFC7AE0824 for ; Wed, 13 Apr 2011 13:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2sFBHxzNUye for ; Wed, 13 Apr 2011 13:39:08 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id B79A8E081A for ; Wed, 13 Apr 2011 13:38:47 -0700 (PDT) Received: by pwi5 with SMTP id 5so481622pwi.31 for ; Wed, 13 Apr 2011 13:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CbdYTMtuqKcQ7WcSixRiMSPyRKskXG6VvP6cwzvDDlc=; b=MGmudtIvymJBbv6pz2uWfnM0gUlXqWCia9EbxqNhKtNiiHg7AZUCi4OhpWCygxfH3N PpBOvxG/K9uTCX1UTt12E4oA3D+pgVNEzjq/Rf5aALA61oDqyrPdNBgcpfVAqmfV3Bbn oIx2mJDhD1bpiFskLgElqjjKigHis4QSSfILE= 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:content-transfer-encoding; b=Sq47T/hMUT3H+UqmraW6UvoqCDYDvxg1wmLcmIw03Id/KuIyJHJuagkasHsGuIhb72 rQn2aM19MEjdKnpN7Y5kVvfwRPK3xoi2DLT+DlQ74qy0vsueIBdTDACjzh2R1DbZ9BVZ 4Nqy9cPfnOunhy6dweKOcsf561/Bc6Y8HFVlc= MIME-Version: 1.0 Received: by 10.142.171.4 with SMTP id t4mr3091690wfe.434.1302727126020; Wed, 13 Apr 2011 13:38:46 -0700 (PDT) Received: by 10.68.44.67 with HTTP; Wed, 13 Apr 2011 13:38:45 -0700 (PDT) In-Reply-To: References: <4DA5FA07.9010305@ericsson.com> Date: Wed, 13 Apr 2011 13:38:46 -0700 Message-ID: From: Brian To: David Endicott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , SM Subject: Re: [hybi] Masking alternatives: consensus declaration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:39:10 -0000 Indeed! #!/usr/bin/env node var data=3D"49 6E 64 65 65 64 2E 20 20 41 6E 64 20 72 65 6D 65 6D 62 65 72 20 6E 6F 74 20 74 6F 20 75 73 65 20 6C 61 6D 65 20 6D 61 73 6B 69 6E 67 20 6B 65 79 73 2E"; var bytes =3D data.split(' ').map(function(byte) { return parseInt(byte, 16); }); console.log((new Buffer(bytes)).toString('utf8')); // Indeed. And remember not to use lame masking keys. On Wed, Apr 13, 2011 at 1:32 PM, David Endicott wrote= : > Masking Key: 00 00 00 00 > Content: =A049 6E 64 65 65 64 2E 20 20 41 6E 64 20 72 65 6D 65 6D 62 65 7= 2 20 > 6E 6F 74 20 74 6F 20 75 73 65 20 6C 61 6D 65 20 6D 61 73 6B 69 6E 67 20 6= B > 65 79 73 2E > > > On Wed, Apr 13, 2011 at 4:24 PM, Brian wrote: >> >> No, I suppose I mean: >> >> Masking Key: 03 07 0E 26 >> Content: 54 68 61 6E 6C 68 2F >> >> >> Brian >> >> >> On Wed, Apr 13, 2011 at 1:05 PM, David Endicott >> wrote: >> > Don't you mean.... >> > Masking Key: =A0WooHoo!! >> > Content:=A003 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 77 02 0E 23= 06 >> > 01 >> > 46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00 >> > >> > On Wed, Apr 13, 2011 at 3:44 PM, Brian wrote: >> >> >> >> WooHoo!! >> >> >> >> Thanks, all, for making this a reality! >> >> >> >> Brian >> >> >> >> On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto >> >> wrote: >> >> > Hi there, >> >> > >> >> > Thanks everybody for your participation in the "Masking alternative= s" >> >> > discussion >> >> > and for providing feedback on alternatives. >> >> > >> >> > We have highly appreciated the fact that people have shown a great >> >> > deal >> >> > of >> >> > flexibility in this respect. >> >> > Folks do have preferences (sometimes strong) one way or the other, >> >> > but have expressed that they could live with the other. >> >> > This is essential in terms of the larger practical issue of needing >> >> > to >> >> > resolve issues, >> >> > and moving on towards a protocol version that is stable enough for >> >> > working >> >> > group last call. >> >> > >> >> > In light of this mail discussion, the Prague meeting and other side >> >> > mail >> >> > threads, >> >> > Gabriel and I, as wg chairs, are declaring a rough consensus on >> >> > option >> >> > #2 >> >> > (masking-after-length). >> >> > >> >> > =A0=A0=A0=A0=A0 0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3 >> >> > =A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5= 6 7 8 9 0 1 >> >> > >> >> > +-+-+-+-+-------+-+-------------+-------------------------------+ >> >> > =A0=A0=A0=A0 |F|R|R|R| opcode|R| Payload len |=A0=A0=A0 Extended pa= yload length >> >> > | >> >> > =A0=A0=A0=A0 |I|S|S|S|=A0 (4)=A0 |S|=A0=A0=A0=A0 (7)=A0=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (16/63) >> >> > | >> >> > =A0=A0=A0=A0 |N|V|V|V|=A0=A0=A0=A0=A0=A0 |V|=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |=A0=A0 (if payload len=3D=3D126/127) >> >> > | >> >> > =A0=A0=A0=A0 | |1|2|3|=A0=A0=A0=A0=A0=A0 |4|=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 | >> >> > | >> >> > =A0=A0=A0=A0 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - = - - - - - >> >> > + >> >> > =A0=A0=A0=A0 |=A0=A0=A0=A0 Extended payload length continued, if pa= yload len =3D=3D 127 >> >> > | >> >> > =A0=A0=A0=A0 + - - - - - - - - - - - - - - - >> >> > +-------------------------------+ >> >> > =A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Masking-k= ey >> >> > | >> >> > >> >> > +---------------------------------------------------------------+ >> >> > =A0=A0=A0=A0 |=A0=A0=A0 Masking-key (continued)=A0=A0=A0 |=A0=A0=A0= =A0=A0=A0=A0=A0 Extension data >> >> > | >> >> > =A0=A0=A0=A0 +-------------------------------+ - - - - - - - - - - = - - - - - >> >> > + >> >> > =A0=A0=A0=A0 : >> >> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: >> >> > >> >> > +---------------------------------------------------------------+ >> >> > =A0=A0=A0=A0 :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Application data >> >> > : >> >> > >> >> > +---------------------------------------------------------------+ >> >> > >> >> > Our reading of the list discussion is that WG participants prefer >> >> > option >> >> > #2 >> >> > because: >> >> > >> >> > 1. It allows for better scalability in intermediaries as they do no= t >> >> > need necessarily to unmask the header unless they want to begin fra= me >> >> > inspection and processing. >> >> > >> >> > 2. It allows for a slightly less complex software design. >> >> > >> >> > 3. It paves the way for improved per-frame compression later on to = be >> >> > applied on the payload before masking. >> >> > >> >> > 4. The additional attack vector via exposure of the bits in the >> >> > header >> >> > is thought to be minimal. >> >> > >> >> > cheers >> >> > Gabriel and Salvatore >> >> > _______________________________________________ >> >> > 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 ibc@aliax.net Wed Apr 13 16:16:01 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8F5A1E0677 for ; Wed, 13 Apr 2011 16:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPywfkpRMdVw for ; Wed, 13 Apr 2011 16:16:01 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id 058B7E07E7 for ; Wed, 13 Apr 2011 16:16:00 -0700 (PDT) Received: by qwc23 with SMTP id 23so783568qwc.31 for ; Wed, 13 Apr 2011 16:16:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.118.195 with SMTP id w3mr27508qcq.203.1302736560563; Wed, 13 Apr 2011 16:16:00 -0700 (PDT) Received: by 10.229.75.7 with HTTP; Wed, 13 Apr 2011 16:16:00 -0700 (PDT) Date: Thu, 14 Apr 2011 01:16:00 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hybi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] draft-ibc-websocket-dns-srv-02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:16:01 -0000 Hi, a new version of draft-ibc-websocket-dns-srv-02.txt has been posted to the IETF repository: http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 Filename: draft-ibc-websocket-dns-srv Revision: 02 Title: DNS SRV Resource Records for the WebSocket Protocol Creation_date: 2011-04-14 WG ID: Independent Submission Number_of_pages: 16 Abstract: This document specifies the usage of DNS SRV resource records by WebSocket clients when resolving a "ws:" or "wss:" Uniform Resource Identifier (URI). The DNS SRV mechanism confers load-balancing and failover capabilities for WebSocket service providers. --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Wed Apr 13 18:03:26 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C95D1E0681 for ; Wed, 13 Apr 2011 18:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dh+3ZgQ05ed for ; Wed, 13 Apr 2011 18:03:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3DB0BE05F5 for ; Wed, 13 Apr 2011 18:03:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so1149677vxg.31 for ; Wed, 13 Apr 2011 18:03:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.113 with SMTP id dj17mr220025vdb.38.1302743005818; Wed, 13 Apr 2011 18:03:25 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Wed, 13 Apr 2011 18:03:25 -0700 (PDT) In-Reply-To: <000201cbf9f0$77786fc0$66694f40$@noemax.com> References: <2C840123-723C-4A5F-AFD5-B61B4CF58659@brandedcode.com> <4DA08A71.7090405@warmcat.com> <20110410062337.GI15894@1wt.eu> <4DA15996.9010901@warmcat.com> <4DA40D84.1040407@warmcat.com> <001601cbf9c8$408b5680$c1a20380$@noemax.com> <4DA58243.1090204@warmcat.com> <000201cbf9f0$77786fc0$66694f40$@noemax.com> Date: Thu, 14 Apr 2011 11:03:25 +1000 Message-ID: From: Greg Wilkins To: Arman Djusupov Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] On Fragmentation of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 01:03:26 -0000 On 14 April 2011 01:35, Arman Djusupov wrote: > 64KB (16 bits) is too small for a single frame. There is often a need to > send an already buffered message that exceeds 64KB, in such cases the > message that is otherwise prepared for sending would need to be chunked. > This would require spending additional processing on splitting it. Receiving > such a message would also require additional processing for reading each > frame's header and concatenating the payload. In my opinion this continuous > splitting/concatenating is unnecessary just for saving 16 bits in the frame > header. Note that my background is in non-browser communications where > medium/large/super large messages are the norm. > > A 32 bit header would permit the sending of 2GB as a single-frame message > which is more than enough for today and is probably going to be a reasonable > frame size for the foreseeable future. Currently the way that jetty is implemented on the server side is that I have a fixed pre allocated buffer size into which frames are received. Applications can then individually set the max size of an aggregation buffer per connection, which is used to aggregate multiple frames into a single message. Applications may also choose to consume the frames directly without any aggregation. So for sending a 2GB file to Jetty, you will have to fragment it, because nobody is going to set the pre allocated frame buffer at anything large enough to accept 2GB. The default is 64MB. Now this is not the only way to implement a server and it may not even be close to the best way. But it is certainly not an unusual way to handle this kind of thing and I think Jetty should be totally within it's rights to say to a client - if you want to send me a 2GB message, please send it to me in fragments < 64MB. Currently if a client wants to send 2GB frames, then it wont be able to talk to Jetty. Having a negotiated max frame size would allow such a client to talk to Jetty. cheers From gregw@intalio.com Wed Apr 13 22:15:59 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB612E081F for ; Wed, 13 Apr 2011 22:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TgXpxPm2XPV for ; Wed, 13 Apr 2011 22:15:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id BDEF2E081D for ; Wed, 13 Apr 2011 22:15:58 -0700 (PDT) Received: by vxg33 with SMTP id 33so1280741vxg.31 for ; Wed, 13 Apr 2011 22:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.88.136 with SMTP id bg8mr478614vdb.78.1302758158131; Wed, 13 Apr 2011 22:15:58 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Wed, 13 Apr 2011 22:15:58 -0700 (PDT) Date: Thu, 14 Apr 2011 15:15:58 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:16:00 -0000 All, I've had a bit of a look at John tamplin's x-google-mux extension and I have to say that it's a little bit scary at the complexity required to implement MUX as an extension. This is a great pity as I think that with only a few tweaks it would have been much easier to support in the base protocol and that most opinions I've seen expressed lately agree that MUX is going to be vital for any widespread deployment and scaling of websockets. The problem is that the framing and extension mechanism that we have in websockets is just not good enough to actually do MUX, so x-google-mux essentially ignores those mechanism and is implemented as a new framing layer within the payload that then carries another layer of websocket framing. This is not to criticise the design (or designers), as I think the current websocket framing is just not good enough for MUX. WS provides frames like: [ opcode {} { application payload} ] which can be fragmented like: [ ! opcode {} { application } ] [ ! cont. {} { pay } ] [ cont. {} { load } ] I think we all imagined that when it came to MUX, we'd just be able to put the channel ID in the ext data like: [ opcode {chan 1} {application payload} ] and if it was fragmented it would look like: [ ! opcode {chan 1} { application } ] [ cont. {chan 1} { payload } ] and if it was interleaved with another channel it would look like: [ ! opcode {chan 1} { application } ] [ ! opcode {chan 2} { other } ] [ cont. {chan 1} { payload } ] [ cont. {chan 2} { data } ] But the problem with this, is that that interleaved stream of frames is not a legal sequence of frames because you cannot follow an non-final-opcode frame with another frame carrying an opcode, nor can you follow a final continuation frame with another final continuation frame. The situation get's worse when you consider that intermediaries can fragment and aggregate packets, so you might receive a stream like: [ ! opcode {chan 1} { app } ] [! cont {}{lication} ] [ ! opcode {chan 2} { other chan 1 payload } ] [ cont. {chan 2} { data } ] So frames can arrive without channel IDs and other frames can be aggregated so that extension data ends up being buried in the payload. The fragmentation mechanism is basically useless for MUX ! The solution that John is working on is to ignore the websocket frames and work at a message level, where a WS message will use opcode 0xf and will carry 1 or more MUX blocks like: [ 0xf {} { (muxCode chanId data)...(muxCode chanId data) } If the mux code is 0, then that is a data block and it carries a normal websocket frame, for example [ 0xf {} { ( 0 chanId opcode {} { application payload} ) } ] Now the inner websocket messages may be fragmented so we could see something like: [ 0xf {} { ( 0 chanId !opcode {} { application} 0 chanId !cont {} {pay} 0 chanId cont {} {load} ) } ] or the outher websocket message could be fragmented so we could see something like: [!0xf {} { ( 0 chanId !opcode {} { applic } ] [ cont {} {ation} 0 chanId !cont {} {pay} 0 chanId cont {} {load} ) } ] Note that the extension mechanism is hardly uses, other than the 0xf opcode - but that is not even needed as you could just as easily have said that all binary frames are mux frames. But I think the design of x-google-mux does work, and it may well be the best that we can do with the current websockets. But this is a huge disappointment because: 1) MUXed data is wrapped in 3 layers of framing, WS, then mux blocks then WS again. 2) Neither the fragmentation nor extension data fields are used, and it was part of there design that they were there for MUX. 3) There is the possibility that the inner websocket frames are themselves MUXed and thus could thenselve contain another layer of MUX blocks and WS framing. It could be turtles all the way down[1] It is a huge pity that we could not agree to have at least minimal support for MUX in the base protocol, as it would not need much to make it work via intermediaries. If we just added a channel ID field to the basic framing, then we could give the intermediaries some rules about fragmentation/aggregation - copy the channel ID when fragmenting - don't aggregate different channel IDs. We need not define how channels are created, flow control or anything like that, but just a smear of channel awareness so intermediaries do not make the existing framing unusable for MUX. Another alternative is that does not put Channels into the base protocol, is that we make the ext data a little more visible to the intermediaries and define rules for how it is fragmented and aggregated. It could just be simple rules like: duplicate extension data into each fragment and never aggregate frames that have different extension data. Eitherway, I think the inability of a MUX extension to use the base frames indicates that we have got something very wrong. I know there is a strong desire to just ship it and be done with it, but I really think we need to realise that we've dropped the ball on this one. Why have an extension mechanisms if it is essentially unusable? regards PS. again I really don't mean to rain on John Tamplins parade. x-google-mux is probably about as good as you can do with the current draft. [1] http://en.wikipedia.org/wiki/Turtles_all_the_way_down From tyoshino@google.com Wed Apr 13 23:58:01 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0A8DFE0687 for ; Wed, 13 Apr 2011 23:58:01 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPoardEGQrjH for ; Wed, 13 Apr 2011 23:57:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id AC7D9E06AB for ; Wed, 13 Apr 2011 23:57:59 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p3E6vw3v000455 for ; Wed, 13 Apr 2011 23:57:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302764278; bh=Lho91z9tXVpHqBx9NbE1rqE9adU=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=Dj9OrdAFfSTGWt3oXgcFpOPAJ0QhZ5EG7ANFmjQsd2xWPKkAYgzb47Qs58Sv+ojmq BLGKaTkvrGglN/W/Ezb6Q== Received: from yxn22 (yxn22.prod.google.com [10.190.4.86]) by wpaz9.hot.corp.google.com with ESMTP id p3E6vvY0029827 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Apr 2011 23:57:57 -0700 Received: by yxn22 with SMTP id 22so707883yxn.20 for ; Wed, 13 Apr 2011 23:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=odtBg1QIIzIGyrRZLZ8UOhwTgHXXbyFibTYxy5BXJ3w=; b=Rkby3rn5d4ICwjQDNYuN9HxEUQqKfvP+WNksFQRkozXChILQkbXSVjaYyGnbNBfCnS OlvNFIf69OwzrfbI4JTA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=nCR44Gu64I6Bx6+4QHHOQv+iC5Q7F2Ov8fHagF6ODoxeFanYE+tYBX2fRny3zbo2m0 wGZexm83m10QCaH1hWFQ== Received: by 10.150.114.11 with SMTP id m11mr1226516ybc.426.1302764270458; Wed, 13 Apr 2011 23:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.57.4 with HTTP; Wed, 13 Apr 2011 23:57:29 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 14 Apr 2011 15:57:29 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5d0109118fd04a0db713d X-System-Of-Record: true Subject: [hybi] Subprotocol semantics. How SHOULD/MUST user-agent and server deal with it X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:58:01 -0000 --000e0cd5d0109118fd04a0db713d Content-Type: text/plain; charset=ISO-8859-1 We should make it clear whether WebSocket layer (code of user-agent, server framework) must verify only grammar (i.e. follows ABNF or not) or also check some condition beyond grammar checking. If we do latter, we should also define what bad req/res is clearly. Conditions sound bad I can come up with are: For user-agent a) Sec-WebSocket-Protocol in response is not an element of Sec-WebSocket-Protocol in request b) the number of elements in Sec-WebSocket-Protocol in response is two or more c) sent Sec-WebSocket-Protocol but no Sec-WebSocket-Protocol in response d) didn't send Sec-WebSocket-Protocol but response contained Sec-WebSocket-Protocol For server e) supports multiple subprotocols but the user-agent didn't send Sec-WebSocket-Protocol f) supports multiple subprotocols but Sec-WebSocket-Protocol in request didn't contain any of them According to the normative section 5.2.2.2, a), b) and c) mean the server is misbehaving. Current The WebSocket API cannot handle case b) so, user-agent can do nothing but drop the connection for now. But I also think some application may benefit from having multiple values in Sec-WebSocket-Protocol in response. How we should handle case d) is not defined clearly in the current spec. This can be considered as "the client don't care protocol, but the server explicitly declare the protocol it talks". Here, we come down to a question "what absence of Sec-WebSocket-Protocol in the handshake request means. Wanna talk default subprotocol? Don't care subprotocol?" e) is a kind of server application framework design issue. Maybe server frameworks pass received subprotocol request to application code to ask decision. This is related to d). I can imagine use case like these. - developer uses "absence of Sec-WebSocket-Protocol" as "default please". Server application code decides some default subprotocol from the list of subprotocols it can talk and silently starts talking it by not sending Sec-WebSocket-Protocol in response. - developer uses "absence of Sec-WebSocket-Protocol" as "don't care". Known subprotocols are superchat and chat. User-agent sends no Sec-WebSocket-Protocol. The server sends the best subprotocol that is superchat as Sec-WebSocket-Protocol in response. It sounds clear to me that we should drop the request in case f). ---- I think it's also an option that we leave judgement to upper layer (JavaScript running on the user-agent, application code implemented on the server framework) for case a), c), d), f). i.e. we don't perform any validation other than grammar checking in WebSocket layer. If we decide to check these condition and drop req/res in WebSocket protocol layer, we must give clear semantics for "absence of Sec-WebSocket-Protocol". ---- The followings are some related suggestions from me on the spec text (assuming we allow only one subprotocol in Sec-WebSocket-Protocol in response). 5.2.2.2 (normative section) /subprotocol/ > A (possibly empty) list representing the subprotocol the > server is ready to use. If the server supports multiple subprotocols, then the value should be derived from the > client's handshake, specifically by selecting one of the > values from the "Sec-WebSocket-Protocol" field. The absence of such a field is equivalent to the null value. The empty string is not the same as the null value for these purposes. - Here in a normative section, "must" became "should" from non-normative section 1.3 and 1.9. I think this should be "MUST". - In the first sentence, we should say that the size of list must be 1. - The last sentence is correct but misleading. It sounds that empty string which means a list of one element "" is allowed as Sec-WebSocket-Protocol. - The grammar for Sec-WebSocket-Protocol is not specified in this section, but I think it's just missing. We may say here that it also follows (token | quoted-string). Takeshi --000e0cd5d0109118fd04a0db713d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We should make it clear whether WebSocket layer (code of user-agent, s= erver framework) must verify only grammar (i.e. follows ABNF or not) or als= o check some condition beyond grammar checking. If we do latter, we should = also define what bad req/res is clearly.

Conditions sound bad I can come up with are:
=
For user-agent
a) Sec-WebSocket-Protocol in respon= se is not an element of Sec-WebSocket-Protocol in request
b) the = number of elements in Sec-WebSocket-Protocol in response is two or more
c) sent Sec-WebSocket-Protocol but no Sec-WebSocket-Protocol in=A0resp= onse
d) didn't send Sec-WebSocket-Protocol but response conta= ined Sec-WebSocket-Protocol

For server
e) supports multiple subprotocols but the user-agent didn't send Sec-We= bSocket-Protocol
f) supports multiple subprotocols but Sec-WebSoc= ket-Protocol in request didn't contain any of them

According to the normative section=A05.2.2.2,=A0a), b) and c) mean the= server is misbehaving. Current=A0The WebSocket API cannot handle case b) so, user-agent can do no= thing but drop the connection for now. But I also think some application ma= y benefit from having multiple values in Sec-WebSocket-Protocol in response= .

How we should handle case d) is not defined clearly in = the current spec. This can be considered as "the client don't care= protocol, but the server explicitly declare the protocol it talks".= =A0Here, we come down to a question "what absence of Sec-WebSocket-Pro= tocol in the handshake request means. Wanna talk default subprotocol? Don&#= 39;t care subprotocol?"

e) is a kind of server application framework design iss= ue. Maybe server frameworks pass received subprotocol request to applicatio= n code to ask decision. This is related to d). I can imagine use case like = these.
- developer uses "absence of Sec-WebSocket-Protocol" as &quo= t;default please". Server application code decides some default subpro= tocol from the list of subprotocols it can talk and silently starts talking= it by not sending Sec-WebSocket-Protocol in response.
- developer uses "absence of Sec-WebSocket-Protocol" as &quo= t;don't care". Known subprotocols are superchat and chat. User-age= nt sends no Sec-WebSocket-Protocol. The server sends the best subprotocol t= hat is superchat as Sec-WebSocket-Protocol in response.

It sounds clear to me that we should drop the request i= n case f).=A0

----

I thin= k it's also an option that we leave judgement to upper layer (JavaScrip= t running on the user-agent, application code implemented on the server fra= mework) for case a), c), d), f). i.e. we don't perform any validation o= ther than grammar checking in WebSocket layer.

If we decide to check these condition and drop req/res = in WebSocket protocol layer, we must give clear semantics for "absence= of Sec-WebSocket-Protocol".

----

The followings are some related suggestions from me on = the spec text (assuming we allow only one subprotocol in Sec-WebSocket-Prot= ocol in response).

5.2.2.2 (normative section)
=A0=A0 =A0 =A0 /subprotocol/
=A0=A0 =A0 =A0 =A0 =A0A (possibly empty) l= ist representing the subprotocol the
=A0=A0 =A0 =A0 =A0 =A0server is ready to use. =A0If the server supports mul= tiple
=A0=A0 =A0 =A0 =A0 =A0subprotocols, then the value should be derived from t= he
=A0=A0 =A0 =A0 =A0 =A0client's handshake, specifically by selecti= ng one of the
=A0=A0 =A0 =A0 =A0 =A0values from the "Sec-WebSocket-= Protocol" field.=A0=A0The absence
=A0=A0 =A0 =A0 =A0 =A0of such a field is equivalent to the null value. =A0T= he empty
=A0=A0 =A0 =A0 =A0 =A0string is not the same as the null value for these pu= rposes.

- Here in a normative section= , "must" became "should" from non-normative section 1.3= and 1.9. I think this should be "MUST".
- In the first sentence, we should say that the size of list must be 1= .
- The last sentence is correct but misleading. It sounds that e= mpty string which means a list of one element "" is allowed as Se= c-WebSocket-Protocol.
- The grammar for Sec-WebSocket-Protocol is not specified in this sect= ion, but I think it's just missing. We may say here that it also follow= s (token | quoted-string).

Takeshi
--000e0cd5d0109118fd04a0db713d-- From andy.warmcat.com@googlemail.com Thu Apr 14 00:12:51 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 918AAE070D for ; Thu, 14 Apr 2011 00:12:51 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjJ38jd52XnN for ; Thu, 14 Apr 2011 00:12:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 862FEE06E3 for ; Thu, 14 Apr 2011 00:12:49 -0700 (PDT) Received: by wwa36 with SMTP id 36so1082765wwa.13 for ; Thu, 14 Apr 2011 00:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tN14F2yUAcmPHRtuKxICVkHIBVcci4rvrSeS4HT3HtM=; b=mCKneDIm2iYc+DkxQoJN19DTVinrnRHPXEI+sqVGs5Tt5CQc0Bj/DGIOsJ+grMzQ9E ASl0FaRDNRm9LZs1ljZbnPq2K/szUDDwSXL0sM1RMI4qIAmqS3dN6avqFganGt4M6yjC OzTylotaOrQa3+1U/e9cIF9PZ6f2io6SzeFqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gnQGcaMHcBTcDhBrXL8nyPIUBOnU7YlwVspx3zhEfUQx4XNe32ESyARmFfynrXibJP +iLldpOo5hyT0nj6ffsLkzVzwznZWFrqEKxxLAgB3seXJcuS4sbWQaxYAkjONkiwQInN 2RtmZQgoxy6ejFJkUvgcKgGDHSHpnq69yiPhs= Received: by 10.227.39.66 with SMTP id f2mr444052wbe.2.1302765168819; Thu, 14 Apr 2011 00:12:48 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id b20sm792121wbb.16.2011.04.14.00.12.45 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 00:12:46 -0700 (PDT) Sender: Andy Green Message-ID: <4DA69E68.4080703@warmcat.com> Date: Thu, 14 Apr 2011 08:12:40 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:12:51 -0000 On 04/14/2011 06:15 AM, Somebody in the thread at some point said: Hi - > I've had a bit of a look at John tamplin's x-google-mux extension and > I have to say that it's a little bit scary at the complexity required > to implement MUX as an extension. This is a great pity as I think It is scary, but actually more than halfway through the implementation most of the issues are coming from having to refactor the existing code somewhat to match the needs of it. It is fitting well into the extension arrangements in libwebsocket, ie, all the mux code except generic callbacks is in one extension source file. Various other things needed breaking in half for re-use and new states adding, etc. > that with only a few tweaks it would have been much easier to support > in the base protocol and that most opinions I've seen expressed lately I am not sure about that and I think we have to take a lot of care assuming we saw all the subtleties. > If the mux code is 0, then that is a data block and it carries a > normal websocket frame, for example > > [ 0xf {} { ( 0 chanId opcode {} { application payload} ) } ] Yeah notice that the mux block part does not contain a "mux block length". The characteristic of x-google-mux is that the mux block length is implied by the content and must be parsed out. This saves bytes on the wire, which matters, but means there is no casual parsing of mux content possible. (And the payload content of the muxed block may itself represent recursively muxed content, so there is another mux block header, something implied only by the state history of the child channels. It was surprising but thinking about it, the consumer of this recursively muxed stream MUST already hold matching structure and state. There's no point adding bytes to the stream to tag it, you would end up being able to parse it but not knowing how to use it. > Now the inner websocket messages may be fragmented so we could see > something like: > > [ 0xf {} { ( 0 chanId !opcode {} { application} 0 chanId !cont {} > {pay} 0 chanId cont {} {load} ) } ] > > or the outher websocket message could be fragmented so we could see > something like: > > [!0xf {} { ( 0 chanId !opcode {} { applic } ] [ cont {} {ation} 0 > chanId !cont {} {pay} 0 chanId cont {} {load} ) } ] What's the problem there? > Note that the extension mechanism is hardly uses, other than the 0xf > opcode - but that is not even needed as you could just as easily have > said that all binary frames are mux frames. Well he has control frames too that manage quota and adding and dropping subchannels, they happen under opcode 0xf as well. > But I think the design of x-google-mux does work, and it may well be > the best that we can do with the current websockets. But this is a > huge disappointment because: > > 1) MUXed data is wrapped in 3 layers of framing, WS, then mux blocks > then WS again. Ha no that's the simple case --> > 2) Neither the fragmentation nor extension data fields are used, and > it was part of there design that they were there for MUX. > 3) There is the possibility that the inner websocket frames are > themselves MUXed and thus could thenselve contain another layer of MUX > blocks and WS framing. It could be turtles all the way down[1] Right. And as I say above, you are required to parse that recursively to even understand where the next mux block starts as it stands. It is reasonable inside direct endpoint - endpoint context because you are receiving it in order to parcel it out, but it makes intermediaries have to do all that work too. > It is a huge pity that we could not agree to have at least minimal > support for MUX in the base protocol, as it would not need much to > make it work via intermediaries. If we just added a channel ID field Sorry why can't an intermediary use this mux scheme? It's not exactly trivial but it is doable. > Eitherway, I think the inability of a MUX extension to use the base > frames indicates that we have got something very wrong. I know there > is a strong desire to just ship it and be done with it, but I really > think we need to realise that we've dropped the ball on this one. Why > have an extension mechanisms if it is essentially unusable? No I think whatever the mux extension looked like, it would always be an "uber-framing" one way or the other. You don't mention the quota management, but actually that's another brain-boggler. Only after trying to think of alternatives for a while did I realize it's probably a reasonable way (although the coding could be improved to use knowledge on both sides about lengths that had been sent in the past to basically signal an ACK to renew that much quota just using a few bits riding shotgun on other traffic TCP/IP style). -Andy From andy.warmcat.com@googlemail.com Thu Apr 14 00:19:35 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61066E0861 for ; Thu, 14 Apr 2011 00:19:35 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjuzClmkt-ST for ; Thu, 14 Apr 2011 00:19:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id F3E91E0845 for ; Thu, 14 Apr 2011 00:19:33 -0700 (PDT) Received: by wyb29 with SMTP id 29so1262120wyb.31 for ; Thu, 14 Apr 2011 00:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=byYPHvFc6lhZJf/ZQX+zyhCSQWInwkigHAedlzXmURA=; b=Fj/uaCSAb6VPdjDPh8NRBBpHLGxJiAFyd4d04cTP7vTkSNbDyhBCFXf6oEwI4jBL4+ t+kNIAcfHJ9Gj3ln10GTtQqDwPP9KAsHcaJ61z7moCLBmEv3LeQa8pVuPCkb3qNix7Zg T72aLM99Ixa5Kg7g979wyanmCaZwKoTdcHb9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qyLaIiFS0KwaQOqRL0hr0fTkUe8tdwXvgEtqO1aEQnOUdXRUdx4fd6SN8oAQTXwwjE kCGiCdxQx5gMOCbOlfxuh7us9cFH/dNlHOvEhV+okCbDXrRVfKMH81KTrGiHcCSiLEo9 UoHcHZL+oaEl2dlhxYi/oFhR+nF96SUX2EVBM= Received: by 10.227.61.16 with SMTP id r16mr444377wbh.24.1302765573321; Thu, 14 Apr 2011 00:19:33 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id e13sm794380wbi.40.2011.04.14.00.19.31 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 00:19:32 -0700 (PDT) Sender: Andy Green Message-ID: <4DA6A003.3070308@warmcat.com> Date: Thu, 14 Apr 2011 08:19:31 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Takeshi Yoshino References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Subprotocol semantics. How SHOULD/MUST user-agent and server deal with it X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:19:35 -0000 On 04/14/2011 07:57 AM, Somebody in the thread at some point said: Hi - > f) supports multiple subprotocols but Sec-WebSocket-Protocol in request > didn't contain any of them > It sounds clear to me that we should drop the request in case f). Right... whatever the plan was for no explicit protocol being negotiated, it no longer makes any sense. The protocol should always have to be explicitly requested by the client even if the server only supports that one, you don't know if a different client who assumes it is a different protocol is connecting to you otherwise. There'd be no error and if the protocols were similar the failure mode might take a long time to show or be subtle. -Andy From gregw@intalio.com Thu Apr 14 02:15:56 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AB6F4E0669 for ; Thu, 14 Apr 2011 02:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMGUZkqw6g6E for ; Thu, 14 Apr 2011 02:15:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id B99EAE0664 for ; Thu, 14 Apr 2011 02:15:54 -0700 (PDT) Received: by vws12 with SMTP id 12so1433372vws.31 for ; Thu, 14 Apr 2011 02:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.66.135 with SMTP id f7mr727410vdt.198.1302772553507; Thu, 14 Apr 2011 02:15:53 -0700 (PDT) Received: by 10.52.108.105 with HTTP; Thu, 14 Apr 2011 02:15:53 -0700 (PDT) In-Reply-To: <4DA69E68.4080703@warmcat.com> References: <4DA69E68.4080703@warmcat.com> Date: Thu, 14 Apr 2011 19:15:53 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:15:56 -0000 On 14 April 2011 17:12, Andy Green wrote: > On 04/14/2011 06:15 AM, Somebody in the thread at some point said: >> that with only a few tweaks it would have been much easier to support >> in the base protocol and that most opinions I've seen expressed lately > > I am not sure about that and I think we have to take a lot of care assumi= ng > we saw all the subtleties. I'm not saying that a few tweaks is all that is required to implement MUX. I'm saying that a few tweaks might be sufficient to prevent the current spec creating intermediaries that will break MUX that uses ws framing. >> If the mux code is 0, then that is a data block and it carries a >> normal websocket frame, for example >> >> [ 0xf {} { ( 0 chanId =A0opcode =A0{} { application payload} =A0) } ] > > Yeah notice that the mux block part does not contain a "mux block length"= . > =A0The characteristic of x-google-mux is that the mux block length is imp= lied > by the content and must be parsed out. Yes - which means that the mux block parser will need to itself be a WS parser. I'm guessing that the simplest solution will be to wrap them all up in a single parser that works for WS or muxBlocks containing WS frames. >> Now the inner websocket messages may be fragmented so we could see >> something like: >> >> [ 0xf {} { ( 0 chanId =A0!opcode =A0{} { application} =A00 chanId !cont = {} >> {pay} 0 chanId cont {} {load} ) } ] >> >> or the outher websocket message could be fragmented so we could see >> something like: >> >> [!0xf {} { ( 0 chanId =A0!opcode =A0{} { applic } ] =A0 [ cont {} {ation= } =A00 >> chanId !cont {} {pay} 0 chanId cont {} {load} ) } ] > > What's the problem there? Nothing - I'm explaining how it works. >> Note that the extension mechanism is hardly uses, other than the 0xf >> opcode - but that is not even needed as you could just as easily have >> said that all binary frames are mux frames. > > Well he has control frames too that manage quota and adding and dropping > subchannels, they happen under opcode 0xf as well. But those could also be sent in normal binary frames. In fact there is very little in this that could not be done as a sub-protocol rather than an extension (except that sub protocols would go to the javascript application). > Right. =A0And as I say above, you are required to parse that recursively = to > even understand where the next mux block starts as it stands. it is cool - but scary. >> It is a huge pity that we could not agree to have at least minimal >> support for MUX in the base protocol, as it would not need much to >> make it work via intermediaries. =A0If we just added a channel ID field > > Sorry why can't an intermediary use this mux scheme? =A0It's not exactly > trivial but it is doable. Yes intermediaries will be able to implement MUX themselves. But there will also be ones that do not, and they are the ones that are forcing this recursive MUX. >> Eitherway, I think the inability of a MUX extension to use the base >> frames indicates that we have got something very wrong. =A0I know there >> is a strong desire to just ship it and be done with it, but I really >> think we need to realise that we've dropped the ball on this one. =A0Why >> have an extension mechanisms if it is essentially unusable? > > No I think whatever the mux extension looked like, it would always be an > "uber-framing" one way or the other. Why? The simple rules I described about aggregation and fragmentation should be sufficient to make normal WS frames usable in a MUX extension. Sure there are lots of complex problems to solve, such as channel life cycles and flow control - but at least the basic framing need not be reinvented. > You don't mention the quota management, but actually that's another > brain-boggler. =A0Only after trying to think of alternatives for a while = did I > realize it's probably a reasonable way (although the coding could be > improved to use knowledge on both sides about lengths that had been sent = in > the past to basically signal an ACK to renew that much quota just using a > few bits riding shotgun on other traffic TCP/IP style). Sure - I think this stuff is good. But I'm not advocating having anything like that in the base protocol. I'd like to see just enough to make the base frames usable and avoid the need for MUX blocks and nested framing. cheers From andy.warmcat.com@googlemail.com Thu Apr 14 03:20:23 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11256E066A for ; Thu, 14 Apr 2011 03:20:23 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8UP1gUsNP07 for ; Thu, 14 Apr 2011 03:20:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 4435EE0669 for ; Thu, 14 Apr 2011 03:20:20 -0700 (PDT) Received: by wyb29 with SMTP id 29so1401449wyb.31 for ; Thu, 14 Apr 2011 03:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uiE/5gUVTGMxXsYE0Ui/nmAWpSWb3SFkpV6ZERkYpnY=; b=S+4DYGMgjkA2yZKMdQUy3qq/YfrAOMOajG+h/vXIL+N7LLXmkLGzIbZs+1D+9LcSLY lfpnhZqPNhYMtpczGT8z50UwTLf86zX/1p63bNAthseXG/RYT8iiRcRLX+IfLsm9ZzBQ Jru/EtY/xfTuBZrR8y5HJoq0PcfDEA5N3zwE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZXy27Fb0o0+zxkig4KsgNuQcN1cpUUS2nrlUTkaqaAH7hac+WiLVQeP/pqUfcc0VcJ wcJwZpn9WMMQsv55wXsCol60dVTxy7exDUaa+JILfVi9jSE/wX75SwquH1cK4XNzPwbq GvFtpUPdfNrIgkqZV5HcNMfybBslSbvYq6meM= Received: by 10.227.198.206 with SMTP id ep14mr613463wbb.174.1302776419574; Thu, 14 Apr 2011 03:20:19 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id p5sm892637wbg.11.2011.04.14.03.20.17 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 03:20:18 -0700 (PDT) Sender: Andy Green Message-ID: <4DA6CA60.70000@warmcat.com> Date: Thu, 14 Apr 2011 11:20:16 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <4DA69E68.4080703@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 10:20:23 -0000 On 04/14/2011 10:15 AM, Somebody in the thread at some point said: > On 14 April 2011 17:12, Andy Green wrote: >> On 04/14/2011 06:15 AM, Somebody in the thread at some point said: > >>> that with only a few tweaks it would have been much easier to support >>> in the base protocol and that most opinions I've seen expressed lately >> >> I am not sure about that and I think we have to take a lot of care assuming >> we saw all the subtleties. > > I'm not saying that a few tweaks is all that is required to implement MUX. > I'm saying that a few tweaks might be sufficient to prevent the > current spec creating intermediaries that will break MUX that uses ws > framing. I think the idea is that you negotiated the mux extension on a particular link so you can see funny non-base-protocol stuff coming in there. That is in fact how extensions are meant to work, even if you look at the extension data area you can't interpret it outside of the context of which extensions were negotiated for that specific link. >> Yeah notice that the mux block part does not contain a "mux block length". >> The characteristic of x-google-mux is that the mux block length is implied >> by the content and must be parsed out. > > Yes - which means that the mux block parser will need to itself be a > WS parser. I'm guessing that the simplest solution will be to wrap > them all up in a single parser that works for WS or muxBlocks > containing WS frames. I don't think it matters, how it ends up either way is that the mux spec drives the architecture of the base code in a way that you are unlikely to predict from just reading the base spec. So it won't fly to look at mux extension just as a simple add-on, stuff like recursion has deep ramifications into how the parser works, how and when per-connection mux extension data is allocated, etc etc. >> Well he has control frames too that manage quota and adding and dropping >> subchannels, they happen under opcode 0xf as well. > > But those could also be sent in normal binary frames. In fact there > is very little in this that could not be done as a sub-protocol rather > than an extension (except that sub protocols would go to the > javascript application). This is the "uber framing" question again... if you can mux mux'd channels, then you need an OOB context to issue the control messages into, if it's all flat with mux management messages just part of the normal stream it can't do recursive muxing. >> Right. And as I say above, you are required to parse that recursively to >> even understand where the next mux block starts as it stands. > > it is cool - but scary. It's mostly scary because it messes up assumptions we might be holding on to about how our base implementation should be architected. For example I was looking at a trivial implementation in Javascript IIRC the other week, the author of that will have his head explode when confronted with the mux spec. That guy will probably react to this by calling it "too complicated" etc. He's right in as far as it's not a weekend project to do it like maybe the simplest base spec implementation is. >>> It is a huge pity that we could not agree to have at least minimal >>> support for MUX in the base protocol, as it would not need much to >>> make it work via intermediaries. If we just added a channel ID field >> >> Sorry why can't an intermediary use this mux scheme? It's not exactly >> trivial but it is doable. > > Yes intermediaries will be able to implement MUX themselves. > But there will also be ones that do not, and they are the ones that > are forcing this recursive MUX. Once the code is written for mux parsing at all, it can be shared for intermediary action easily enough I think. >> No I think whatever the mux extension looked like, it would always be an >> "uber-framing" one way or the other. > > Why? The simple rules I described about aggregation and > fragmentation should be sufficient to make normal WS frames usable in > a MUX extension. Sure there are lots of complex problems to solve, > such as channel life cycles and flow control - but at least the basic > framing need not be reinvented. The mux management and channel index content is for is not part of the muxed content, so it's always "out of band". If there is no OOB concept, you can't mux a mux'd channel. -Andy From jat@google.com Thu Apr 14 06:43:23 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A6ABE0748 for ; Thu, 14 Apr 2011 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.739 X-Spam-Level: X-Spam-Status: No, score=-107.739 tagged_above=-999 required=5 tests=[AWL=-1.763, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7btfJci1+cD for ; Thu, 14 Apr 2011 06:43:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id AE30EE06B8 for ; Thu, 14 Apr 2011 06:43:14 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p3EDhDDs016269 for ; Thu, 14 Apr 2011 06:43:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302788594; bh=MP4LY5ztMQKbJsoPQMQIoIt1GYg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xR7sy23+EPoYpETUTHX8RiP4JGNGgyPzBHstV7fyNrRqMCGFeZ4Hm8qKoxpzZah0A oBOp8FXWET0JX8/U1UsBg== Received: from yxe1 (yxe1.prod.google.com [10.190.2.1]) by kpbe14.cbf.corp.google.com with ESMTP id p3EDhBca002442 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 14 Apr 2011 06:43:11 -0700 Received: by yxe1 with SMTP id 1so3485204yxe.25 for ; Thu, 14 Apr 2011 06:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C469fAPRsxZuDDDRLH8py1hTPXfRQ9Zcc1RF42gh87k=; b=kcUQuhvd6Go/lg5jZW+3YljaIHyS0wvtyu4jhE1SJ1LXQ1WedKvOTkYjX6RwZW5dGO r8FJzmNm+s3jQZnFzsQQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BSbWlSviplMP+OiyWUW262nCEXEUtwR2LfmctHYRYYlg3Aq2UgkX+7OFXFF3nZ1KiY lY2kEBtpitO1+1VAQ5Ug== Received: by 10.150.170.19 with SMTP id s19mr1592740ybe.67.1302788591134; Thu, 14 Apr 2011 06:43:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Thu, 14 Apr 2011 06:42:51 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Thu, 14 Apr 2011 09:42:51 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd4cc3c31298a04a0e11beb X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:43:23 -0000 --000e0cd4cc3c31298a04a0e11beb Content-Type: text/plain; charset=UTF-8 On Thu, Apr 14, 2011 at 1:15 AM, Greg Wilkins wrote: > I've had a bit of a look at John tamplin's x-google-mux extension and > I have to say that it's a little bit scary at the complexity required > to implement MUX as an extension. This is a great pity as I think > that with only a few tweaks it would have been much easier to support > in the base protocol and that most opinions I've seen expressed lately > agree that MUX is going to be vital for any widespread deployment and > scaling of websockets. > > The problem is that the framing and extension mechanism that we have > in websockets is just not good enough to actually do MUX, so > x-google-mux essentially ignores those mechanism and is implemented as > a new framing layer within the payload that then carries another > layer of websocket framing. This is not to criticise the design (or > designers), as I think the current websocket framing is just not good > enough for MUX. > I am not sure why you say it ignores the framing/extension mechanism -- we have three vectors of extension in the WebSocket framing: opcodes, reserved bits, and an extension area, and it uses an extension opcode. It reuses the base framing rather than create its own framing for inner blocks. I think what you fundamentally don't like is that intermediaries have to understand the extensions in order to do something with a message, which I have argued is a requirement since the beginning, and it is still in the spec that an intermediary may not fragment or otherwise mutate a message which contains extensions it doesn't understand. So, I think it actually would be possible to define a channel ID in the extension data and require that fragmentation of a MUXd frame duplicates the channel ID. However, as you point out that doesn't allow you to interleave frames from different channels, unless you say the fragment state is maintained separately per channel, and I think baking that into the base protocol is definitely going too far. Also, you would still need to deal with control messages for adding/dropping individual channels and for flow control, and it seems better to aggregate them into the frame containing MUX'd data where possible. If you don't think this is a reasonable use of an extension opcode, then what exactly would you think is a good use for it? > Note that the extension mechanism is hardly uses, other than the 0xf > opcode - but that is not even needed as you could just as easily have > said that all binary frames are mux frames. > Not if you wanted to be able to send binary frames, or other as-yet-undefined frame types. > 1) MUXed data is wrapped in 3 layers of framing, WS, then mux blocks > then WS again. > There is no wrapping of MUX data blocks -- they are just a prefix to a frame on a logical channel. It seems preferable to reuse the logical channel framing rather than to invent a new framing and have to talk about how to carry as-yet-unspecified extension data from the logical channel frame in this new framing. > 2) Neither the fragmentation nor extension data fields are used, and > it was part of there design that they were there for MUX. > If you look back at the original examples I gave when we were agreeing on the framing, something very similar to the x-google-mux proposal was given as an example of how it could be implemented using the proposed framing, so I don't see why this proposal is apparently a surprise to you. The fragmentation is indeed needed for MUX, and if the shared channel is busy the MUX is going to be fragmenting the logical channel messages, and the proposal makes use of that by in fact reusing the exact framing for the logical channels. Also, the combined MUX message itself could be fragmented by a later intermediary, since as any other WS frame the sender doesn't know if some intermediary needs to fragment it further. > It is a huge pity that we could not agree to have at least minimal > support for MUX in the base protocol, as it would not need much to > make it work via intermediaries. If we just added a channel ID field > to the basic framing, then we could give the intermediaries some rules > about fragmentation/aggregation - copy the channel ID when fragmenting > - don't aggregate different channel IDs. We need not define how > channels are created, flow control or anything like that, but just a > smear of channel awareness so intermediaries do not make the existing > framing unusable for MUX. > As mentioned earlier, I don't think you can solve the problem by just defining a few unused fields in the base protocol -- I think you would essentially have to define much of the MUX behavior in the base protocol. The above would not be sufficient, as you would also have to require that intermediaries keep track of fragmentation state on a per-channel basis. > Another alternative is that does not put Channels into the base > protocol, is that we make the ext data a little more visible to the > intermediaries and define rules for how it is fragmented and > aggregated. It could just be simple rules like: duplicate extension > data into each fragment and never aggregate frames that have different > extension data. > What is "different" extension data? Remember that intermediaries cannot even distinguish what is extension data from application data if they don't understand the negotiated extensions. To do otherwise would require some tagging of the extension data (including defining it as per-message or per-fragment, where obviously per-fragment data can't be fragmented), which would be expensive and restrictive for future uses of extension data. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4cc3c31298a04a0e11beb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 14, 2011 at 1:15 AM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
I've had a bit of a look at John tamplin's x-google-mux extension a= nd
I have to say that it's a little bit scary at the complexity required to implement MUX as an extension. =C2=A0This is a great pity as I think
that with only a few tweaks it would have been much easier to support
in the base protocol and that most opinions I've seen expressed lately<= br> agree that MUX is going to be vital for any widespread deployment and
scaling of websockets.

The problem is that the framing and extension mechanism that we have
in websockets is just not good enough to actually do MUX, so
x-google-mux essentially ignores those mechanism and is implemented as
a new framing layer within the payload =C2=A0that then carries another
layer of websocket framing. =C2=A0 =C2=A0This is not to criticise the desig= n (or
designers), as I think the current websocket framing is just not good
enough for MUX.

I am not sure why you s= ay it ignores the framing/extension mechanism -- we have three vectors of e= xtension in the WebSocket framing: opcodes, reserved bits, and an extension= area, and it uses an extension opcode. =C2=A0It reuses the base framing ra= ther than create its own framing for inner blocks.

I think what you fundamentally don't like is that i= ntermediaries have to understand the extensions in order to do something wi= th a message, which I have argued is a requirement since the beginning, and= it is still in the spec that an intermediary may not fragment or otherwise= mutate a message which contains extensions it doesn't understand. =C2= =A0So, I think it actually would be possible to define a channel ID in the = extension data and require that fragmentation of a MUXd frame duplicates th= e channel ID. =C2=A0However, as you point out that doesn't allow you to= interleave frames from different channels, unless you say the fragment sta= te is maintained separately per channel, and I think baking that into the b= ase protocol is definitely going too far. =C2=A0Also, you would still need = to deal with control messages for adding/dropping individual channels and f= or flow control, and it seems better to aggregate them into the frame conta= ining MUX'd data where possible.

If you don't think this is a reasonable use of an e= xtension opcode, then what exactly would you think is a good use for it?
=C2=A0
Note that the extension mechanism is hardly uses, other than the 0xf
opcode - but that is not even needed as you could just as easily have
said that all binary frames are mux frames.

=
Not if you wanted to be able to send binary frames, or other as-yet-un= defined frame types.
=C2=A0
=C2=A01) MUXed data is wrapped in 3 layers of framing, WS, then mux blocks<= br> then WS again.

There is no wrapping of = MUX data blocks -- they are just a prefix to a frame on a logical channel. = =C2=A0It seems preferable to reuse the logical channel framing rather than = to invent a new framing and have to talk about how to carry as-yet-unspecif= ied extension data from the logical channel frame in this new framing.
=C2=A0
=C2=A02) Neither the fragmentation nor extension data fields are used, and<= br> it was part of there design that they were there for MUX.
<= div>
If you look back at the original examples I gave when we= were agreeing on the framing, something very similar to the x-google-mux p= roposal was given as an example of how it could be implemented using the pr= oposed framing, so I don't see why this proposal is apparently a surpri= se to you. =C2=A0The fragmentation is indeed needed for MUX, and if the sha= red channel is busy the MUX is going to be fragmenting the logical channel = messages, and the proposal makes use of that by in fact reusing the exact f= raming for the logical channels. =C2=A0Also, the combined MUX message itsel= f could be fragmented by a later intermediary, since as any other WS frame = the sender doesn't know if some intermediary needs to fragment it furth= er.
=C2=A0
It is a huge pity that we could not agree to have at least minimal
support for MUX in the base protocol, as it would not need much to
make it work via intermediaries. =C2=A0If we just added a channel ID field<= br> to the basic framing, then we could give the intermediaries some rules
about fragmentation/aggregation - copy the channel ID when fragmenting
- don't aggregate different channel IDs. =C2=A0 =C2=A0We need not defin= e how
channels are created, flow control or anything like that, but just a
smear of channel awareness so intermediaries do not make the existing
framing unusable for MUX.

As mentioned = earlier, I don't think you can solve the problem by just defining a few= unused fields in the base protocol -- I think you would essentially have t= o define much of the MUX behavior in the base protocol. =C2=A0The above wou= ld not be sufficient, as you would also have to require that intermediaries= keep track of fragmentation state on a per-channel basis.
=C2=A0
Another alternative is that does not put Channels into the base
protocol, is that we make the ext data a little more visible to the
intermediaries and define rules for how it is fragmented and
aggregated. =C2=A0 =C2=A0It could just be simple rules like: duplicate exte= nsion
data into each fragment and never aggregate frames that have different
extension data.

What is "different= " extension data? =C2=A0Remember that intermediaries cannot even disti= nguish what is extension data from application data if they don't under= stand the negotiated extensions. =C2=A0To do otherwise would require some t= agging of the extension data (including defining it as per-message or per-f= ragment, where obviously per-fragment data can't be fragmented), which = would be expensive and restrictive for future uses of extension data.=C2=A0=

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd4cc3c31298a04a0e11beb-- From henrikn@microsoft.com Thu Apr 14 09:45:15 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E63FE08A6 for ; Thu, 14 Apr 2011 09:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVxydY5K9dDP for ; Thu, 14 Apr 2011 09:45:12 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfc.amsl.com (Postfix) with ESMTP id 250C0E0663 for ; Thu, 14 Apr 2011 09:45:09 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 14 Apr 2011 09:45:04 -0700 Received: from TK5EX14MBXC213.redmond.corp.microsoft.com ([169.254.2.245]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0289.008; Thu, 14 Apr 2011 09:45:04 -0700 From: Henrik Frystyk Nielsen To: Henrik Frystyk Nielsen , "hybi@ietf.org" Thread-Topic: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response Thread-Index: Acv1THojZe1Zjr5kQI+H72V16Zh+AQFdpBeQ Date: Thu, 14 Apr 2011 16:45:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC9F5BTK5EX14MBXC213r_" MIME-Version: 1.0 Subject: Re: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:45:15 -0000 --_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC9F5BTK5EX14MBXC213r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure whether this was registered as an issue but I believe it is import= ant in order to allow clients to interop with servers. Thanks, Henrik From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Hen= rik Frystyk Nielsen Sent: Thursday, April 07, 2011 10:59 To: hybi@ietf.org Subject: [hybi] Indicating acceptable protocols in a 426 Upgrade Required S= tatus response The latest HTTP/1.1-bis draft [1] includes a definition of the "426 Upgrade= Required" status code which was adopted from RFC 2817. This allows a serve= r to send back a response indicating that an upgrade protocol such as WebSo= cket is required: HTTP/1.1 426 Upgrade Required Upgrade: websocket Connection: Upgrade Just like a "101 Switching Protocols" should indicate which sub-protocol (i= f any) was accepted ('chat' in this example): HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=3D Sec-WebSocket-Protocol: chat I propose that a "426 Upgrade Required" response MUST indicate which protoc= ols (if any) are acceptable: HTTP/1.1 426 Upgrade Required Upgrade: websocket Connection: Upgrade Sec-WebSocket-Protocol: chat This mirrors similar patterns already used in HTTP including a "405 Method = Not Allowed" response where the server (from [2]): 8.4.6. 405 Method Not Allowed The method specified in the Request-Line is not allowed for the target resource. The response MUST include an Allow header field containing a list of valid methods for the requested resource. The reason it is a must is that otherwise there is no way for the client to= know what to do because the exchange is not self-described. I think it is fine to reuse the Sec-WebSocket-Protocol header field just li= ke what is done for the 101 response. Thanks, Henrik [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8= .4.19 [2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8= .4.6 --_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC9F5BTK5EX14MBXC213r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not sure whether this = was registered as an issue but I believe it is important in order to allow = clients to interop with servers.

 

Thanks,

 

Henrik

 

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Henrik Frystyk Nielsen
Sent: Thursday, April 07, 2011 10:59
To: hybi@ietf.org
Subject: [hybi] Indicating acceptable protocols in a 426 Upgrade Req= uired Status response

 

The latest HTTP/1.1-bis draft [1] includes a defi= nition of the “426 Upgrade Required” status code which was adop= ted from RFC 2817. This allows a server to send back a response indicating = that an upgrade protocol such as WebSocket is required:

 

     HTTP/1.1 426 Upgrade Req= uired

     Upgrade: websocket<= /o:p>

     Connection: Upgrade=

 

Just like a “101 Switching Protocols”= should indicate which sub-protocol (if any) was accepted (‘chat̵= 7; in this example):

 

     HTTP/1.1 101 Switching P= rotocols

     Upgrade: websocket<= /o:p>

     Connection: Upgrade=

     Sec-WebSocket-Accept: s3= pPLMBiTxaQ9kYGzzhZRbK+xOo=3D

     Sec-WebSocket-Protocol: = chat

 

I propose that a “426 Upgrade Required̶= 1; response MUST indicate which protocols (if any) are acceptable:

 

     HTTP/1.1 426 Upgrade Req= uired

     Upgrade: websocket<= /o:p>

     Connection: Upgrade=

     Sec-WebSocket-Protocol: = chat

 

This mirrors similar patterns already used in HTT= P including a “405 Method Not Allowed” response where the serve= r (from [2]):

 

   8.4.6.  405 Method Not Allowed<= o:p>

 

   The method specified in the Request-= Line is not allowed for the

   target resource.  The response = MUST include an Allow header field

   containing a list of valid methods f= or the requested resource.

 

The reason it is a must is that otherwise there i= s no way for the client to know what to do because the exchange is not self= -described.

 

I think it is fine to reuse the Sec-WebSocket-Pro= tocol header field just like what is done for the 101 response.<= /p>

 

Thanks,

 

Henrik

 

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.1= 9

[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.6=

 

 

--_000_F1D6C4CA564CA347B3B9EB54BEA5AD7C0CAC9F5BTK5EX14MBXC213r_-- From salvatore.loreto@ericsson.com Thu Apr 14 11:11:27 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00F88E0717 for ; Thu, 14 Apr 2011 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toSUxbJU5Kcf for ; Thu, 14 Apr 2011 11:11:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 8D0B8E065F for ; Thu, 14 Apr 2011 11:11:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-6a-4da738c80100 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 54.42.11171.8C837AD4; Thu, 14 Apr 2011 20:11:20 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 20:11:20 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2DE14232D for ; Thu, 14 Apr 2011 21:11:20 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E8E2750B78 for ; Thu, 14 Apr 2011 21:11:19 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 56A975090A for ; Thu, 14 Apr 2011 21:11:19 +0300 (EEST) Message-ID: <4DA738C6.7040401@ericsson.com> Date: Thu, 14 Apr 2011 20:11:18 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030402040403050703030402" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:11:27 -0000 --------------030402040403050703030402 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Henrik, yes I have it on my issues' list... more this issue was brought up during the F2F meeting in Prague, however it is not clear to me what the wg think about the "426" usage this should be discussed in the thread initiated yesterday by Takeshi about SubProtocol Semantic: http://www.ietf.org/mail-archive/web/hybi/current/msg07241.html cheers /Sal On 4/14/11 6:45 PM, Henrik Frystyk Nielsen wrote: > > Not sure whether this was registered as an issue but I believe it is > important in order to allow clients to interop with servers. > > Thanks, > > Henrik > > *From:*hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf > Of *Henrik Frystyk Nielsen > *Sent:* Thursday, April 07, 2011 10:59 > *To:* hybi@ietf.org > *Subject:* [hybi] Indicating acceptable protocols in a 426 Upgrade > Required Status response > > The latest HTTP/1.1-bis draft [1] includes a definition of the “426 > Upgrade Required” status code which was adopted from RFC 2817. This > allows a server to send back a response indicating that an upgrade > protocol such as WebSocket is required: > > HTTP/1.1 426 Upgrade Required > > Upgrade: websocket > > Connection: Upgrade > > Just like a “101 Switching Protocols” should indicate which > sub-protocol (if any) was accepted (‘chat’ in this example): > > HTTP/1.1 101 Switching Protocols > > Upgrade: websocket > > Connection: Upgrade > > Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= > > Sec-WebSocket-Protocol: chat > > I propose that a “426 Upgrade Required” response MUST indicate which > protocols (if any) are acceptable: > > HTTP/1.1 426 Upgrade Required > > Upgrade: websocket > > Connection: Upgrade > > Sec-WebSocket-Protocol: chat > > This mirrors similar patterns already used in HTTP including a “405 > Method Not Allowed” response where the server (from [2]): > > 8.4.6. 405 Method Not Allowed > > The method specified in the Request-Line is not allowed for the > > target resource. The response MUST include an Allow header field > > containing a list of valid methods for the requested resource. > > The reason it is a must is that otherwise there is no way for the > client to know what to do because the exchange is not self-described. > > I think it is fine to reuse the Sec-WebSocket-Protocol header field > just like what is done for the 101 response. > > Thanks, > > Henrik > > [1] > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.19 > > > [2] > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.6 > -- Salvatore Loreto www.sloreto.com --------------030402040403050703030402 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Henrik,

yes I have it on my issues' list...

more this issue was brought up during the F2F meeting in Prague,
however it is not clear to me what the wg think about the "426" usage

this should be discussed in the thread initiated yesterday by Takeshi about SubProtocol Semantic:
http://www.ietf.org/mail-archive/web/hybi/current/msg07241.html

cheers
/Sal

On 4/14/11 6:45 PM, Henrik Frystyk Nielsen wrote:

Not sure whether this was registered as an issue but I believe it is important in order to allow clients to interop with servers.

 

Thanks,

 

Henrik

 

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Henrik Frystyk Nielsen
Sent: Thursday, April 07, 2011 10:59
To: hybi@ietf.org
Subject: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response

 

The latest HTTP/1.1-bis draft [1] includes a definition of the “426 Upgrade Required” status code which was adopted from RFC 2817. This allows a server to send back a response indicating that an upgrade protocol such as WebSocket is required:

 

     HTTP/1.1 426 Upgrade Required

     Upgrade: websocket

     Connection: Upgrade

 

Just like a “101 Switching Protocols” should indicate which sub-protocol (if any) was accepted (‘chat’ in this example):

 

     HTTP/1.1 101 Switching Protocols

     Upgrade: websocket

     Connection: Upgrade

     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

     Sec-WebSocket-Protocol: chat

 

I propose that a “426 Upgrade Required” response MUST indicate which protocols (if any) are acceptable:

 

     HTTP/1.1 426 Upgrade Required

     Upgrade: websocket

     Connection: Upgrade

     Sec-WebSocket-Protocol: chat

 

This mirrors similar patterns already used in HTTP including a “405 Method Not Allowed” response where the server (from [2]):

 

   8.4.6.  405 Method Not Allowed

 

   The method specified in the Request-Line is not allowed for the

   target resource.  The response MUST include an Allow header field

   containing a list of valid methods for the requested resource.

 

The reason it is a must is that otherwise there is no way for the client to know what to do because the exchange is not self-described.

 

I think it is fine to reuse the Sec-WebSocket-Protocol header field just like what is done for the 101 response.

 

Thanks,

 

Henrik

 

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.19

[2] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-13#section-8.4.6

 

 



-- 
Salvatore Loreto
www.sloreto.com
--------------030402040403050703030402-- From gregw@intalio.com Thu Apr 14 17:43:02 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3C617E0679 for ; Thu, 14 Apr 2011 17:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J5lNdlFj4wG for ; Thu, 14 Apr 2011 17:43:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3A3F3E065C for ; Thu, 14 Apr 2011 17:43:01 -0700 (PDT) Received: by vws12 with SMTP id 12so2196822vws.31 for ; Thu, 14 Apr 2011 17:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.69 with SMTP id 5mr1968043vdc.96.1302828180858; Thu, 14 Apr 2011 17:43:00 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 14 Apr 2011 17:43:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Apr 2011 10:43:00 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:43:02 -0000 John I didn't intend for my message to be a critique of the x-google-mux design. I think it is a good design given the base protocol. On 14 April 2011 23:42, John Tamplin wrote: > I am not sure why you say it ignores the framing/extension mechanism -- w= e > have three vectors of extension in the WebSocket framing: opcodes, reserv= ed > bits, and an extension area, and it uses an extension opcode. I'm not saying that you have used the ext opcode badly, only that your design could have been made to work without any of the extension vectors, so they are not an enabling feature of the base protocol. But I do like the use of the 0xF opcode instead of the binary frame, as it allows channel 1 to be sent normally. So that is a good use of the ext opcode - just not a necessary one. > I think what you fundamentally don't like is that intermediaries have to > understand the extensions in order to do something with a message. Partially yes. But my main concern is the nested/recursive framing of WS inside WS. I don't think it makes good use of the framing/ext mechanisms we put into the base protocol, which I think indicates that those features are not usable enough and should either be fixed or scrapped. > which I > have argued is a requirement since the beginning, and it is still in the > spec that an intermediary may not fragment or otherwise mutate a message > which contains extensions it doesn't understand. Ah - so that is something I missed. I'm OK with that restriction as I think any intermediary that is changing fragmentation is probably an intermediary that is doing aggregation anyway. But as you say below.... > So, I think it actually > would be possible to define a channel ID in the extension data and requir= e > that fragmentation of a MUXd frame duplicates the channel ID. =A0However,= as > you point out that doesn't allow you to interleave frames from different > channels, unless you say the fragment state is maintained separately per > channel, Exactly. One of the motivations for fragmentation was to support mux, but without interleaving we find that it can't support mux, so we must have framing inside framing. > I think baking that into the base protocol is definitely going too far. Why? We don't need to require that base protocol can do MUX, only that a MUX extension can change some of the framing semantics. This could be as simple as saying that apparently illegal sequences of fragments are allowed if there are extensions that can sort them out. This would allow fragments to be interleaved and channel IDs to be in the extension data and used by the endpoints to do the aggregation. Intermediaries would not be allowed to aggregate because they don't know the extension. Tools that don't know about the extension might be a little confused - but they too should not aggregate if they don't know the extensions. > If you don't think this is a reasonable use of an extension opcode, then > what exactly would you think is a good use for it? It is a good use - just not a necessary one for the extension to work. ie having extensible opcode was not a necessary condition for having such an extension. >> =A01) MUXed data is wrapped in 3 layers of framing, WS, then mux blocks >> then WS again. > > There is no wrapping of MUX data blocks -- they are just a prefix to a fr= ame > on a logical channel. =A0It seems preferable to reuse the logical channel > framing rather than to invent a new framing and have to talk about how to > carry as-yet-unspecified extension data from the logical channel frame in > this new framing. I consider a prefix to be wrapping in another layer of framing. But I agree that reusing the WS framing for the channel is a reasonable thing to do if you can't use the base framing for that purpose. >> =A02) Neither the fragmentation nor extension data fields are used, and >> it was part of there design that they were there for MUX. > > If you look back at the original examples I gave when we were agreeing on > the framing, something very similar to the x-google-mux proposal was give= n > as an example of how it could be implemented using the proposed framing, = so > I don't see why this proposal is apparently a surprise to you. =A0The > fragmentation is indeed needed for MUX, and if the shared channel is busy > the MUX is going to be fragmenting the logical channel messages, and the > proposal makes use of that by in fact reusing the exact framing for the > logical channels. =A0Also, the combined MUX message itself could be fragm= ented > by a later intermediary, since as any other WS frame the sender doesn't k= now > if some intermediary needs to fragment it further. Sorry but I missed that in the volume of email here. I had always assumed that the extension data area was going to be used for channel IDs and I remember plenty of examples suggesting that. So sorry I didn't pay more attention earlier. > As mentioned earlier, I don't think you can solve the problem by just > defining a few unused fields in the base protocol -- I think you would > essentially have to define much of the MUX behavior in the base protocol. > =A0The above would not be sufficient, as you would also have to require t= hat > intermediaries keep track of fragmentation state on a per-channel basis. But as you have pointed out, we already do not allow intermediaries to fragment/aggregate if they don't understand the extensions. So we are mostly there. All we need now is to allow interleaving of fragments, and I think that can be done without any binary change. We only need to say that it is not illegal to send a sequence of fragments that can only be aggregated by use of an extension. Intermediaries that don't understand the extension can still forward the fragments unchanged. I'm not saying that we should have MUX in the base framing. I just think that we need the base framing to be usable for MUX and thus to remove the need for nested framing. cheers From ibc@aliax.net Thu Apr 14 18:30:51 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F332E068B for ; Thu, 14 Apr 2011 18:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm9j5cu5wucm for ; Thu, 14 Apr 2011 18:30:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id C8103E065C for ; Thu, 14 Apr 2011 18:30:50 -0700 (PDT) Received: by qwc23 with SMTP id 23so1585938qwc.31 for ; Thu, 14 Apr 2011 18:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.211.200 with SMTP id gp8mr1158692qab.76.1302831050266; Thu, 14 Apr 2011 18:30:50 -0700 (PDT) Received: by 10.229.75.7 with HTTP; Thu, 14 Apr 2011 18:30:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Apr 2011 03:30:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Henrik Frystyk Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 01:30:51 -0000 2011/4/7 Henrik Frystyk Nielsen : > I propose that a =E2=80=9C426 Upgrade Required=E2=80=9D response MUST ind= icate which > protocols (if any) are acceptable: > > =C2=A0=C2=A0=C2=A0=C2=A0 HTTP/1.1 426 Upgrade Required > > =C2=A0=C2=A0=C2=A0=C2=A0 Upgrade: websocket > > =C2=A0=C2=A0=C2=A0=C2=A0 Connection: Upgrade > > =C2=A0=C2=A0=C2=A0=C2=A0 Sec-WebSocket-Protocol: chat I don't understand how and when a websocket server is supposed to reply such 426. For example, if a client sends a correct WebSocket HTTP handshake request but no one of the listed subprotocols is supported by the server, do you mean that the server should reply 426 rather than 101? But it is 100% true that current draft 06 doesn't specify what occurs in case the server supports no one of the subprotocols suggested by the client in the Sec-WebSocket-Protocol header. This is a common issue in the draft: it assumes all goes OK and doesn't care about possible errors: - What should do the client if the handshake request receive a 401 or 303 response? - What should do the server if it supports no one of the subprotocols suggested by the client in the Sec-WebSocket-Protocol header? - What should do the client if Sec-WebSocket-Protocol header in 101 response contains a subprotocol not suggested in the client request? The draft just says: "Web browsers verify that the server included one of the values as was specified in the |WebSocket| constructor.", but does not define how the client should react in other case. (Also, why does the draft say "Web browsers" rather than "WebSocket clients"?). --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 14 18:55:27 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2891AE0715 for ; Thu, 14 Apr 2011 18:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-tcgwV+O60Z for ; Thu, 14 Apr 2011 18:55:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id A51A7E0704 for ; Thu, 14 Apr 2011 18:55:26 -0700 (PDT) Received: by qwc23 with SMTP id 23so1593711qwc.31 for ; Thu, 14 Apr 2011 18:55:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.26.130 with SMTP id e2mr1090442qcc.241.1302832526230; Thu, 14 Apr 2011 18:55:26 -0700 (PDT) Received: by 10.229.75.7 with HTTP; Thu, 14 Apr 2011 18:55:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Apr 2011 03:55:26 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Henrik Frystyk Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Indicating acceptable protocols in a 426 Upgrade Required Status response X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 01:55:27 -0000 2011/4/15 I=C3=B1aki Baz Castillo : > - What should do the server if it supports no one of the subprotocols > suggested by the client in the Sec-WebSocket-Protocol header? > > - What should do the client if Sec-WebSocket-Protocol header in 101 > response contains a subprotocol not suggested in the client request? > The draft just says: "Web browsers verify that the server included one > of the values as was specified in the |WebSocket| constructor.", but > does not define how the client should react in other case. (Also, why > does the draft say "Web browsers" rather than "WebSocket clients"?). Sorry, I didn't realize that this exact subject is being discussed in other mail thread. --=20 I=C3=B1aki Baz Castillo From andy.warmcat.com@googlemail.com Fri Apr 15 00:17:41 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1F50E078E for ; Fri, 15 Apr 2011 00:17:41 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7X-4dW1v4j1 for ; Fri, 15 Apr 2011 00:17:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 879DCE0752 for ; Fri, 15 Apr 2011 00:17:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so2245350wyb.31 for ; Fri, 15 Apr 2011 00:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RnIMREHVK95qlesTW7MrvzVmYfDqbz9GO5eo2bJhDqg=; b=n5lYG8tMguuJ5wDKXdQFn4xyVEKavO7yghDTMwBxPFf2sNmG9gh+SzSmQXGCMwTNjb dg4q52cmVfqSc49TEnBaZD0xrGQ9wWrRXmSE2VOs4jNZgdHFlwCCWjcun34DSQ3JRRAf QR62Nf0anQ0dhIqz1I1mouj6Kbv7CIoqS6h8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZLO+/lc0W/FJheQc4lg5imai7ao2UNx8WdFNNwTPbZWUA6eWLVd7F1iKBhosBAqc4E aU8RodAyoWiVUlIVHtcaMQhJemHfIMsJ+eEG18xiO/fh6uoPop5z2X/abm+nZNisupcl gmrq2iJNZILReYv8rJIM9ZerjBTw2u46IdPlM= Received: by 10.227.174.79 with SMTP id s15mr1726119wbz.76.1302851859742; Fri, 15 Apr 2011 00:17:39 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o23sm1422184wbc.61.2011.04.15.00.17.34 (version=SSLv3 cipher=OTHER); Fri, 15 Apr 2011 00:17:34 -0700 (PDT) Sender: Andy Green Message-ID: <4DA7F10D.7020605@warmcat.com> Date: Fri, 15 Apr 2011 08:17:33 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:17:42 -0000 On 04/15/2011 01:43 AM, Somebody in the thread at some point said: > I'm not saying that you have used the ext opcode badly, only that your > design could have been made to work without any of the extension > vectors, so they are not an enabling feature of the base protocol. But > I do like the use of the 0xF opcode instead of the binary frame, as it > allows channel 1 to be sent normally. So that is a good use of the ext > opcode - just not a necessary one. Notice though that you can only play the ch1 = base protocol game when there are no other subchannels up. > I consider a prefix to be wrapping in another layer of framing. > But I agree that reusing the WS framing for the channel is a > reasonable thing to do if you can't use the base framing for that > purpose. Right, it's that which creates the OOB framing. You can call it a prefix or whatever since the bytes go out in an ordered stream but it's acting as a wrapper. > I'm not saying that we should have MUX in the base framing. I just > think that we need the base framing to be usable for MUX and thus to > remove the need for nested framing. Well it's as simple as using one of the reserved bits in the first frame byte of the base framing to say it's a mux block header. But I'm not sure what it actually buys us. -Andy From gregw@intalio.com Fri Apr 15 01:33:08 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0848E0686 for ; Fri, 15 Apr 2011 01:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVDj+14OF4mk for ; Fri, 15 Apr 2011 01:33:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 614F0E065A for ; Fri, 15 Apr 2011 01:33:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so2404269vxg.31 for ; Fri, 15 Apr 2011 01:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.226 with SMTP id it2mr2580015vdb.16.1302856384211; Fri, 15 Apr 2011 01:33:04 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Fri, 15 Apr 2011 01:33:04 -0700 (PDT) In-Reply-To: <4DA7F10D.7020605@warmcat.com> References: <4DA7F10D.7020605@warmcat.com> Date: Fri, 15 Apr 2011 18:33:04 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:33:09 -0000 On 15 April 2011 17:17, Andy Green wrote: >> I'm not saying that we should have MUX in the base framing. =A0I just >> think that we need the base framing to be usable for MUX and thus to >> remove the need for nested framing. > > Well it's as simple as using one of the reserved bits in the first frame > byte of the base framing to say it's a mux block header. =A0But I'm not s= ure > what it actually buys us. I think it buys us simplicity, less buffering, less framing, no masking already masked content etc. If we can reuse the base framing, then for each channel we need to keep the state: + opcode + buffer of payload received so far once the last frame comes in, we pass the buffered payload to the application, just as we do for the non mux case. With nested framing, then for each channel we need to keep the state: + buffer of payload received so far once the last frame comes in, we have to parse the buffer to a websocket protocol stack that itself may be muxed and will have it own set of channels with payloads that need to be buffered etc. cheers From andy.warmcat.com@googlemail.com Fri Apr 15 02:19:57 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B238E07A9 for ; Fri, 15 Apr 2011 02:19:57 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-8qE32GdZbC for ; Fri, 15 Apr 2011 02:19:56 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 422C0E079F for ; Fri, 15 Apr 2011 02:19:56 -0700 (PDT) Received: by wyb29 with SMTP id 29so2328887wyb.31 for ; Fri, 15 Apr 2011 02:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lpQvCs5kMZP5kWWuT+U7BeLPGlSXdD5ohhrkF33ZR2M=; b=wLSkX954Ew6ENFX/ikhr6wBwGaZiB4WPTc7pgJL+gXBQIz8fTUALz9pkSQfQb1A/ia hbWG7JaSH6qpxcayy3ehJB22MJWtqpGHkN+Q13QHd3H5fFSjq6eRPqZgv/jiaXn21YRu Pc3g2bbghMMJyHAU/z/FvnStp8PoQdAdv3xyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dof/jMXR0Gx0WtEYbM/lp4x5eJ7v38WPwkNkOkv04DvrpTANgrd7THiMwldGQJmhSq AN+1nlzAwEYVgA2WcpuxyFgQCUH3c1rItOVXkQXzyT9olIqzwMqJm3t7kKdrJKjNJ761 m9XNH91Wfgv3cvnqfH6Ffu6FywYSwPmZ7hl9g= Received: by 10.227.184.66 with SMTP id cj2mr1871907wbb.90.1302859195620; Fri, 15 Apr 2011 02:19:55 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id z13sm1056183wbd.12.2011.04.15.02.19.53 (version=SSLv3 cipher=OTHER); Fri, 15 Apr 2011 02:19:54 -0700 (PDT) Sender: Andy Green Message-ID: <4DA80DB8.8090002@warmcat.com> Date: Fri, 15 Apr 2011 10:19:52 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <4DA7F10D.7020605@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:19:57 -0000 On 04/15/2011 09:33 AM, Somebody in the thread at some point said: > On 15 April 2011 17:17, Andy Green wrote: >>> I'm not saying that we should have MUX in the base framing. I just >>> think that we need the base framing to be usable for MUX and thus to >>> remove the need for nested framing. >> >> Well it's as simple as using one of the reserved bits in the first frame >> byte of the base framing to say it's a mux block header. But I'm not sure >> what it actually buys us. > > I think it buys us simplicity, less buffering, less framing, no 'Simplicity' of what? It certainly doesn't suddenly make all the brainache go away about mux. I guess you could say 'simpler, unified frame coding'. It's neutral for buffering as discussed below. Far from 'less framing' on the wire it will demand more framing bytes or reducing max mux subchannels from 8192 to 127 since current 2-byte mux block header will have to comply with explicitly setting the base spec reserved bits in the first and second byte to achieve compatibility. Not saying that's not worth doing just let's understand we are not getting 'less framing' by doing it we're adding a little bloat. > masking already masked content etc. The existing mux spec already 'defines' that only the outer transport should be masked, although that seems crappy considering one guy's outer transport may become the next guy's inner muxed channel it should work I guess. > If we can reuse the base framing, then for each channel we need to > keep the state: > + opcode > + buffer of payload received so far > once the last frame comes in, we pass the buffered payload to the > application, just as we do for the non mux case. You have to keep that state anyway... sorry if I am missing your point. > With nested framing, then for each channel we need to keep the state: > + buffer of payload received so far > once the last frame comes in, we have to parse the buffer to a > websocket protocol stack that itself may be muxed and will have it own > set of channels with payloads that need to be buffered etc. "once the last frame comes in, we have to parse the buffer to a websocket protocol stack" -- why? You can parse the thing packet by packet as it comes in, issuing bytes to your state machine. Then there is no global buffering at all and the parsing is faster since it's not all done at the end. What is it you think you have to wait for at the end before you can begin to parse? -Andy From gezelter@rlgsc.com Fri Apr 15 03:41:02 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86F4DE06AD for ; Fri, 15 Apr 2011 03:41:02 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIb-kQx40dpl for ; Fri, 15 Apr 2011 03:41:01 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by ietfc.amsl.com (Postfix) with SMTP id 81CE3E0674 for ; Fri, 15 Apr 2011 03:41:01 -0700 (PDT) Received: (qmail 13167 invoked from network); 15 Apr 2011 10:41:00 -0000 Received: from unknown (141.157.215.43) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 15 Apr 2011 10:40:59 -0000 Message-ID: <4DA820B7.5090409@rlgsc.com> Date: Fri, 15 Apr 2011 05:40:55 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org, Andy Green , arman@noemax.com, gregw@intalio.com, John Tamplin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:41:02 -0000 Nowhere in the recent discussion of Frame Length have I seen a reference to the realities of extended length (> 64KB) frames. Instead, I have seen references to requiring extended frame sizes to support "sending extended messages with no overhead". With all due respect for hyperbole, this concern is not supported by the realities of the network. [In the interests of smooth reading, I am omitting the citations from the following couple of paragraphs.] The WebSocket protocol is emphatically TCP-based (however, my concerns also hold true for WebSocket protocol implementations over other network protocols, e.g., SCTP). Even "Jumbo Frames" limit the MTU to less than 10K bytes (octets). Of necessity, a WebSocket frame of more than slightly less than IP MTU (upon which TCP is reliant) will involve the chunking of the message into a number of packets, and the reassembly of those packets at the destination into a single, sequenced stream. This is not negotiable, it is a fundamental part of TCP, which is in turn dependent on IP. Even if we were to ignore the overhead and processing of IP and TCP, the realities of the network make it unwise to use extended frame sizes at the WebSocket protocol level. Extended frame sizes quickly create large potentials for network and application problems. Consider the case of a 1Gbps network. 1Gbps translates to a theoretical (emphasis: THEORETICAL) maximum bandwidth of 125 MB/sec. Sending gigabytes of traffic in one frame means that the time until the next frame is measured in seconds. This is, with all due respect, not a realistic presumption, even on a LAN. If one includes wide area networks, it is even farther from real-world feasibility. Protocol overhead drops quickly with packet length to a point. Once frame overhead is well less than 1%, it becomes statistically insignificant. It is worth noting that Packet Switching was chosen for the ARPAnet because it solved a number of problems, one of which was latency. Message switching long predated packet switching, and was well-known to have issues. Hence, packet switching. The latency of PING and PONG are directly affected. If an extended length frame is transmitting, PING and PONG will be delayed. For that matter, since no event will be signaled until end of frame, seconds could pass before ANY event is noticed. This is a poor idea, even when transmission errors are handled at lower levels. I can easily see timeouts being declared whose root cause is nothing more than a very large frame. [We have been here before; before ubiquitous broadband, it was common when running error-correcting modems over direct dialed circuits. It was difficult to justify to users, and difficult to track down after the fact. It was not something that is worth repeating.] In summary, I would be all for limiting the frame size to 16 bits on grounds of latency and efficiency. Larger frame sizes are not a demonstrable performance gain. If an application is dependent on the performance difference between a 64Kbyte frame and a 1Mbyte frame, it in all likelihood is far too close to the edge of what can be achieved reliably. We do no one a service by encouraging unreliable design. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From ibc@aliax.net Fri Apr 15 06:01:39 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 104B0E0820 for ; Fri, 15 Apr 2011 06:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1UwftTxivrk for ; Fri, 15 Apr 2011 06:01:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id 7F6E5E06F8 for ; Fri, 15 Apr 2011 06:01:38 -0700 (PDT) Received: by qwc23 with SMTP id 23so1872488qwc.31 for ; Fri, 15 Apr 2011 06:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.118.195 with SMTP id w3mr1397239qcq.203.1302872497711; Fri, 15 Apr 2011 06:01:37 -0700 (PDT) Received: by 10.229.75.7 with HTTP; Fri, 15 Apr 2011 06:01:37 -0700 (PDT) In-Reply-To: <4DA820B7.5090409@rlgsc.com> References: <4DA820B7.5090409@rlgsc.com> Date: Fri, 15 Apr 2011 15:01:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: gezelter@rlgsc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:01:39 -0000 2011/4/15 Bob Gezelter : > The WebSocket protocol is emphatically TCP-based (however, my concerns al= so > hold true for WebSocket protocol implementations over other network > protocols, e.g., SCTP) This is a good point. Modern Internet communication protocols don't restrict themself to a specific transport protocol (as TCP). Instead, their respective RFC's talk about "reliable transport protocols". --=20 I=C3=B1aki Baz Castillo From arman@noemax.com Fri Apr 15 06:02:58 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9EADDE0829 for ; Fri, 15 Apr 2011 06:02: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrCHglFc+k3h for ; Fri, 15 Apr 2011 06:02:58 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfc.amsl.com (Postfix) with ESMTP id E7CCAE0820 for ; Fri, 15 Apr 2011 06:02:57 -0700 (PDT) Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id YRS25001; Fri, 15 Apr 2011 16:03:01 +0300 From: "Arman Djusupov" To: , , "'Andy Green'" , , "'John Tamplin'" References: <4DA820B7.5090409@rlgsc.com> In-Reply-To: <4DA820B7.5090409@rlgsc.com> Date: Fri, 15 Apr 2011 16:02:46 +0300 Message-ID: <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGKmU+NpPxCzLOrT0Nbrh1Wu6o7QAJKm/UzlM9SaYA= Content-Language: en-us Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:02:58 -0000 > The latency of PING and PONG are directly affected. If an extended > length frame is transmitting, PING and PONG will be delayed. For that > matter, since no event will be signaled until end of frame, seconds > could pass before ANY event is noticed. This is a poor idea, even when > transmission errors are handled at lower levels. I can easily see > timeouts being declared whose root cause is nothing more than a very > large frame. [We have been here before; before ubiquitous broadband, > it was common when running error-correcting modems over direct dialed > circuits. It was difficult to justify to users, and difficult to track > down after the fact. It was not something that is worth repeating.] Sending a 64KB frame over a slow GPRS network can delay the PING/PONG for as much time as sending a 1GB frame over a local network. We can't assume that by setting the maximum frame length to 64KB we are ensuring the reliable delivery of control frames, because this is too dependent on the network condition. Under some circumstances even a few bytes long frame cannot be delivered because the remote side doesn't read from the connection due to high load or channel throttling rules. At the end of the day it's the sender that controls the outgoing frame sizes. If the sending side wants to improve the delivery of its control frames it can always choose to send frames of smaller size or even implement an algorithm that would adjust the frame size depending on network conditions and other requirements. > In summary, I would be all for limiting the frame size to 16 bits on > grounds of latency and efficiency. Larger frame sizes are not a > demonstrable performance gain. If an application is dependent on the > performance difference between a 64Kbyte frame and a 1Mbyte frame, it > in all likelihood is far too close to the edge of what can be achieved > reliably. We do no one a service by encouraging unreliable design. I can agree that 64KB is OK as a frame size for most of use cases today, but this might be too small for the faster networks of tomorrow, or too big for some compact devices still in use today. In my opinion the frame length field should allow a negotiable/configurable frame size within reasonable boundaries, rather than be capped to 64KB. With best regards, Arman From gezelter@rlgsc.com Fri Apr 15 06:10:17 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16CF6E0830 for ; Fri, 15 Apr 2011 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz2OLtM3g-Q0 for ; Fri, 15 Apr 2011 06:10:16 -0700 (PDT) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by ietfc.amsl.com (Postfix) with SMTP id 92931E0831 for ; Fri, 15 Apr 2011 06:10:15 -0700 (PDT) Received: (qmail 9530 invoked from network); 15 Apr 2011 13:10:14 -0000 Received: from unknown (141.157.215.43) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 15 Apr 2011 13:10:13 -0000 Message-ID: <4DA843B1.8090905@rlgsc.com> Date: Fri, 15 Apr 2011 08:10:09 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4DA820B7.5090409@rlgsc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:10:17 -0000 Inaki, Agreed. with a caveat. Functional requirements of underlying layers, as opposed to specification of a particular underlying layer is not a "modern" phenomenon. See RFC 772, Suzanne Sluizer and Jon Postel (1980, September) “Mail Transport Protocolâ€. The WebSocket protocol specification reads far clearer with the TCP'isms relegated to a separate dependent RFC, a point I noted in my blog posting the other week [see http://rlgsc.com/r/20110323.html]. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From gezelter@rlgsc.com Fri Apr 15 06:18:57 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B92CCE0719 for ; Fri, 15 Apr 2011 06:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuPBcfUj+5ac for ; Fri, 15 Apr 2011 06:18:57 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by ietfc.amsl.com (Postfix) with SMTP id 018D4E070A for ; Fri, 15 Apr 2011 06:18:56 -0700 (PDT) Received: (qmail 13142 invoked from network); 15 Apr 2011 13:18:56 -0000 Received: from unknown (141.157.215.43) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 15 Apr 2011 13:18:54 -0000 Message-ID: <4DA845BB.5000903@rlgsc.com> Date: Fri, 15 Apr 2011 08:18:51 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Arman Djusupov References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> In-Reply-To: <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:18:57 -0000 Arman, Agreed. I meant the 64K as a "Straw Man". Actually, IMHO, something more along the size of a Jumbo Frame is more appropriate (e.g., 8-10KBytes). When protocol overhead drops below a small fraction of bandwidth (for the sake of argument, 1% by volume) successive doublings of frame size become all but irrelevant (32 bytes of overhead/10K is already 0.32% overhead); further increases do not appreciably reduce overhead. In most cases this is not an buffering problem, as the underlying transport guarantees a sequenced stream of error-free bytes. Rather, the problem is a question of latency. Admittedly, it is all but impossible to determine the speed/available bandwidth of the limiting path of a connection, and the limiting path might change for any number of reasons (e.g., railcar derailing and damaging a cable). For these reasons, I advocate the use of fairly short frames. In any event, it would take a major change in physical constants before I could see justifying 1Mbyte+ frame sizes as providing a significant gain. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From andy.warmcat.com@googlemail.com Fri Apr 15 06:22:58 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A1C7E0766 for ; Fri, 15 Apr 2011 06:22:58 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI4xNBdk6xmE for ; Fri, 15 Apr 2011 06:22:53 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 36580E0719 for ; Fri, 15 Apr 2011 06:22:53 -0700 (PDT) Received: by wwa36 with SMTP id 36so2153279wwa.13 for ; Fri, 15 Apr 2011 06:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8Hr6PixA7ZjImAdl/lYve+zakU5theUzzFawVtYtFIs=; b=GkpHAKmlVhm9N90LlA3aCj2SHPJReBgWlG9kZp+7epUgoU6XsrH4C8pULezqnIvuEG 1flvjcQpLwKjrGVnR/HJrK9P4Mn4ntPuOpGIfvRnFNsMpPaNLdrgJ3GA3fQVP8FGTx2j QzPfTJd6bj5qmT3rzrKi1Ag3O/cpORET/JPVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=abcFYEV6J4wy5j3j+m3jibzuY6Q6qN39VM9AJwUoRefzrS0Ic4FkD+NfxoGxWQN2tt migBYJWd/MCD5N8KEeYhgw5Ek9n59dlMxv0zpfiSzwafp0rJ/38zDbhQ1h5CDb54hd1W 60GYA2NnKyWyoWl6wi0DpToeE2GAS2zVK67xc= Received: by 10.227.208.207 with SMTP id gd15mr2117614wbb.93.1302873772454; Fri, 15 Apr 2011 06:22:52 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id ed10sm1620292wbb.15.2011.04.15.06.22.50 (version=SSLv3 cipher=OTHER); Fri, 15 Apr 2011 06:22:51 -0700 (PDT) Sender: Andy Green Message-ID: <4DA846A9.8040002@warmcat.com> Date: Fri, 15 Apr 2011 14:22:49 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Arman Djusupov References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> In-Reply-To: <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gregw@intalio.com, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:22:58 -0000 On 04/15/2011 02:02 PM, Somebody in the thread at some point said: Hi - > Sending a 64KB frame over a slow GPRS network can delay the PING/PONG for as > much time as sending a 1GB frame over a local network. We can't assume that > by setting the maximum frame length to 64KB we are ensuring the reliable > delivery of control frames, because this is too dependent on the network > condition. Under some circumstances even a few bytes long frame cannot be > delivered because the remote side doesn't read from the connection due to > high load or channel throttling rules. You're right, but it's actually easier to solve with 64KByte frame limit. PING and PONG timeout number is also undefined so it can just tend to cover the worst case "good enough link" experience with 64KBytes blocking it. You can't take that approach if the ceiling is left at 2^63. >> In summary, I would be all for limiting the frame size to 16 bits on >> grounds of latency and efficiency. Larger frame sizes are not a >> demonstrable performance gain. If an application is dependent on the >> performance difference between a 64Kbyte frame and a 1Mbyte frame, it >> in all likelihood is far too close to the edge of what can be achieved >> reliably. We do no one a service by encouraging unreliable design. > > I can agree that 64KB is OK as a frame size for most of use cases today, but > this might be too small for the faster networks of tomorrow, or too big for > some compact devices still in use today. In my opinion the frame length > field should allow a negotiable/configurable frame size within reasonable > boundaries, rather than be capped to 64KB. Worst that can happen is you need to send lots of 64KByte frames, it doesn't sound so bad. If your code keeps sending while POLLOUT is coming you have plenty of frames prepared in the pipe and each frame is multiple packets on the wire, so its ability to fill available bandwidth shouldn't be hampered. -Andy From ibc@aliax.net Fri Apr 15 06:28:18 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25B38E0829 for ; Fri, 15 Apr 2011 06:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-p86ZzxIuB6 for ; Fri, 15 Apr 2011 06:28:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id 947CAE07C1 for ; Fri, 15 Apr 2011 06:28:17 -0700 (PDT) Received: by qyk7 with SMTP id 7so1718422qyk.10 for ; Fri, 15 Apr 2011 06:28:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.118.195 with SMTP id w3mr1415933qcq.203.1302874097136; Fri, 15 Apr 2011 06:28:17 -0700 (PDT) Received: by 10.229.75.7 with HTTP; Fri, 15 Apr 2011 06:28:17 -0700 (PDT) In-Reply-To: <4DA843B1.8090905@rlgsc.com> References: <4DA820B7.5090409@rlgsc.com> <4DA843B1.8090905@rlgsc.com> Date: Fri, 15 Apr 2011 15:28:17 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: gezelter@rlgsc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:28:18 -0000 2011/4/15 Bob Gezelter : > Inaki, > > Agreed. with a caveat. > > Functional requirements of underlying layers, as opposed to specification= of > a particular underlying layer is not a "modern" phenomenon. See RFC 772, > Suzanne Sluizer and Jon Postel (1980, September) =E2=80=9CMail Transport = Protocol=E2=80=9D. I should replace "modern" with "other". Thanks for pointing it out. > The WebSocket protocol specification reads far clearer with the TCP'isms > relegated to a separate dependent RFC, a point I noted in my blog posting > the other week [see http://rlgsc.com/r/20110323.html]. Awesoming article. I hope the specification will be improved/fixed taking into account the issues you describe. --=20 I=C3=B1aki Baz Castillo From jat@google.com Fri Apr 15 06:43:48 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6022EE06CE for ; Fri, 15 Apr 2011 06:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.635 X-Spam-Level: X-Spam-Status: No, score=-107.635 tagged_above=-999 required=5 tests=[AWL=-1.659, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3ti4Nqh7i0s for ; Fri, 15 Apr 2011 06:43:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 5678DE0685 for ; Fri, 15 Apr 2011 06:43:47 -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 p3FDhk9S029473 for ; Fri, 15 Apr 2011 06:43:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302875026; bh=I5hOcev2uJ0d/uMpcLs+rTw6oZA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kmoJmObdUv2oYdY+n67CnEWAQ4t2uGs736CGBmwuc329fMadeVcutHXrWK50Mb6GN TL8hMV261hV1tVWR5BM/Q== Received: from gwb15 (gwb15.prod.google.com [10.200.2.15]) by hpaq1.eem.corp.google.com with ESMTP id p3FDhii1031190 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 06:43:45 -0700 Received: by gwb15 with SMTP id 15so1456573gwb.41 for ; Fri, 15 Apr 2011 06:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E1jG22x3V0/tkDVgH+ivkiLeOoV3tnnrwSUr+J7GQNo=; b=kELh72zoZECaIPdC22QwbXUJ4I5m3ubBvmAo0GiupiDxKYj31tJQVtNwfiFfF+8R8t BXUvxG06YzC+wAS/aqpA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=p0uPZJElr/fkCHDG/5GT3ZJsjMY8Mg45ehD6DvGN/S+T4YWbagD+xUvcypTeA0oUMF a1mRo/rALg+lXBW50kxw== Received: by 10.150.162.2 with SMTP id k2mr2798151ybe.10.1302875024122; Fri, 15 Apr 2011 06:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Fri, 15 Apr 2011 06:43:24 -0700 (PDT) In-Reply-To: <4DA820B7.5090409@rlgsc.com> References: <4DA820B7.5090409@rlgsc.com> From: John Tamplin Date: Fri, 15 Apr 2011 09:43:24 -0400 Message-ID: To: gezelter@rlgsc.com Content-Type: multipart/alternative; boundary=000e0cd60ae4ffe77504a0f53aec X-System-Of-Record: true Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:43:48 -0000 --000e0cd60ae4ffe77504a0f53aec Content-Type: text/plain; charset=UTF-8 On Fri, Apr 15, 2011 at 6:40 AM, Bob Gezelter wrote: > Nowhere in the recent discussion of Frame Length have I seen a reference to > the realities of extended length (> 64KB) frames. Instead, I have seen > references to requiring extended frame sizes to support "sending extended > messages with no overhead". With all due respect for hyperbole, this > concern > is not supported by the realities of the network. [In the interests of > smooth reading, I am omitting the citations from the following couple of > paragraphs.] > This whole discussion is addressing the wrong point -- those arguing for incredibly long frames were not doing so for raising the percentage of payload bytes on the wire, but rather for efficiency of the sender. Basically, they wanted to be able to "fire and forget" sending a huge file (with sendfile and similar constructs), with the expectation that as networks get faster larger files will be feasible. Rather than assuming some smaller maximum file size is "good enough", it seemed inexpensive to allow 8-byte lengths and be sure it was enough. If you haven't read the archives surrounding the discussion of framing choices, you cannot imagine how contentious it was, so I would be loathe to revisit this decision. In the worst case, we have wasted the initial length byte=127 case if this is never used, or 1/7th of a bit. That doesn't seem worth arguing over. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd60ae4ffe77504a0f53aec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 15, 2011 at 6:40 AM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
Nowhere in the recent discussion of Frame Length have I seen a reference to=
the realities of extended length (> 64KB) frames. Instead, I have seen references to requiring extended frame sizes to support "sending exten= ded
messages with no overhead". With all due respect for hyperbole, this c= oncern
is not supported by the realities of the network. [In the interests of
smooth reading, I am omitting the citations from the following couple of paragraphs.]

This whole discussion is a= ddressing the wrong point -- those arguing for incredibly long frames were = not doing so for raising the percentage of payload bytes on the wire, but r= ather for efficiency of the sender. =C2=A0Basically, they wanted to be able= to "fire and forget" sending a huge file (with sendfile and simi= lar constructs), with the expectation that as networks get faster larger fi= les will be feasible. =C2=A0Rather than assuming some smaller maximum file = size is "good enough", it seemed inexpensive to allow 8-byte leng= ths and be sure it was enough.

If you haven't read the archives surrounding the di= scussion of framing choices, you cannot imagine how contentious it was, so = I would be loathe to revisit this decision. =C2=A0In the worst case, we hav= e wasted the initial length byte=3D127 case if this is never used, or 1/7th= of a bit. =C2=A0That doesn't seem worth arguing over.
=C2=A0
--
John A. Tamplin
Software Engineer (GWT), G= oogle
--000e0cd60ae4ffe77504a0f53aec-- From arman@noemax.com Fri Apr 15 08:32:24 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12858E06FA for ; Fri, 15 Apr 2011 08:32:24 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvPp5NmkDEBe for ; Fri, 15 Apr 2011 08:32:23 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfc.amsl.com (Postfix) with ESMTP id 4D44DE06BA for ; Fri, 15 Apr 2011 08:32:23 -0700 (PDT) Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id YTV40626; Fri, 15 Apr 2011 18:32:26 +0300 From: "Arman Djusupov" To: "'John Tamplin'" , References: <4DA820B7.5090409@rlgsc.com> In-Reply-To: Date: Fri, 15 Apr 2011 18:32:10 +0300 Message-ID: <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CBFB9B.741C3760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGKmU+NpPxCzLOrT0Nbrh1Wu6o7QAJKm/UzAcOoz+aUwV8lwA== Content-Language: en-us Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:32:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01CBFB9B.741C3760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > In the worst case, we have wasted the initial length byte=3D127 case = if=20 > this is never used, or 1/7th of a bit. That doesn't seem worth=20 > arguing over. =20 My primary hope was that we could negotiate the max message size. IMO = this is important; as I explained in an earlier message, if the = receiving side has a size quota that is not known to the sending side, = the sending side might end up sending a large amount of data before the = receiving side realizes that its size quota has been reached and denies = receiving any more data. =20 With best regards, Arman =20 ------=_NextPart_000_0054_01CBFB9B.741C3760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

> In = the worst case, we have wasted the initial length byte=3D127 case if =

> this is never used, or 1/7th = of a bit.=C2=A0 That doesn't seem worth

> arguing over.

 

My = primary hope was that we could negotiate the max message size. IMO this = is important; as I explained in an earlier message, if the receiving = side has a size quota that is not known to the sending side, the sending = side might end up sending a large amount of data before the receiving = side realizes that its size quota has been reached and denies receiving = any more data.

 

With = best regards,

Arman

 

------=_NextPart_000_0054_01CBFB9B.741C3760-- From w@1wt.eu Fri Apr 15 08:46:26 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 478B1E06FA for ; Fri, 15 Apr 2011 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8UF4Zr1mRMO for ; Fri, 15 Apr 2011 08:46:25 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfc.amsl.com (Postfix) with ESMTP id 83767E069F for ; Fri, 15 Apr 2011 08:46:25 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3FFkHCK027549; Fri, 15 Apr 2011 17:46:17 +0200 Date: Fri, 15 Apr 2011 17:46:17 +0200 From: Willy Tarreau To: Arman Djusupov Message-ID: <20110415154617.GA26904@1wt.eu> References: <4DA820B7.5090409@rlgsc.com> <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org, gregw@intalio.com, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:46:26 -0000 On Fri, Apr 15, 2011 at 06:32:10PM +0300, Arman Djusupov wrote: > > In the worst case, we have wasted the initial length byte=127 case if > > > this is never used, or 1/7th of a bit. That doesn't seem worth > > > arguing over. > > > > My primary hope was that we could negotiate the max message size. IMO this is important; as I explained in an earlier message, if the receiving side has a size quota that is not known to the sending side, the sending side might end up sending a large amount of data before the receiving side realizes that its size quota has been reached and denies receiving any more data. Well, this behaviour already works well with HTTP and does not cause any particular problem to browsers. Moreover, having a mandatory message size voids the possibility to send compressed stream without buffering them all at once first. Look how it is done with HTTP. Want to retrieve a static object ? Content-length is used (= message size here). Want to use a dynamic object or a compressed object ? Chunked encoding is used (= frame size here). So it's important not to make message size something mandatory, otherwise some useful features will not be possible anymore. Regards, Willy From gezelter@rlgsc.com Fri Apr 15 09:11:40 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0F51CE0915 for ; Fri, 15 Apr 2011 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poXAUeZ4zVCg for ; Fri, 15 Apr 2011 09:11:35 -0700 (PDT) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) by ietfc.amsl.com (Postfix) with SMTP id 94230E0914 for ; Fri, 15 Apr 2011 09:11:35 -0700 (PDT) Received: (qmail 20079 invoked from network); 15 Apr 2011 16:11:34 -0000 Received: from unknown (141.157.215.43) by p3plsmtpa07-04.prod.phx3.secureserver.net (173.201.192.233) with ESMTP; 15 Apr 2011 16:11:34 -0000 Message-ID: <4DA86E31.1020203@rlgsc.com> Date: Fri, 15 Apr 2011 11:11:29 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Willy Tarreau References: <4DA820B7.5090409@rlgsc.com> <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> <20110415154617.GA26904@1wt.eu> In-Reply-To: <20110415154617.GA26904@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:11:40 -0000 Willy, Last time I checked the draft specification (this morning), message size was distinct from frame size, to wit, messages are composed of one or more frames. Thus, even setting the most conservative limit on frame size (< a jumbo frame; about 9kb) says nothing about how long a message can be. The above is independent of my well-known belief that multiplexing is needed in the base WebSocket protocol. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From jamie@shareable.org Sat Apr 16 11:00:33 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 62939E0702 for ; Sat, 16 Apr 2011 11:00:33 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYsXElYW9T6X for ; Sat, 16 Apr 2011 11:00:32 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfc.amsl.com (Postfix) with ESMTP id 868A3E0681 for ; Sat, 16 Apr 2011 11:00:32 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QB9n9-0002a4-Ol; Sat, 16 Apr 2011 19:00:19 +0100 Date: Sat, 16 Apr 2011 19:00:19 +0100 From: Jamie Lokier To: Andy Green Message-ID: <20110416180019.GL16019@shareable.org> References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA846A9.8040002@warmcat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org, gezelter@rlgsc.com, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:00:33 -0000 Andy Green wrote: > You're right, but it's actually easier to solve with 64KByte frame > limit. PING and PONG timeout number is also undefined so it can just > tend to cover the worst case "good enough link" experience with 64KBytes > blocking it. > > You can't take that approach if the ceiling is left at 2^63. 2^63 was chosen precisely because it doesn't impose an arbitrary limit, as any limit that functionality _depends_ on an arbitrary threshold that is good for one network will inevitably be a very poor choice for another one. This means any regulation of frame queuing/blocking latencies or buffer limitations must be addressed by other means - explicitly - and scaled with the network's characteristics. The 1Gbit/s ethernet example is a poor choice, because that is not even fast by current standards. Current high-end laptops have 10Gbit/s connections, 100Gbit/s ethernet is already standardised and has available hardware, terabit ethernet is the next goal, and it seems likely that within 10 years, 10 terabit wired connections will be available on high-end consumer hardware if there is a commercial demand. > Worst that can happen is you need to send lots of 64KByte frames, it > doesn't sound so bad. If your code keeps sending while POLLOUT is > coming you have plenty of frames prepared in the pipe and each frame is > multiple packets on the wire, so its ability to fill available bandwidth > shouldn't be hampered. You have focused on byte overhead (for which your argument makes sense), and have neglected the example of sendfile which can use hardware-assisted TCP and shared memory for duplicate transmissions *only* when the WS frames are *significantly larger* than TCP packets. That's because TCP hardware assistence tends not to be able to splice together shared preexisting data with program generated headers at arbitrary offsets in TCP packets. The memory sharing is the main benefit for scaling up, not the avoidance of memory copies. Sendfile is not he point - that's just a specific current implementation detail, for which there are probably no current applications. The point is the fact that arbitrary cut-offs do have unwanted effects that are unnecessary, and there is no obviously good reason for those cut-offs in this instance. WS is aimed at the next 10 years, during which it is virtually guaranteed that large messages will get used if they work reliably, and much faster networks than we have now will be used by a significant subset of users. It is common to send replacement HTML for parts of pages inside messages, and that can easily run into megabytes - these days, let alone in 10 years when such a thing is likely to be so cheap there is no point doing anything else. So large messages are expected, and then the question would be why did we require them split *arbitrarily* into little tiny 64kb fragments handled by the CPU on a terabit network which has hardware-assisted TCP/SCTP/future at both ends? I agree that splitting into small fragments is good for a variety of reasons, including latency, receiver capability and ability to inject control messages. But the splitting size is not something we should casually fix for the lifetime of WS, as network speeds and application uses already vary over an enormous range. -- Jamie From jamie@shareable.org Sat Apr 16 11:06:00 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 12D9AE0733 for ; Sat, 16 Apr 2011 11:06:00 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8127wE5Id34 for ; Sat, 16 Apr 2011 11:05:59 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfc.amsl.com (Postfix) with ESMTP id 6F4DBE0708 for ; Sat, 16 Apr 2011 11:05:59 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QB9sY-0002bb-8I; Sat, 16 Apr 2011 19:05:54 +0100 Date: Sat, 16 Apr 2011 19:05:54 +0100 From: Jamie Lokier To: Arman Djusupov Message-ID: <20110416180554.GM16019@shareable.org> References: <4DA820B7.5090409@rlgsc.com> <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org, gregw@intalio.com, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:06:00 -0000 Arman Djusupov wrote: > My primary hope was that we could negotiate the max message size. IMO > this is important; as I explained in an earlier message, if the > receiving side has a size quota that is not known to the sending side, > the sending side might end up sending a large amount of data before > the receiving side realizes that its size quota has been reached and > denies receiving any more data. That's a flow control problem or a message size problem, not a fragment size problem. If the problem is you want to be able to send a control frame (such as "close" or "abort") and the receiver would block receiving, the solution is positive token flow control (which does limit the fragment size - but as a side effect). Setting the fragment size alone *doesn't* solve that problem. If the problem is the receiver has a limit on how big a message it can accept at all, you want to limit the message size, not the fragment size, and it's clear that there is no good *fixed* message size limit for the broad range of applications and networks. -- Jamie From andy.warmcat.com@googlemail.com Sat Apr 16 11:55:11 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3777CE0663 for ; Sat, 16 Apr 2011 11:55:11 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcj8mTA2lh3B for ; Sat, 16 Apr 2011 11:55:10 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id 34CA8E065F for ; Sat, 16 Apr 2011 11:55:10 -0700 (PDT) Received: by wwk4 with SMTP id 4so590997wwk.1 for ; Sat, 16 Apr 2011 11:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wgfwGMkNghgAsK3v3w+B6xYpsTs2uKtvE2bFqN3ii8U=; b=L9EicmzVIx7/AKkD5L67aryQKw8d6Yyq5ye204dc6vw+01wv7aNZxcpni21NVxVPTt 2D0BBjNkVL5TC32xJi0rsV05+vdsJs7LIEtPkw1FMF5i+eKQg2WfNu5dYvSmaQqv53np v0qQBNceJ3TvnGZOMrjObD/8MITTIXJyhO+t4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wzwgtYpH8usispT8lsQ5JhqYLxz8VgZZWhgcOy12A7vTp0CufMJTzHC6SNuLCetSiU tzUQcPZeighYRzMtkEpeNmX4llyykdKvhy/9mneH9po7R0l1uaCB1dFa1tUXA619CMne FLTOFNxV/BKGsqysoFxZy378FCPOqq15VsldQ= Received: by 10.227.39.89 with SMTP id f25mr3374883wbe.154.1302980109503; Sat, 16 Apr 2011 11:55:09 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id bd8sm2302813wbb.48.2011.04.16.11.55.05 (version=SSLv3 cipher=OTHER); Sat, 16 Apr 2011 11:55:07 -0700 (PDT) Sender: Andy Green Message-ID: <4DA9E608.3020406@warmcat.com> Date: Sat, 16 Apr 2011 19:55:04 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamie Lokier References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> <20110416180019.GL16019@shareable.org> In-Reply-To: <20110416180019.GL16019@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gezelter@rlgsc.com, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:55:11 -0000 On 04/16/2011 07:00 PM, Somebody in the thread at some point said: Hi - > You have focused on byte overhead (for which your argument makes > sense), and have neglected the example of sendfile which can use ... > Sendfile is not the point - that's just a specific current > implementation detail, for which there are probably no current > applications. I 'neglected' something that's 'not the point' and has 'no current applications', it sounds like I am doing alright. > It is common to send replacement HTML for parts of pages inside > messages, and that can easily run into megabytes - these days, let > alone in 10 years when such a thing is likely to be so cheap there is > no point doing anything else. So large messages are expected, and > then the question would be why did we require them split *arbitrarily* > into little tiny 64kb fragments handled by the CPU on a terabit > network which has hardware-assisted TCP/SCTP/future at both ends? To follow your argument, hardware assist may be be able to handle something as simple as frame chopping for websockets "in ten years" too, what you're talking about is hardware-assisted chopping of frames into packets already. In that case it's neutral about frame size limit. > I agree that splitting into small fragments is good for a variety of > reasons, including latency, receiver capability and ability to inject > control messages. But the splitting size is not something we should > casually fix for the lifetime of WS, as network speeds and application > uses already vary over an enormous range. Yes there is pressure to keep the frames small in reality, expecially in x-google-mux case where they can bind 8192 subchannels each blocked until other senders' frames are sent. I think we can agree if you are subchannel #8191 and have some kind of latency requirement you will not be happy all the other subchannels are sending 2^63 byte frames (each taking 5 months to transmit on a 10Tbit/s link, so he gets his turn 3 Millenia later... bit laggy). I take the point the pressure to keep frames 'small' is relative to the channel capacity and MTU and that tends to increase though. How about 2^32 that's blocking 10Tbit/s link for 3ms. -Andy From jamie@shareable.org Sat Apr 16 16:41:36 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 080A5E0691 for ; Sat, 16 Apr 2011 16:41:36 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R20Ek2CRB03i for ; Sat, 16 Apr 2011 16:41:35 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfc.amsl.com (Postfix) with ESMTP id 1A8BEE0661 for ; Sat, 16 Apr 2011 16:41:34 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QBF7G-00035M-ML; Sun, 17 Apr 2011 00:41:26 +0100 Date: Sun, 17 Apr 2011 00:41:26 +0100 From: Jamie Lokier To: Andy Green Message-ID: <20110416234126.GO16019@shareable.org> References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> <20110416180019.GL16019@shareable.org> <4DA9E608.3020406@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA9E608.3020406@warmcat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hybi@ietf.org, gezelter@rlgsc.com, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 23:41:36 -0000 Andy Green wrote: > On 04/16/2011 07:00 PM, Somebody in the thread at some point said: > >Sendfile is not the point - that's just a specific current > >implementation detail, for which there are probably no current > >applications. > > I 'neglected' something that's 'not the point' and has 'no current > applications', it sounds like I am doing alright. The point is arbitrary small thresholds aren't helpful when there is no clear benefit or reason. Sendfile is an example of why - it is not the point itself. Also I was wrong when I said no current applications. I thought of a couple of realistic ones since writing that, which I won't go into here. The case in favour of 64k frames seems weak to me. It will seem archaic in the coming years, like the 640k RAM limit in MSDOS and the quaint 2G file size limit we used to have. > To follow your argument, hardware assist may be be able to handle > something as simple as frame chopping for websockets "in ten years" too, > what you're talking about is hardware-assisted chopping of frames into > packets already. In that case it's neutral about frame size limit. Sure it can be done; that's not the point. The point is a limit does have implications beyond counting the header bytes proportional overhead. And so a limit should be justified. Nothing more than that, really. > Yes there is pressure to keep the frames small in reality, expecially in > x-google-mux case where they can bind 8192 subchannels each blocked > until other senders' frames are sent. Just 8192? Seems a bit short-sighted. With some communication patterns (generally pub-sub with very little activity but confirmed presence needed), a million subchannels works efficiently, even on a single small PC over a home network connection. And with much less memory than using lots of sockets. It is more relevant when you think that good muxing should make WebSocket objects in Javascript so cheap to create that they could be created casually and remove the need for application scripts to address, format and dispatch messages internally. But I'm digressing. > I think we can agree if you are subchannel #8191 and have some kind of > latency requirement you will not be happy all the other subchannels are > sending 2^63 byte frames (each taking 5 months to transmit on a 10Tbit/s > link, so he gets his turn 3 Millenia later... bit laggy). That is nonsense: If you are a multiplexer, you choose sensible frame sizes for the situation - and "sensible" is a rather dynamic quantity. If you are not, you don't have that problem and any frame size is ok, - maybe even 2^63, if you just want to get WS out of the way and transmit an infinite byte stream. Frame sizes don't stay the same across mux/demux boundaries. Splitting & merging is permitted, which is the whole point of frames. A fixed 64k or 10k frame size limit does not address latency adequately. If you have 8192 subchannels with latency requirements, you need QoS reservations and/or bandwidth-latency estimation, and the muxer needs to choose its frame size from that. And ideal muxer would probably vary the frame size dynamically, reducing as the amount of predicted unacknowledged data increases to bound the expected latency of the next small message. It has some similarities with process scheduling, which dynamically adjusts timeslices and learns to distinguish batch activity from transient activity. The point is that is very much something that should be left to implementations. We don't have enough experience to know what values to use, let alone what adaptive heuristics to use. > I take the point the pressure to keep frames 'small' is relative to the > channel capacity and MTU and that tends to increase though. How about > 2^32 that's blocking 10Tbit/s link for 3ms. That'd be fine with me. I argued for 2^24, but it was easy to miss :-) I think the reason it came out as 2^63 in the end was so that there'd be no untested boundary case or simply ignored wraparound to become a submarine bug in widely deployed code when it encounters handles a long frame in future. -- Jamie From andy.warmcat.com@googlemail.com Sun Apr 17 00:49:21 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03ECFE0686 for ; Sun, 17 Apr 2011 00:49:21 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4Mdjw9hJxbb for ; Sun, 17 Apr 2011 00:49:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id AEEBDE0682 for ; Sun, 17 Apr 2011 00:49:19 -0700 (PDT) Received: by wyb29 with SMTP id 29so3583027wyb.31 for ; Sun, 17 Apr 2011 00:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=te1yw8IHhtcMuSC+84NyNltS4WECIT1CIcK2lza77M4=; b=N+Jyw7ef5X6WnSUpvIDWPq/xBCBzsmEdoyhyu+yTBu6DnUPMjSr8WoY3vUtptfRufb EuWNWy61Tz0cvQ41nJW4UIKx0oqhsaUAqsnCwb/UYbN2mOVFsvNdNQm7vdgGO70mYQB8 QgR580muq4CnrpdbmNRz5Mv4JxWeQtVm/YYxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HPkiEj7xA/zbiOppUxtx5t56wDnhIxLIA5qVWggNSuRzNShqhTrVOElegSQBsakYEZ CEPcH8Cf5qbZwdiqDcwETide3xUufXfn+K05d3ErH9nhjbE75y/6snD/cX2Hqcnfackp gu+G/I2SDuha+ju3BWoVwkYPhQOz+XSIW/kFI= Received: by 10.227.172.7 with SMTP id j7mr3693828wbz.60.1303026558741; Sun, 17 Apr 2011 00:49:18 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o6sm2547900wbo.54.2011.04.17.00.49.15 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 00:49:15 -0700 (PDT) Sender: Andy Green Message-ID: <4DAA9B75.4070301@warmcat.com> Date: Sun, 17 Apr 2011 08:49:09 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jamie Lokier References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> <20110416180019.GL16019@shareable.org> <4DA9E608.3020406@warmcat.com> <20110416234126.GO16019@shareable.org> In-Reply-To: <20110416234126.GO16019@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gezelter@rlgsc.com, gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 07:49:21 -0000 On 04/17/2011 12:41 AM, Somebody in the thread at some point said: Hi - >> Yes there is pressure to keep the frames small in reality, expecially in >> x-google-mux case where they can bind 8192 subchannels each blocked >> until other senders' frames are sent. > > Just 8192? Seems a bit short-sighted. With some communication 8192 in one mux layer. n of those can be mux subchannels at the next layer up and so on. > It is more relevant when you think that good muxing should make > WebSocket objects in Javascript so cheap to create that they could be > created casually and remove the need for application scripts to > address, format and dispatch messages internally. But I'm digressing. Yeah I already pointed that out a while back, it's a good reason to expect that we see mux connections pretty much as the norm in the browser case. >> I think we can agree if you are subchannel #8191 and have some kind of >> latency requirement you will not be happy all the other subchannels are >> sending 2^63 byte frames (each taking 5 months to transmit on a 10Tbit/s >> link, so he gets his turn 3 Millenia later... bit laggy). > > That is nonsense: If you are a multiplexer, you choose sensible frame The example uses the current status of x-google-mux AIUI, it doesn't define chopping frames, just prepends them with mux block headers. > And ideal muxer would probably vary the frame size dynamically, > reducing as the amount of predicted unacknowledged data increases to > bound the expected latency of the next small message. It has some > similarities with process scheduling, which dynamically adjusts > timeslices and learns to distinguish batch activity from transient > activity. The current approach AIUI is that frame fragmentation by intermediary of mux is possible, but only if the extensions are all understood by the guy who wants to fragment them. When you combine the high incidence of mux connection with frame fragmentation by mux though, you can see arguments for monster ws frame size are all moot. >> I take the point the pressure to keep frames 'small' is relative to the >> channel capacity and MTU and that tends to increase though. How about >> 2^32 that's blocking 10Tbit/s link for 3ms. > > That'd be fine with me. > > I argued for 2^24, but it was easy to miss :-) Well fine then. > I think the reason it came out as 2^63 in the end was so that there'd > be no untested boundary case or simply ignored wraparound to become a > submarine bug in widely deployed code when it encounters handles a long > frame in future. It'd be better to encourage or define a test suite. I wrote a fragment fuzzer along with some simple protocols, Greg has tried to define a set of tests formally based on libwebsockets test protocols. They not only confirm reliable operation inside the individual implementation but have a huge advantage they can confirm implementations had the same understanding of the spec by running one guy's client against another guy's server; Pat McManus went around testing interoperability with deflate-stream and found errors that were easy to fix once known. Allowing crazy numbers in the protocol instead that we know can't be supported or fully tested and saying it's bulletproof sounds less good. -Andy From jat@google.com Sun Apr 17 08:17:34 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A15EE06B5 for ; Sun, 17 Apr 2011 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.135 X-Spam-Level: X-Spam-Status: No, score=-104.135 tagged_above=-999 required=5 tests=[AWL=1.842, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzvV8LDMra9y for ; Sun, 17 Apr 2011 08:17:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id B6E34E0694 for ; Sun, 17 Apr 2011 08:17:33 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p3HFHWks012443 for ; Sun, 17 Apr 2011 08:17:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303053453; bh=LZOmAwrVtGVN6ApPUN8TYnXt0rE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Sc5NaDGU6MBZVjXAPSC4jYjI/irJXR6Cnrz1GHMoOW4Uowy6+5xxy5z0EHjR5ZOCH VlUSsI43slS6+Fb76j3Sg== Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by wpaz9.hot.corp.google.com with ESMTP id p3HFHVJp018689 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 17 Apr 2011 08:17:31 -0700 Received: by gwb20 with SMTP id 20so1900108gwb.31 for ; Sun, 17 Apr 2011 08:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hy6PPlzAoK9F1RKWBj58GbeHXzwqJdFMVnRgl+VHWEo=; b=Fxpa4LGTfwebzFbkLc+v8eMhktyH1ByT7oZ0eRSbsdBS1EqKj7eUzoE7iLH8DVtZoc 9eB49A+ZGUp0151IncIg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=HlY31ei5ILJZFR8oM9b6lXYT5R4gcJslx337tIJJdnBrFIHRsoNO4VE8g7Dp3Vl0fL aGtCEH/Ohj+v7JBIY5BA== Received: by 10.150.170.19 with SMTP id s19mr3733665ybe.67.1303053451112; Sun, 17 Apr 2011 08:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Sun, 17 Apr 2011 08:17:10 -0700 (PDT) In-Reply-To: <4DAA9B75.4070301@warmcat.com> References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> <20110416180019.GL16019@shareable.org> <4DA9E608.3020406@warmcat.com> <20110416234126.GO16019@shareable.org> <4DAA9B75.4070301@warmcat.com> From: John Tamplin Date: Sun, 17 Apr 2011 11:17:10 -0400 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: hybi@ietf.org, gregw@intalio.com, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 15:17:34 -0000 On Sun, Apr 17, 2011 at 3:49 AM, Andy Green wrote: > 8192 in one mux layer. =C2=A0n of those can be mux subchannels at the nex= t layer up and so on. That is just the current proposal to get experience with it -- we could always define some variable-length encoding (in fact it was suggested to do that with low channel numbers to conserve space) and allow them to get arbitrarily large, though we would probably have to support negotiation of a maximum channel number in that case. > The example uses the current status of x-google-mux AIUI, it doesn't defi= ne chopping frames, > just prepends them with mux block headers. Actually the "Fairness" section talks about refragmenting as necessary. =C2=A0You will have to do that based on the available send quota for a channel anyway. > The current approach AIUI is that frame fragmentation by intermediary of = mux is possible, > but only if the extensions are all understood by the guy who wants to fra= gment them. That is what is in the base WebSockets protocol -- an intermediary may not change the frame at all if it does not understand all the extensions which were negotiated. -- John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Sun Apr 17 09:26:50 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F257DE06DE for ; Sun, 17 Apr 2011 09:26:50 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uySwIg0BGju4 for ; Sun, 17 Apr 2011 09:26:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id F0C1CE0684 for ; Sun, 17 Apr 2011 09:26:49 -0700 (PDT) Received: by wwa36 with SMTP id 36so3208246wwa.13 for ; Sun, 17 Apr 2011 09:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n+x5sx2gLllX9hEMhPeed1EHWXxaCpuPn4JyLOSP1j4=; b=H9k3V75e/9ibNom6G8GCo4+vcYcSh1GgPwYf5sTxS5uad7Yqy4EFBOPaLxTX2SPzMz b9bIgfoVpgLVSVBDjGmjnTuvQkRWCZ9rIynB1qARYVYHEEgCk/4PgWDUa4/w3HJNW+VK Q246h6nsq5Q94olqhJX1EDX5AHnLoyRmsK1b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TuJCCYzJUG+5IdR+eIWu12EHrxar+pNMFRVZBQ06zYVDczxroErlEZ4qlwPpqUArjj ozdgiFZByxlMp/4Yofl6/sh8y/dtDtFUlCSRJb6Dh8UacXxK1XVjxJHUYlHdqkSRGmw5 HOpwM+TMk0LvopNKG8v0zI68hQ14HkOYd4Xog= Received: by 10.227.139.19 with SMTP id c19mr4111892wbu.13.1303057609028; Sun, 17 Apr 2011 09:26:49 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id bd8sm2755633wbb.65.2011.04.17.09.26.47 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 09:26:47 -0700 (PDT) Sender: Andy Green Message-ID: <4DAB14C6.2030101@warmcat.com> Date: Sun, 17 Apr 2011 17:26:46 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Tamplin References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> <20110416180019.GL16019@shareable.org> <4DA9E608.3020406@warmcat.com> <20110416234126.GO16019@shareable.org> <4DAA9B75.4070301@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gregw@intalio.com, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 16:26:51 -0000 On 04/17/2011 04:17 PM, Somebody in the thread at some point said: Hi - > On Sun, Apr 17, 2011 at 3:49 AM, Andy Green wrote: >> 8192 in one mux layer. n of those can be mux subchannels at the next layer up and so on. > > That is just the current proposal to get experience with it -- we > could always define some variable-length encoding (in fact it was > suggested to do that with low channel numbers to conserve space) and > allow them to get arbitrarily large, though we would probably have to > support negotiation of a maximum channel number in that case. I guess unless the quota is managed very nicely there is a magic number of active subchannels where the quota traffic itself and the latency characteristics of delivering the quota vs the payloads causes performance to melt down. >> The example uses the current status of x-google-mux AIUI, it doesn't define chopping frames, >> just prepends them with mux block headers. > > Actually the "Fairness" section talks about refragmenting as > necessary. You will have to do that based on the available send quota > for a channel anyway. Well I missed it. You could take the approach you just delay sending it until there's enough quota to send it all too. Although as far as I read there's no relationship between quota numbers and max legal frame size defined. -Andy From gregw@intalio.com Sun Apr 17 15:41:12 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1D7AE0732 for ; Sun, 17 Apr 2011 15:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTuLKAxrCZf0 for ; Sun, 17 Apr 2011 15:41:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0FFAFE068B for ; Sun, 17 Apr 2011 15:41:07 -0700 (PDT) Received: by vws12 with SMTP id 12so3937895vws.31 for ; Sun, 17 Apr 2011 15:41:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.99 with SMTP id bz3mr870851vdc.117.1303080067491; Sun, 17 Apr 2011 15:41:07 -0700 (PDT) Received: by 10.52.158.104 with HTTP; Sun, 17 Apr 2011 15:41:07 -0700 (PDT) In-Reply-To: <20110415154617.GA26904@1wt.eu> References: <4DA820B7.5090409@rlgsc.com> <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> <20110415154617.GA26904@1wt.eu> Date: Mon, 18 Apr 2011 08:41:07 +1000 Message-ID: From: Greg Wilkins To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 22:41:12 -0000 On 16 April 2011 01:46, Willy Tarreau wrote: > On Fri, Apr 15, 2011 at 06:32:10PM +0300, Arman Djusupov wrote: >> My primary hope was that we could negotiate the max message size. IMO th= is is important; as I explained in an earlier message, if the receiving sid= e has a size quota that is not known to the sending side, the sending side = might end up sending a large amount of data before the receiving side reali= zes that its size quota has been reached and denies receiving any more data= . > > Well, this behaviour already works well with HTTP and does not cause > any particular problem to browsers. But it does cause problems on servers. HTTP servers typically have undeclared limits on the size of URL accepted (that limits parameters sent with a GET), and limits on the size of form encoded content (that limits the size of parameters sent with a POST). We have response codes 413 and 414 to cope with these circumstances, and maybe the equivalent is sufficient for websocket - but I hardly see having the ability to declare a maximal frame and/or message size as bad thing - at worse it might be under utilised. cheers From gregw@intalio.com Sun Apr 17 18:53:00 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CEECE066C for ; Sun, 17 Apr 2011 18:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOHy4Bo2D3NK for ; Sun, 17 Apr 2011 18:52:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2924DE0665 for ; Sun, 17 Apr 2011 18:52:59 -0700 (PDT) Received: by vws12 with SMTP id 12so4004500vws.31 for ; Sun, 17 Apr 2011 18:52:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.99.163 with SMTP id er3mr2343072vdb.197.1303091578780; Sun, 17 Apr 2011 18:52:58 -0700 (PDT) Received: by 10.52.158.104 with HTTP; Sun, 17 Apr 2011 18:52:58 -0700 (PDT) In-Reply-To: <4DA80DB8.8090002@warmcat.com> References: <4DA7F10D.7020605@warmcat.com> <4DA80DB8.8090002@warmcat.com> Date: Mon, 18 Apr 2011 11:52:58 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] MUX complications X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 01:53:00 -0000 On 15 April 2011 19:19, Andy Green wrote: > On 04/15/2011 09:33 AM, Somebody in the thread at some point said: >> >> On 15 April 2011 17:17, Andy Green =A0wrote: >>>> >>>> I'm not saying that we should have MUX in the base framing. =A0I just >>>> think that we need the base framing to be usable for MUX and thus to >>>> remove the need for nested framing. >>> >>> Well it's as simple as using one of the reserved bits in the first fram= e >>> byte of the base framing to say it's a mux block header. =A0But I'm not >>> sure >>> what it actually buys us. >> >> I think it buys us simplicity, less buffering, less framing, no > > 'Simplicity' of what? Instead of sending something like [!0xf {} { ( 0 chanId !opcode {} { applic } ] [ cont {} {ation} 0 chanId !cont {} {pay} 0 chanId cont {} {load} ) } ] we could send [!opcode {chanId} {application } ] [ !cont {chanId} {pay} ] [ cont {chanId} {load} ] > =A0It certainly doesn't suddenly make all the brainache > go away about mux. =A0I guess you could say 'simpler, unified frame codin= g'. My making the nested framing go away, it means our aching brains can focus more on the difficulties of MUX (flow control etc) rather than nested/recursive parsers and state machines. > It's neutral for buffering as discussed below. I don't think so. Typically a parser is going to have input buffers and output buffers - parse raw on the wire bytes to produce parsed bytes. If you have to string 3 (or recursively more) parsers together, then I can see many intermediary buffers being used. With a lot of smarts, you can probably flatten out the recursive/chained parsers into a single parser - but that is a big task that you need to start by throwing away your existing WS parser and starting again. > Far from 'less framing' on the wire it will demand more framing bytes or > reducing max mux subchannels from 8192 to 127 since current 2-byte mux bl= ock > header will have to comply with explicitly setting the base spec reserved > bits in the first and second byte to achieve compatibility. Not saying > that's not worth doing just let's understand we are not getting 'less > framing' by doing it we're adding a little bloat. I don't understand this point. I'm not suggesting changing the chanId encoding that John has proposed (which is variable length). I'm just saying put it in the extension data rather than in a MUX block frame/prefix. >> masking already masked content etc. > > The existing mux spec already 'defines' that only the outer transport sho= uld > be masked, although that seems crappy considering one guy's outer transpo= rt > may become the next guy's inner muxed channel it should work I guess. With my proposal a MUXing intermediary need no unmux or remux. We only need to pad the mux ext data to 4 bytes and then the intermediary can keep the same mask key, add the masked mux channel Id, and then reused the payload in its already masked form. >> If we can reuse the base framing, then for each channel we need to >> keep the state: >> =A0+ opcode >> =A0+ buffer of payload received so far >> once the last frame comes in, we pass the buffered payload to the >> application, just as we do for the non mux case. > > You have to keep that state anyway... sorry if I am missing your point. Yes we keep that state anyway (I listed it both times). The difference is that if we reuse the base framing then MUX becomes a transformation from wire data to application data. With the nested framing MUX is a transformation from wire data to wire data and needs recursive (or smart iterative) handling. >> With nested framing, then for each channel we need to keep the state: >> =A0+ buffer of payload received so far >> once the last frame comes in, we have to parse the buffer to a >> websocket protocol stack that itself may be muxed and will have it own >> set of channels with payloads that need to be buffered etc. > > "once the last frame comes in, we have to parse the buffer to a websocket > protocol stack" =A0-- why? =A0You can parse the thing packet by packet as= it > comes in, issuing bytes to your state machine. =A0Then there is no global > buffering at all and the parsing is faster since it's not all done at the > end. =A0What is it you think you have to wait for at the end before you c= an > begin to parse? Yep I think it can be done this way. But it will pretty smart implementation of WS parsers/generators. If you receive something like: [!0xf {} { ( 0 chanId !0xf {} { 0 chanId !0xf {} {0} } } ] then you parser is going to have to remember that it is 3 levels of mux down with the meta data for the 3 layer not yet received, and that there are two channel Id's in play, with the first channel Id really acting as a name space for the second channel Id which might not be unique for the connection. It is doable - but it's not simple. We already have the restriction that an intermediary can't fragment or aggregate if it does not understand all the extensions. So for my proposal, all we need to add is that we can send arbitrary sequences of interleaved fragments that an extension will well order. cheers From w@1wt.eu Sun Apr 17 22:06:50 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 387A8E0761 for ; Sun, 17 Apr 2011 22:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aicWTjLwCXjA for ; Sun, 17 Apr 2011 22:06:49 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfc.amsl.com (Postfix) with ESMTP id 585E6E066A for ; Sun, 17 Apr 2011 22:06:48 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p3I56gTH005335; Mon, 18 Apr 2011 07:06:42 +0200 Date: Mon, 18 Apr 2011 07:06:42 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110418050642.GF32460@1wt.eu> References: <4DA820B7.5090409@rlgsc.com> <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> <20110415154617.GA26904@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, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 05:06:50 -0000 On Mon, Apr 18, 2011 at 08:41:07AM +1000, Greg Wilkins wrote: > On 16 April 2011 01:46, Willy Tarreau wrote: > > On Fri, Apr 15, 2011 at 06:32:10PM +0300, Arman Djusupov wrote: > >> My primary hope was that we could negotiate the max message size. IMO this is important; as I explained in an earlier message, if the receiving side has a size quota that is not known to the sending side, the sending side might end up sending a large amount of data before the receiving side realizes that its size quota has been reached and denies receiving any more data. > > > > Well, this behaviour already works well with HTTP and does not cause > > any particular problem to browsers. > > But it does cause problems on servers. > > HTTP servers typically have undeclared limits on the size of URL > accepted (that limits parameters sent with a GET), and limits on the > size of form encoded content (that limits the size of parameters sent > with a POST). Indeed, though that's slightly different. > We have response codes 413 and 414 to cope with these circumstances, > and maybe the equivalent is sufficient for websocket - but I hardly > see having the ability to declare a maximal frame and/or message size > as bad thing - at worse it might be under utilised. Having the ability to specify the *max* sizes is a good thing and I'd also like to have it. What I was saying is that we should not have to announce the message size, only the frame size. Regards, Willy From gezelter@rlgsc.com Mon Apr 18 04:15:03 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6BC07E071E for ; Mon, 18 Apr 2011 04:15:03 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtdqgOO+moYa for ; Mon, 18 Apr 2011 04:14:59 -0700 (PDT) Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) by ietfc.amsl.com (Postfix) with SMTP id E7F17E06E0 for ; Mon, 18 Apr 2011 04:14:58 -0700 (PDT) Received: (qmail 3807 invoked from network); 18 Apr 2011 11:14:57 -0000 Received: from unknown (68.161.205.173) by p3plsmtpa07-09.prod.phx3.secureserver.net (173.201.192.238) with ESMTP; 18 Apr 2011 11:14:57 -0000 Message-ID: <4DAC1D2B.6000108@rlgsc.com> Date: Mon, 18 Apr 2011 06:14:51 -0500 From: Bob Gezelter Organization: Robert Gezelter Software Consultant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: <4DA820B7.5090409@rlgsc.com> <004801cbfb6d$6eec0640$4cc412c0$@noemax.com> <4DA846A9.8040002@warmcat.com> <20110416180019.GL16019@shareable.org> <4DA9E608.3020406@warmcat.com> <20110416234126.GO16019@shareable.org> <4DAA9B75.4070301@warmcat.com> <4DAB14C6.2030101@warmcat.com> In-Reply-To: <4DAB14C6.2030101@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: gregw@intalio.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gezelter@rlgsc.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:15:03 -0000 This will have to be short, as I have some deadlines to meet today. I have noted a number of comments concerning my comments about frame sizes. Some of the comments seemed to mis-construe my suggestion as a suggestion of limits on message size. I do not like extremely long messages for other reasons, but I see no reason to preclude them from the specification. Long frame sizes, on the other hand, have implications on how the WebSocket protocol rides on its transport mechanism, which is a relevant concern. In particular, I disagree with the suggestion that frame sizing should be driven by some of the concerns expressed, to wit: sendfile and hardware assisted TCP. sendfile is indeed described as a "... Because this copying is done within the kernel. ..." However, I believe that this characterization is not to be taken literally. A large file (arguendo, hundreds of megabytes), may be at best mapped into virtual space, but each group of disk blocks will have to be brought into memory from the (possibly non-continuous) areas of the disk, and then written back out. This is not an overhead-free operation. Instead, the sendfile description seems to reap significant benefit from avoiding multiple in-memory copies that would otherwise be necessary. Hardware assisted TCP is similarly not all of the limitation that it seems. All devices providing hardware assist for TCP almost certainly implement scatter/gather mapping of some form. Therefore, pre-pending protocol information onto the front of WebSocket protocol frames does not prevent TCP hardware assist. It would be more correct to say that the efficiency of the WebSocket protocol in such situations will depend heavily on the choices of those implementing the middleware layer that actually speaks the protocol. If the middleware layer (e.g., WebSockets) is not well optimized, then we will pay the price. Multiplexing is a whole other topic for another posting. - Bob +--------------------------------------------------------------------------+ | Robert "Bob" Gezelter E-Mail: gezelter@rlgsc.com | | Robert Gezelter Software Consultant | | 35-20 167th Street, Suite 215 Fax: (on Request) | | Flushing, New York 11358-1731 | | United States of America http://www.rlgsc.com | +--------------------------------------------------------------------------+ From ifette@google.com Mon Apr 18 23:51:42 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 443DBE06CC for ; Mon, 18 Apr 2011 23:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWwQ34el8TE3 for ; Mon, 18 Apr 2011 23:51:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 0A59AE06BA for ; Mon, 18 Apr 2011 23:51:40 -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 p3J6peMf005516 for ; Mon, 18 Apr 2011 23:51:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303195900; bh=W/PP1F7jf+JsFk+l5C8KyGELDQ4=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=RqibMeetVLmhiGrYgo7r+5nrUvOFvLTIPVCUT6EfP8mViXAxLyf0nZ7uldLTQTO1A FpKZAA1fWtsqv6QPfpmpA== Received: from qyk35 (qyk35.prod.google.com [10.241.83.163]) by hpaq5.eem.corp.google.com with ESMTP id p3J6pbqh010236 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Apr 2011 23:51:38 -0700 Received: by qyk35 with SMTP id 35so1442477qyk.13 for ; Mon, 18 Apr 2011 23:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M17nOkzG3SQyEyAZH1IiZ6+vqicIgeM+X/XpusQ3+bk=; b=ukoPyPuC2nRfBcJBoovoVCgzXzk2+ZTnrK8mNYUpcjDU+nRF2YADcuw66LSMS9z/Gd HEhggwyRocGWwWdfutTg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=bxAv1i2XCSOUTl8qRaXDtA6M6JfLNw7ohFnLN5UOpVM0m2wwr1C3zxD1IpWkygzZhU rPHdK0yO4NOblGB+SXrg== MIME-Version: 1.0 Received: by 10.229.40.213 with SMTP id l21mr4091145qce.143.1303195897419; Mon, 18 Apr 2011 23:51:37 -0700 (PDT) Received: by 10.229.0.137 with HTTP; Mon, 18 Apr 2011 23:51:37 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> Date: Mon, 18 Apr 2011 23:51:37 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Wilkins Content-Type: multipart/alternative; boundary=00163649a97189d90d04a13ff0bf X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 06:51:42 -0000 --00163649a97189d90d04a13ff0bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In making this change, I am stuck on the following, which leads me to prefe= r Greg's proposal to John's: 1. In John's proposal, the type of control frame is determined by the first byte of the payload. How does this work in the presence of extensions? The payload is defined as extension data followed by concatenation data. If I get an opcode of 0x1, followed by 12 bytes, which of those 12 bytes is the actual byte that tells me if it's close/ping/pong? As an intermediary, I'm now basically unable to determine anything. If one of the extensions is "gzip all the application data" I am hopeless. Even if the extensions don't touch the application data, then I still have to figure out where the extension data ends and where the control frame data begins. (Is it simply the last byte of the payload? What if we ever want to allow things like an application-provided closure reason along with the close frame? Now where i= s it?) This gets really complicated, unless we say that extension data is never present with control frames, but that also seems undesirable. 2. The masking consensus was that all payload data is masked. The control frame is now in the payload. Yuck. We essentially have to say there's no application-provided data that will ever ride along with a control frame an= d that control frames are not masked, or we have to unmask control frames, an= d it starts getting overly complicated. Basically, I'm worried that this is over-complicating things with little actual benefit. Greg's proposal adds some benefit (clear distinction betwee= n control frame and data frame) with little cost. -Ian 2011/3/8 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83= =E3=83=86=E3=82=A3) > I am rather ambivalent, however if we do it we should do it now. I do agr= ee > with the following: > > 1. It would be nice to understand what is a "control" frame, especially i= f > an extension wants to define its own definition of a control frame that > should not be fragmented. If we had a single control frame opcode and the > first byte defined which control it was (with some number reserved for > extensions), this would be much clearer. > > The other points about scarcity of opcodes or making it lower cost hold > some value to me, but frankly not nearly as much as the first. > > I will make the change unless anyone objects strongly. > > > On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins wrote: > >> Ian, >> >> What are your thoughts about this as editor? there does not appear to >> be any opposed and there is support for Johns original proposal. >> It would be good to know soon if you think this will be in -07, as it >> affects the server APIs somewhat. >> >> cheers >> >> >> >> >> On 4 March 2011 04:25, Bruce Atherton wrote: >> > On 02/03/2011 11:13 AM, John Tamplin wrote: >> >> >> >> My suggestion would be to define a CONTROL opcode, and then for that >> >> opcode the first byte of the payload defines which control frame is >> >> present. >> > >> > +1. Simply from a design perspective it makes more sense. Text frame, >> binary >> > frame, continuation frame, and control frame all feel like the same >> level of >> > abstraction. Breaking control down into ping, pong, and close seems li= ke >> an >> > abstraction imbalance. And what do you gain by taking this deep-dive o= n >> the >> > control frames? Saving a single byte from a frame that is already tiny= ? >> > >> > Plus there are the other benefits you mention. I just think this makes >> > sense. >> > >> > >> > _______________________________________________ >> > 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 >> > > --00163649a97189d90d04a13ff0bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In making this change, I am stuck on the following, which leads me to prefe= r Greg's proposal to John's:

1. In John's pr= oposal, the type of control frame is determined by the first byte of the pa= yload. How does this work in the presence of extensions? The payload is def= ined as extension data followed by concatenation data. If I get an opcode o= f 0x1, followed by 12 bytes, which of those 12 bytes is the actual byte tha= t tells me if it's close/ping/pong? As an intermediary, I'm now bas= ically unable to determine anything. If one of the extensions is "gzip= all the application data" I am hopeless. Even if the extensions don&#= 39;t touch the application data, then I still have to figure out where the = extension data ends and where the control frame data begins. (Is it simply = the last byte of the payload? What if we ever want to allow things like an = application-provided closure reason along with the close frame? Now where i= s it?) This gets really complicated, unless we say that extension data is n= ever present with control frames, but that also seems undesirable.

2. The masking consensus was that all payload data is m= asked. The control frame is now in the payload. Yuck. We essentially have t= o say there's no application-provided data that will ever ride along wi= th a control frame and that control frames are not masked, or we have to un= mask control frames, and it starts getting overly complicated.

Basically, I'm worried that this is over-complicati= ng things with little actual benefit. Greg's proposal adds some benefit= (clear distinction between control frame and data frame) with little cost.=

-Ian

2011= /3/8 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3= =83=86=E3=82=A3) <ifette@google.com>
I am rather=C2=A0ambivalent, however if we do it we should do it now. I do = agree with the following:

1. It would be nice to underst= and what is a "control" frame, especially if an extension wants t= o define its own definition of a control frame that should not be fragmente= d. If we had a single control frame opcode and the first byte defined which= control it was (with some number reserved for extensions), this would be m= uch clearer.

The other points about scarcity of opcodes or making it= lower cost hold some value to me, but frankly not nearly as much as the fi= rst.

I will make the change unless anyone objects = strongly.=C2=A0


On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins= <gregw@webtide.com> wrote:
bruce@callenish.com> wrote:
> On 02/03/2011 11:13 AM, John Tamplin wrote:
>>
>> My suggestion would be to define a CONTROL opcode, and then for th= at
>> opcode the first byte of the payload defines which control frame i= s
>> present.
>
> +1. Simply from a design perspective it makes more sense. Text frame, = binary
> frame, continuation frame, and control frame all feel like the same le= vel of
> abstraction. Breaking control down into ping, pong, and close seems li= ke an
> abstraction imbalance. And what do you gain by taking this deep-dive o= n the
> control frames? Saving a single byte from a frame that is already tiny= ?
>
> Plus there are the other benefits you mention. I just think this makes=
> sense.
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--00163649a97189d90d04a13ff0bf-- From ifette@google.com Tue Apr 19 00:07:39 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9EF5EE0696 for ; Tue, 19 Apr 2011 00:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CefpeAMKENDU for ; Tue, 19 Apr 2011 00:07:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 3143BE05F5 for ; Tue, 19 Apr 2011 00:07:38 -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 p3J77bbW004932 for ; Tue, 19 Apr 2011 00:07:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303196858; bh=66clfu5INaDapfbzmUNHNJa+z40=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=ZJLfhnTKM3Yv7VbR2rbSiyZkZbtfsF3AZvSS+l3hFFx+LcHnF0lSeHLsM2RkwIwr6 InqWKBBfzbrBjLK9RQrYg== Received: from qwc9 (qwc9.prod.google.com [10.241.193.137]) by kpbe16.cbf.corp.google.com with ESMTP id p3J77a4e024644 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 00:07:36 -0700 Received: by qwc9 with SMTP id 9so5027051qwc.27 for ; Tue, 19 Apr 2011 00:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8jueJHpdDhnlhgZg1GvHfMTY+lc5GGCXXHQ/Nwh7cZg=; b=VZL4HZQIjwK+grZlAeSAtPuWI3tVQLpDT4GelpEsv60Y6IpaqUNMmcND3OiR/4r4Kz 1PmcMeegO387RFG+W8gg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=qfi0xI/iWSmNVBYzbYikPyU3VWB/Xq2bqHHZBklW4Uib3yTF6zzYrCppitiSn8SNx7 zhXtM5YON/iniRKrxg1Q== MIME-Version: 1.0 Received: by 10.229.118.78 with SMTP id u14mr4141826qcq.29.1303196855825; Tue, 19 Apr 2011 00:07:35 -0700 (PDT) Received: by 10.229.0.137 with HTTP; Tue, 19 Apr 2011 00:07:35 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> Date: Tue, 19 Apr 2011 00:07:35 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd5f4aaa9f68a04a140299b X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 07:07:39 -0000 --000e0cd5f4aaa9f68a04a140299b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Forgot that -06 added close reasons already. "The Close message MAY contain a body (the "application data" portion of the frame) that indicates a reason for closing, such as an endpoint shutting down, an endpoint having received a message too large, or an endpoint having received a message that does not conform to the format expected by the other endpoint. If there is a body, the first two bytes of the body MUST be a 2-byte integer (in network byte order) representin= g a status code defined in . Followi= ng the 2-byte integer the body MAY contain UTF-8 encoded data, the interpretation of which is not defined by this specification.= " So again, in this case, figuring out where the opcode is in the case of a close frame is, without understanding the extensions, would be a nightmare. Imagine an extension were in use that added 4 bytes to every frame. Ping would now appear as a 5-byte payload with the opcode in byte 5 (end), but close would be a 7+-byte payload with the close opcode not at the end (stil= l at 5, but an intermediary not knowing that the extension length was 4 would now be hopeless to find this.) -Ian 2011/4/18 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83= =E3=83=86=E3=82=A3) > In making this change, I am stuck on the following, which leads me to > prefer Greg's proposal to John's: > > 1. In John's proposal, the type of control frame is determined by the fir= st > byte of the payload. How does this work in the presence of extensions? Th= e > payload is defined as extension data followed by concatenation data. If I > get an opcode of 0x1, followed by 12 bytes, which of those 12 bytes is th= e > actual byte that tells me if it's close/ping/pong? As an intermediary, I'= m > now basically unable to determine anything. If one of the extensions is > "gzip all the application data" I am hopeless. Even if the extensions don= 't > touch the application data, then I still have to figure out where the > extension data ends and where the control frame data begins. (Is it simpl= y > the last byte of the payload? What if we ever want to allow things like a= n > application-provided closure reason along with the close frame? Now where= is > it?) This gets really complicated, unless we say that extension data is > never present with control frames, but that also seems undesirable. > > 2. The masking consensus was that all payload data is masked. The control > frame is now in the payload. Yuck. We essentially have to say there's no > application-provided data that will ever ride along with a control frame = and > that control frames are not masked, or we have to unmask control frames, = and > it starts getting overly complicated. > > Basically, I'm worried that this is over-complicating things with little > actual benefit. Greg's proposal adds some benefit (clear distinction betw= een > control frame and data frame) with little cost. > > -Ian > > 2011/3/8 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83= =83=E3=83=86=E3=82=A3) > > I am rather ambivalent, however if we do it we should do it now. I do agr= ee >> with the following: >> >> 1. It would be nice to understand what is a "control" frame, especially = if >> an extension wants to define its own definition of a control frame that >> should not be fragmented. If we had a single control frame opcode and th= e >> first byte defined which control it was (with some number reserved for >> extensions), this would be much clearer. >> >> The other points about scarcity of opcodes or making it lower cost hold >> some value to me, but frankly not nearly as much as the first. >> >> I will make the change unless anyone objects strongly. >> >> >> On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins wrote: >> >>> Ian, >>> >>> What are your thoughts about this as editor? there does not appear to >>> be any opposed and there is support for Johns original proposal. >>> It would be good to know soon if you think this will be in -07, as it >>> affects the server APIs somewhat. >>> >>> cheers >>> >>> >>> >>> >>> On 4 March 2011 04:25, Bruce Atherton wrote: >>> > On 02/03/2011 11:13 AM, John Tamplin wrote: >>> >> >>> >> My suggestion would be to define a CONTROL opcode, and then for that >>> >> opcode the first byte of the payload defines which control frame is >>> >> present. >>> > >>> > +1. Simply from a design perspective it makes more sense. Text frame, >>> binary >>> > frame, continuation frame, and control frame all feel like the same >>> level of >>> > abstraction. Breaking control down into ping, pong, and close seems >>> like an >>> > abstraction imbalance. And what do you gain by taking this deep-dive = on >>> the >>> > control frames? Saving a single byte from a frame that is already tin= y? >>> > >>> > Plus there are the other benefits you mention. I just think this make= s >>> > sense. >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> > --000e0cd5f4aaa9f68a04a140299b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Forgot that -06 added close reasons already. "<t>The Close messa= ge MAY contain a body (the &quot;application
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 data&quot; portion of the frame) that indicates a reason<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for closing, such as an endpoi= nt shutting down, an endpoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 having received a message too large= , or an endpoint having
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 receiv= ed a message that does not conform to the format expected
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 by the other endpoint. If there is a body, the = first two bytes of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 body MUST be a 2-byte integer (in n= etwork byte order) representing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 a status code defined in <xref target=3D"status_codes"/>= ;. Following the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2-byte intege= r the body MAY contain UTF-8 encoded data, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interpretation of which is not defi= ned by this specification.</t>"

So agai= n, in this case, figuring out where the opcode is in the case of a close fr= ame is, without understanding the extensions, would be a nightmare. Imagine= an extension were in use that added 4 bytes to every frame. Ping would now= appear as a 5-byte payload with the opcode in byte 5 (end), but close woul= d be a 7+-byte payload with the close opcode not at the end (still at 5, bu= t an intermediary not knowing that the extension length was 4 would now be = hopeless to find this.)

-Ian

2011/4/18 Ian = Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3= =82=A3) <ifette@g= oogle.com>
In making this change, I am stuck on the following, which leads me to prefe= r Greg's proposal to John's:

1. In John's pr= oposal, the type of control frame is determined by the first byte of the pa= yload. How does this work in the presence of extensions? The payload is def= ined as extension data followed by concatenation data. If I get an opcode o= f 0x1, followed by 12 bytes, which of those 12 bytes is the actual byte tha= t tells me if it's close/ping/pong? As an intermediary, I'm now bas= ically unable to determine anything. If one of the extensions is "gzip= all the application data" I am hopeless. Even if the extensions don&#= 39;t touch the application data, then I still have to figure out where the = extension data ends and where the control frame data begins. (Is it simply = the last byte of the payload? What if we ever want to allow things like an = application-provided closure reason along with the close frame? Now where i= s it?) This gets really complicated, unless we say that extension data is n= ever present with control frames, but that also seems undesirable.

2. The masking consensus was that all payload data is m= asked. The control frame is now in the payload. Yuck. We essentially have t= o say there's no application-provided data that will ever ride along wi= th a control frame and that control frames are not masked, or we have to un= mask control frames, and it starts getting overly complicated.

Basically, I'm worried that this is over-complicati= ng things with little actual benefit. Greg's proposal adds some benefit= (clear distinction between control frame and data frame) with little cost.=

-Ian

2011= /3/8 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3= =83=86=E3=82=A3) <ifette@google.com>

I am rather=C2=A0ambivalent, however if we do it we should do it now. I do = agree with the following:

1. It would be nice to underst= and what is a "control" frame, especially if an extension wants t= o define its own definition of a control frame that should not be fragmente= d. If we had a single control frame opcode and the first byte defined which= control it was (with some number reserved for extensions), this would be m= uch clearer.

The other points about scarcity of opcodes or making it= lower cost hold some value to me, but frankly not nearly as much as the fi= rst.

I will make the change unless anyone objects = strongly.=C2=A0


On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins= <gregw@webtide.com> wrote:
bruce@callenish.com> wrote:
> On 02/03/2011 11:13 AM, John Tamplin wrote:
>>
>> My suggestion would be to define a CONTROL opcode, and then for th= at
>> opcode the first byte of the payload defines which control frame i= s
>> present.
>
> +1. Simply from a design perspective it makes more sense. Text frame, = binary
> frame, continuation frame, and control frame all feel like the same le= vel of
> abstraction. Breaking control down into ping, pong, and close seems li= ke an
> abstraction imbalance. And what do you gain by taking this deep-dive o= n the
> control frames? Saving a single byte from a frame that is already tiny= ?
>
> Plus there are the other benefits you mention. I just think this makes=
> sense.
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi



--000e0cd5f4aaa9f68a04a140299b-- From arman@noemax.com Tue Apr 19 00:31:07 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86D36E06CC for ; Tue, 19 Apr 2011 00:31:07 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm4yYjP1oYfO for ; Tue, 19 Apr 2011 00:31:07 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfc.amsl.com (Postfix) with ESMTP id E102CE0665 for ; Tue, 19 Apr 2011 00:31:06 -0700 (PDT) Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id CLY56205; Tue, 19 Apr 2011 10:31:05 +0300 From: "Arman Djusupov" To: "'Greg Wilkins'" , "'Willy Tarreau'" References: <4DA820B7.5090409@rlgsc.com> <005301cbfb82$4eca4470$ec5ecd50$@noemax.com> <20110415154617.GA26904@1wt.eu> In-Reply-To: Date: Tue, 19 Apr 2011 10:30:55 +0300 Message-ID: <001a01cbfe63$bca6da60$35f48f20$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGKmU+NpPxCzLOrT0Nbrh1Wu6o7QAJKm/UzAcOoz+YDjec2lwI4qsLuAcb2xuaUirV+oA== Content-Language: en-us Cc: hybi@ietf.org, gezelter@rlgsc.com Subject: Re: [hybi] On Fragmenting of Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 07:31:07 -0000 Hello Greg, > We have response codes 413 and 414 to cope with these circumstances, and > maybe the equivalent is sufficient for websocket - but I hardly see having the > ability to declare a maximal frame and/or message size as bad thing - at > worse it might be under utilised. I don't think 413 type of error codes can be used efficiently since many simple client implementations do not read from the connection while sending a POST request. As a result, even if the server tries to respond with 413, the response is not getting read until the client has sent the complete request message. So what happens is that the server either writes out the error response and drops the connection, or writes out the error response but keeps reading and discarding the remaining incoming message to recover the HTTP connection. With best regards, Arman From salvatore.loreto@ericsson.com Tue Apr 19 05:36:20 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 95AA1E06A7 for ; Tue, 19 Apr 2011 05:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLE8meXAptdw for ; Tue, 19 Apr 2011 05:36:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 94790E068A for ; Tue, 19 Apr 2011 05:36:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-9e-4dad81c15191 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 66.A1.11171.1C18DAD4; Tue, 19 Apr 2011 14:36:17 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Apr 2011 14:36:17 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 34ABE232D for ; Tue, 19 Apr 2011 15:36:17 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1E2D150B42 for ; Tue, 19 Apr 2011 15:36:17 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5E44F50AC5 for ; Tue, 19 Apr 2011 15:36:16 +0300 (EEST) Message-ID: <4DAD81BF.9080707@ericsson.com> Date: Tue, 19 Apr 2011 14:36:16 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: hybi@ietf.org References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030208070602060804090109" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:36:20 -0000 --------------030208070602060804090109 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit for the sake of clarification, the Greg proposal is related to partitioning the opcodes; ref: http://www.ietf.org/mail-archive/web/hybi/current/msg06696.html /Sal On 4/19/11 9:07 AM, Ian Fette (イアンフェッティ) wrote: > Forgot that -06 added close reasons already. "The Close message MAY > contain a body (the "application > data" portion of the frame) that indicates a reason > for closing, such as an endpoint shutting down, an endpoint > having received a message too large, or an endpoint having > received a message that does not conform to the format expected > by the other endpoint. If there is a body, the first two > bytes of the > body MUST be a 2-byte integer (in network byte order) > representing > a status code defined in . > Following the > 2-byte integer the body MAY contain UTF-8 encoded data, the > interpretation of which is not defined by this > specification." > > So again, in this case, figuring out where the opcode is in the case > of a close frame is, without understanding the extensions, would be a > nightmare. Imagine an extension were in use that added 4 bytes to > every frame. Ping would now appear as a 5-byte payload with the opcode > in byte 5 (end), but close would be a 7+-byte payload with the close > opcode not at the end (still at 5, but an intermediary not knowing > that the extension length was 4 would now be hopeless to find this.) > > -Ian > > 2011/4/18 Ian Fette (イアンフェッティ) > > > In making this change, I am stuck on the following, which leads me > to prefer Greg's proposal to John's: > > 1. In John's proposal, the type of control frame is determined by > the first byte of the payload. How does this work in the presence > of extensions? The payload is defined as extension data followed > by concatenation data. If I get an opcode of 0x1, followed by 12 > bytes, which of those 12 bytes is the actual byte that tells me if > it's close/ping/pong? As an intermediary, I'm now basically unable > to determine anything. If one of the extensions is "gzip all the > application data" I am hopeless. Even if the extensions don't > touch the application data, then I still have to figure out where > the extension data ends and where the control frame data begins. > (Is it simply the last byte of the payload? What if we ever want > to allow things like an application-provided closure reason along > with the close frame? Now where is it?) This gets really > complicated, unless we say that extension data is never present > with control frames, but that also seems undesirable. > > 2. The masking consensus was that all payload data is masked. The > control frame is now in the payload. Yuck. We essentially have to > say there's no application-provided data that will ever ride along > with a control frame and that control frames are not masked, or we > have to unmask control frames, and it starts getting overly > complicated. > > Basically, I'm worried that this is over-complicating things with > little actual benefit. Greg's proposal adds some benefit (clear > distinction between control frame and data frame) with little cost. > > -Ian > > 2011/3/8 Ian Fette (イアンフェッティ) > > > I am rather ambivalent, however if we do it we should do it > now. I do agree with the following: > > 1. It would be nice to understand what is a "control" frame, > especially if an extension wants to define its own definition > of a control frame that should not be fragmented. If we had a > single control frame opcode and the first byte defined which > control it was (with some number reserved for extensions), > this would be much clearer. > > The other points about scarcity of opcodes or making it lower > cost hold some value to me, but frankly not nearly as much as > the first. > > I will make the change unless anyone objects strongly. > > > On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins > > wrote: > > Ian, > > What are your thoughts about this as editor? there does > not appear to > be any opposed and there is support for Johns original > proposal. > It would be good to know soon if you think this will be in > -07, as it > affects the server APIs somewhat. > > cheers > > > > > On 4 March 2011 04:25, Bruce Atherton > wrote: > > On 02/03/2011 11:13 AM, John Tamplin wrote: > >> > >> My suggestion would be to define a CONTROL opcode, and > then for that > >> opcode the first byte of the payload defines which > control frame is > >> present. > > > > +1. Simply from a design perspective it makes more > sense. Text frame, binary > > frame, continuation frame, and control frame all feel > like the same level of > > abstraction. Breaking control down into ping, pong, and > close seems like an > > abstraction imbalance. And what do you gain by taking > this deep-dive on the > > control frames? Saving a single byte from a frame that > is already tiny? > > > > Plus there are the other benefits you mention. I just > think this makes > > sense. > > > > > > _______________________________________________ > > 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 > > > > --------------030208070602060804090109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit for the sake of clarification,
the Greg proposal is related to partitioning the opcodes;

ref:  http://www.ietf.org/mail-archive/web/hybi/current/msg06696.html

/Sal

On 4/19/11 9:07 AM, Ian Fette (イアンフェッティ) wrote:
Forgot that -06 added close reasons already. "<t>The Close message MAY contain a body (the &quot;application
          data&quot; portion of the frame) that indicates a reason
          for closing, such as an endpoint shutting down, an endpoint
          having received a message too large, or an endpoint having
          received a message that does not conform to the format expected
          by the other endpoint. If there is a body, the first two bytes of the
          body MUST be a 2-byte integer (in network byte order) representing
          a status code defined in <xref target="status_codes"/>. Following the
          2-byte integer the body MAY contain UTF-8 encoded data, the
          interpretation of which is not defined by this specification.</t>"

So again, in this case, figuring out where the opcode is in the case of a close frame is, without understanding the extensions, would be a nightmare. Imagine an extension were in use that added 4 bytes to every frame. Ping would now appear as a 5-byte payload with the opcode in byte 5 (end), but close would be a 7+-byte payload with the close opcode not at the end (still at 5, but an intermediary not knowing that the extension length was 4 would now be hopeless to find this.)

-Ian

2011/4/18 Ian Fette (イアンフェッティ) <ifette@google.com>
In making this change, I am stuck on the following, which leads me to prefer Greg's proposal to John's:

1. In John's proposal, the type of control frame is determined by the first byte of the payload. How does this work in the presence of extensions? The payload is defined as extension data followed by concatenation data. If I get an opcode of 0x1, followed by 12 bytes, which of those 12 bytes is the actual byte that tells me if it's close/ping/pong? As an intermediary, I'm now basically unable to determine anything. If one of the extensions is "gzip all the application data" I am hopeless. Even if the extensions don't touch the application data, then I still have to figure out where the extension data ends and where the control frame data begins. (Is it simply the last byte of the payload? What if we ever want to allow things like an application-provided closure reason along with the close frame? Now where is it?) This gets really complicated, unless we say that extension data is never present with control frames, but that also seems undesirable.

2. The masking consensus was that all payload data is masked. The control frame is now in the payload. Yuck. We essentially have to say there's no application-provided data that will ever ride along with a control frame and that control frames are not masked, or we have to unmask control frames, and it starts getting overly complicated.

Basically, I'm worried that this is over-complicating things with little actual benefit. Greg's proposal adds some benefit (clear distinction between control frame and data frame) with little cost.

-Ian

2011/3/8 Ian Fette (イアンフェッティ) <ifette@google.com>

I am rather ambivalent, however if we do it we should do it now. I do agree with the following:

1. It would be nice to understand what is a "control" frame, especially if an extension wants to define its own definition of a control frame that should not be fragmented. If we had a single control frame opcode and the first byte defined which control it was (with some number reserved for extensions), this would be much clearer.

The other points about scarcity of opcodes or making it lower cost hold some value to me, but frankly not nearly as much as the first.

I will make the change unless anyone objects strongly. 


On Tue, Mar 8, 2011 at 8:13 PM, Greg Wilkins <gregw@webtide.com> wrote:
Ian,

What are your thoughts about this as editor?  there does not appear to
be any opposed and there is support for Johns original proposal.
It would be good to know soon if you think this will be in -07, as it
affects the server APIs somewhat.

cheers




On 4 March 2011 04:25, Bruce Atherton <bruce@callenish.com> wrote:
> On 02/03/2011 11:13 AM, John Tamplin wrote:
>>
>> My suggestion would be to define a CONTROL opcode, and then for that
>> opcode the first byte of the payload defines which control frame is
>> present.
>
> +1. Simply from a design perspective it makes more sense. Text frame, binary
> frame, continuation frame, and control frame all feel like the same level of
> abstraction. Breaking control down into ping, pong, and close seems like an
> abstraction imbalance. And what do you gain by taking this deep-dive on the
> control frames? Saving a single byte from a frame that is already tiny?
>
> Plus there are the other benefits you mention. I just think this makes
> sense.
>
>
> _______________________________________________
> 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




--------------030208070602060804090109-- From pmcmanus@mozilla.com Tue Apr 19 06:04:04 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C914E06C4 for ; Tue, 19 Apr 2011 06:04:04 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q9u73CFaOL5 for ; Tue, 19 Apr 2011 06:04:03 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfc.amsl.com (Postfix) with ESMTP id D7F8FE065A for ; Tue, 19 Apr 2011 06:04:03 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 79B4710303; Tue, 19 Apr 2011 09:04:02 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 405E0102A6; Tue, 19 Apr 2011 09:03:58 -0400 (EDT) From: Patrick McManus To: Salvatore Loreto In-Reply-To: <4DAD81BF.9080707@ericsson.com> References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD81BF.9080707@ericsson.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Apr 2011 09:03:30 -0400 Message-ID: <1303218210.20918.609.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 13:04:04 -0000 On Tue, 2011-04-19 at 14:36 +0200, Salvatore Loreto wrote: > for the sake of clarification, > the Greg proposal is related to partitioning the opcodes; > > ref: http://www.ietf.org/mail-archive/web/hybi/current/msg06696.html If we are to rearrange the opcodes, doing it this way (i.e. just rearranging the assignments so you can bit-test the is-opcode() attribute) is my preferred path. I am also fine, prefer even, leaving them as is. -Patrick From andy.warmcat.com@googlemail.com Tue Apr 19 06:26:03 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6D13CE06EE for ; Tue, 19 Apr 2011 06:26:03 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjulOU5brSNJ for ; Tue, 19 Apr 2011 06:26:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 88052E0663 for ; Tue, 19 Apr 2011 06:26:02 -0700 (PDT) Received: by wwa36 with SMTP id 36so4649765wwa.13 for ; Tue, 19 Apr 2011 06:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8y78pn9q0EZNZ/F6RXQdrMXWroQYlB+ZkcwfMoIrRyY=; b=IATqKmTIwlDctIRTZOgmfUvQVeduYD/4LVb3MPkcK4axvXPomeTq3OXj1dDW/dh1LC Uwe/YxXKNEB8FVBBuh4NF2Gamo7H8pmB77hFamGskcHuOha9xLcaF1vza682MLK09wNG WH77s1DD/yO/uHdAxJkWVMnDL72LWqxOEmrPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RhFYf7Sv+0IGF/TtFTZVoKIIVHakQAiEkTxKeTAIajWnU6ta39PiXueTmzeIxuO27Y A/yPb2N0I4y0jO2Fmn+iK996GsOCwU9reRFGIeDR2S2OMM9FwVJno/CyCJInMbwNp97A 7Ww8qGCrwGfX2YZMWlKqoB/jh0vXIRjgpdX0s= Received: by 10.227.53.206 with SMTP id n14mr945253wbg.14.1303219561848; Tue, 19 Apr 2011 06:26:01 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id u9sm3892266wbg.34.2011.04.19.06.25.58 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 06:25:59 -0700 (PDT) Sender: Andy Green Message-ID: <4DAD8D65.4050608@warmcat.com> Date: Tue, 19 Apr 2011 14:25:57 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: ifette@google.com References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 13:26:03 -0000 On 04/19/2011 08:07 AM, Somebody in the thread at some point said: Hi - > So again, in this case, figuring out where the opcode is in the case of > a close frame is, without understanding the extensions, would be a > nightmare. Imagine an extension were in use that added 4 bytes to every > frame. Ping would now appear as a 5-byte payload with the opcode in byte > 5 (end), but close would be a 7+-byte payload with the close opcode not > at the end (still at 5, but an intermediary not knowing that the > extension length was 4 would now be hopeless to find this.) You can't really solve this without knowing the length of the extension data either implicitly because you know the extension or explicitly so you can skip it. (Partitioning the opcode space isn't related to this at all). If the close frame payload was only the 2 bytes it'd be easy you would just look at the last two bytes of the payload. But with arbitrary additional bytes there's no way to know what the middle is. Nothing's using this per-frame extended data at the moment. One way to solve it would be to get rid of the per-frame extended data concept, and evict what would have been associated with the payload to a prior frame using extended opcode. Then a dumb intermediary knows how to skip that frame and the control frame is parseable again no matter what extensions exist. -Andy From jat@google.com Tue Apr 19 07:13:31 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC2F7E0754 for ; Tue, 19 Apr 2011 07:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.543 X-Spam-Level: X-Spam-Status: No, score=-107.543 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j59kBVEWirAK for ; Tue, 19 Apr 2011 07:13:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id BB54DE06E9 for ; Tue, 19 Apr 2011 07:13:30 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p3JEDTOh023435 for ; Tue, 19 Apr 2011 07:13:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303222409; bh=T2yFMpDesuyh6IJyo08JYn2iLk0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=NodiD2dvN5N0hSiAbLG8Y4khJj5NUFj1no2ecNuzCO+2HDDRBQ8XQQoncFqeZtNIg S9i0HTXOleM8kpTlJHRcQ== Received: from yia13 (yia13.prod.google.com [10.243.65.13]) by kpbe19.cbf.corp.google.com with ESMTP id p3JEDDmD001274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Apr 2011 07:13:27 -0700 Received: by yia13 with SMTP id 13so2520250yia.34 for ; Tue, 19 Apr 2011 07:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=JdHxD6aam+GCTq2W6allOlBuxkpuzLHwBVgEauglvkA=; b=lpTdT/BFpCMPI6xkDmdy9WBIGAjHLoLTAafTnSiLfj44e8FgjuRlZsIxQKpD2Cspdc wwawKpNPS7EqMPNaMwbw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=CDIEMUircK0hRNrOSFdwBp5dY42ICfMjg+cNAWLzINbXT98PurktulhaiuL0TxA0cS BHKef9aTHNaNkzgL/+cw== Received: by 10.151.28.15 with SMTP id f15mr473819ybj.295.1303222407145; Tue, 19 Apr 2011 07:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Tue, 19 Apr 2011 07:13:07 -0700 (PDT) In-Reply-To: <4DAD8D65.4050608@warmcat.com> References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> From: John Tamplin Date: Tue, 19 Apr 2011 10:13:07 -0400 Message-ID: To: Andy Green Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:13:31 -0000 On Tue, Apr 19, 2011 at 9:25 AM, Andy Green wrote: > Nothing's using this per-frame extended data at the moment. =C2=A0One way= to > solve it would be to get rid of the per-frame extended data concept, and > evict what would have been associated with the payload to a prior frame > using extended opcode. =C2=A0Then a dumb intermediary knows how to skip t= hat > frame and the control frame is parseable again no matter what extensions > exist. Then you have to maintain state across frames to know that extension data goes with the next frame. For example, if the extension data is some form of compression dictionary, you can't interpret the compressed payload contents without it, so it feels totally wrong to move that to another frame. When we came up with this framing, having the extension data area was important to show that all of the ways that people wanted to extend the protocol could be accommodated. If we drop that now, then we are reopening the framing discussion and have to find new ways to handle extension mechanisms that were enabled by it, or convince everyone involved that they really aren't necessary. The inability to convince everyone that their pet extension ideas weren't important was why the three vectors for extension (reserved bits, reserved opcodes, extension data area) were put in the framing in the first place. I'm not sure it is necessary that intermediaries need to be able to understand frames containing extensions they don't understand. If it is, then instead of leaving the extension area open to definition by extensions, we would need to define some tag/value format that allows intermediaries to skip unknown extensions (and probably tag some extensions as critical, meaning the frame can't be processed if you don't understand the extension). However, note that defining exactly what this format would be was exactly one of the circular discussions that led to months of debate about the framing. Note that making the mask key be extension data becomes either inconsistent (no tag) or more expensive (tag bytes) in this scenario. Personally, I think the way we have things defined is the best compromise for the base protocol -- the endpoints must know all the negotiated extensions, and having that information allows them to know exactly where and in what format various fields are in the extension data. Intermediaries cannot participate in the extension negotiation (if they do, then they aren't an intermediary but both a server and a client in the connection between ultimate endpoints), so they have to be prepared for the endpoints negotiating extensions they don't understand. We already have language in the spec that deals with this, in that intermediaries are not allowed to fragment/coalesce frames if an extension is in use they don't understand. Regarding the question at hand about control opcodes or close frame information, is it necessary that an intermediary be able to interpret them in the face of unknown extensions? If it is, then what if we wanted to define a new compression scheme as an extension -- an intermediary that doesn't understand that extension has no chance of understanding any content, so I believe that restriction imposes too much cost. So, my feeling is that it is fine if only the endpoints, which necessarily know how to determine the size and contents of the extension data area, are able to interpret the extended control opcode and close frame flags. --=20 John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Tue Apr 19 07:48:50 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6882E075A for ; Tue, 19 Apr 2011 07:48:50 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMnMm-U2-ik4 for ; Tue, 19 Apr 2011 07:48:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id E7D33E0700 for ; Tue, 19 Apr 2011 07:48:49 -0700 (PDT) Received: by wwa36 with SMTP id 36so4722518wwa.13 for ; Tue, 19 Apr 2011 07:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RDP3Sj//MaDqXaQQIn+PpN+OAXgqyqEmgYFLUeiWmfs=; b=Jia8BQhu45d805dAxS+ov4K59vzNFcq3owCaYnvCkp1nBxSYoM58qyAYSUXhSHq/iB go01hn+c0pN8kPqIwYg0Ik5w+PEOBmiXlo+iHNgoNpR7Bj2Ou+8Z8k2PJ6l2xJxOye5L J4k1S/4sgzXv3nxQ7InTdqfD0x408j68uaAQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SODKmum8MgbIB99uTrdGeHth74sDXgCMO9U7M8zMJ7frMsxRMLmI/yxfDF+BkJdM/z jF7riWFPAnGgaySxtA3KAdQI/tgmjrDjE0H7LXU2JWMy+gDQ3H3BXKW54jYulns0KktF OPcfH/FodDIed79VR5Hp0JTN+blSK+XYVqWx8= Received: by 10.227.39.66 with SMTP id f2mr6394967wbe.2.1303224528869; Tue, 19 Apr 2011 07:48:48 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id y12sm3936889wby.59.2011.04.19.07.48.46 (version=SSLv3 cipher=OTHER); Tue, 19 Apr 2011 07:48:47 -0700 (PDT) Sender: Andy Green Message-ID: <4DADA0CD.8080306@warmcat.com> Date: Tue, 19 Apr 2011 15:48:45 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: John Tamplin References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 14:48:51 -0000 On 04/19/2011 03:13 PM, Somebody in the thread at some point said: > On Tue, Apr 19, 2011 at 9:25 AM, Andy Green wrote: >> Nothing's using this per-frame extended data at the moment. One way to >> solve it would be to get rid of the per-frame extended data concept, and >> evict what would have been associated with the payload to a prior frame >> using extended opcode. Then a dumb intermediary knows how to skip that >> frame and the control frame is parseable again no matter what extensions >> exist. > > Then you have to maintain state across frames to know that extension > data goes with the next frame. For example, if the extension data is > some form of compression dictionary, you can't interpret the > compressed payload contents without it, so it feels totally wrong to > move that to another frame. Well, everything on the wire is depending on what went before in a real way anyway, you can't re-sync up in this protocol, come in after the handshake and expect to know what was negotiated and so on. So it seems OK to loosely bind frames like that to me, it's not fragile since only control frames can come inbetween. But anyway I agree with the rest of what you wrote making it moot --> > Regarding the question at hand about control opcodes or close frame > information, is it necessary that an intermediary be able to interpret > them in the face of unknown extensions? If it is, then what if we > wanted to define a new compression scheme as an extension -- an > intermediary that doesn't understand that extension has no chance of > understanding any content, so I believe that restriction imposes too > much cost. So, my feeling is that it is fine if only the endpoints, > which necessarily know how to determine the size and contents of the > extension data area, are able to interpret the extended control opcode > and close frame flags. You're right, everybody needs to know that there has been a close event. But only the endpoints, who must know the extended part length, will care about any detail though and then the opcode is enough for the other guys. -Andy From bruce@callenish.com Tue Apr 19 09:21:47 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40178E07C0 for ; Tue, 19 Apr 2011 09:21:47 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ8L6n+d7QOd for ; Tue, 19 Apr 2011 09:21:46 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfc.amsl.com (Postfix) with ESMTP id AF36AE07A1 for ; Tue, 19 Apr 2011 09:21:46 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QCDgP-0001xb-9m; Tue, 19 Apr 2011 09:21:45 -0700 Message-ID: <4DADB694.9030401@callenish.com> Date: Tue, 19 Apr 2011 09:21:40 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ifette@google.com References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:21:47 -0000 On 19/04/2011 12:07 AM, Ian Fette (イアンフェッティ) wrote: > > So again, in this case, figuring out where the opcode is in the case > of a close frame is, without understanding the extensions, would be a > nightmare. I agree. When I voted for this, I didn't fully appreciate the details. I was thinking that the opcode section of the header would be extensible, just as the length field is. So the opcode would be 1 byte unless it was the control opcode, in which case the next byte would be the sub-opcode for the specific control message being sent. Putting it into the payload after the extension data seems to me like a bad idea for the same reasons that masking the framing seemed like a bad idea. From gregw@intalio.com Tue Apr 19 15:33:12 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 590ECE0675 for ; Tue, 19 Apr 2011 15:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM+uV+v7QExC for ; Tue, 19 Apr 2011 15:33:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id BCC03E0673 for ; Tue, 19 Apr 2011 15:33:11 -0700 (PDT) Received: by vws12 with SMTP id 12so158137vws.31 for ; Tue, 19 Apr 2011 15:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.99 with SMTP id bz3mr751971vdc.117.1303252391079; Tue, 19 Apr 2011 15:33:11 -0700 (PDT) Received: by 10.52.158.104 with HTTP; Tue, 19 Apr 2011 15:33:11 -0700 (PDT) In-Reply-To: <4DAD8D65.4050608@warmcat.com> References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> Date: Wed, 20 Apr 2011 08:33:11 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:33:12 -0000 On 19 April 2011 23:25, Andy Green wrote: > Nothing's using this per-frame extended data at the moment. I think because it is close to unusable. One of the oft cited uses for it was for MUX, but interleaving of fragments is not possible with the current design, which has forced x-google-mux to go to great lengths to associated channel ID's with fragments. There is effectively no extension data anyway - since with out any length or structure any extension that used it is essentially just mutating the payload and then there is nothing to say the extension data is at the front, end or munged in the middle of the payload. I think at this stage, we need to just embrace this - and rather than saying we have extension data area, just say extension can mutate payloads, including pre-pending and/or appending data. The issue then is that intermediaries cannot fragment or aggregate frames unless they understand the extension. Again I think we should embrace this and allow arbitrary fragment orderings so that MUXing extensions can interleave fragments. The aggregating of these fragments into a message for a channel can only be done by something that understands the MUX extension, but then we already have that restriction, so why not allow the interleaving? cheers From ifette@google.com Tue Apr 19 15:48:25 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CDDF7E0701 for ; Tue, 19 Apr 2011 15:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2I9e8CJMnTo for ; Tue, 19 Apr 2011 15:48:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 0DBB5E071B for ; Tue, 19 Apr 2011 15:48:03 -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 p3JMm3Jk027018 for ; Tue, 19 Apr 2011 15:48:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303253283; bh=9EPtoRm6Wf0/8EykP1p/yywx88c=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=SguKHnwunTIX1K4pRBt+55n8CZkcyWrdCikN39eJWSTZJ0z8TRYWb5/p/M9JPNBS7 Vwrva17gbw4JgFM6A8bdQ== Received: from qyk2 (qyk2.prod.google.com [10.241.83.130]) by wpaz37.hot.corp.google.com with ESMTP id p3JMlsrt018576 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 15:48:02 -0700 Received: by qyk2 with SMTP id 2so2326442qyk.14 for ; Tue, 19 Apr 2011 15:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cEzTW8AsAy6k6/VGgj4EMLoHLvTGQeDSrQAveRSAWk8=; b=qeymKZDOM3yB3NNRB2LDNEe6uI0OxTYGN3Lu9WwAHxCumdsvC8nVulBPHIQdXYExlf KW8GlKShJYTrG7ExpT9Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=exqIYM4Xqrg54uQxR+LUpOKwp+kr4ThrTnY+uuG1CU/PwOKFtQiMckec2+wuS3lNDf H+XQxZ1atkrFenu4veyg== MIME-Version: 1.0 Received: by 10.229.44.198 with SMTP id b6mr4728820qcf.67.1303253282059; Tue, 19 Apr 2011 15:48:02 -0700 (PDT) Received: by 10.229.0.137 with HTTP; Tue, 19 Apr 2011 15:48:02 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> Date: Tue, 19 Apr 2011 15:48:02 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Greg Wilkins Content-Type: multipart/alternative; boundary=0016364184ffedf85004a14d4c08 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:48:26 -0000 --0016364184ffedf85004a14d4c08 Content-Type: text/plain; charset=UTF-8 Going back to the matter at hand re: the opcodes. I'm fairly convinced I don't want to have a generic control frame opcode and then define which control it is in the body. That said, I think something like Greg's earlier proposal would help and give us a bit of flexibility. e.g. 0x0-0x7 == data opcodes 0x8-0xF == control opcodes we would still have something like 4 unused opcodes in each bucket, and if we wanted to, we could always define something like "this particular opcode means you should look at this other place for more information" and still have intermediaries understand that this is a control frame, and shouldn't be e.g. fragmented or buffered excessively or merged with the next frame etc. It would be a relatively cheap change to make. -Ian On Tue, Apr 19, 2011 at 3:33 PM, Greg Wilkins wrote: > On 19 April 2011 23:25, Andy Green wrote: > > Nothing's using this per-frame extended data at the moment. > > I think because it is close to unusable. One of the oft cited uses > for it was for MUX, but interleaving of fragments is not possible with > the current design, which has forced x-google-mux to go to great > lengths to associated channel ID's with fragments. > > There is effectively no extension data anyway - since with out any > length or structure any extension that used it is essentially just > mutating the payload and then there is nothing to say the extension > data is at the front, end or munged in the middle of the payload. I > think at this stage, we need to just embrace this - and rather than > saying we have extension data area, just say extension can mutate > payloads, including pre-pending and/or appending data. > > The issue then is that intermediaries cannot fragment or aggregate > frames unless they understand the extension. Again I think we > should embrace this and allow arbitrary fragment orderings so that > MUXing extensions can interleave fragments. The aggregating of these > fragments into a message for a channel can only be done by something > that understands the MUX extension, but then we already have that > restriction, so why not allow the interleaving? > > > cheers > --0016364184ffedf85004a14d4c08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Going back to the matter at hand re: the opcodes. I'm fairly convinced = I don't want to have a generic control frame opcode and then define whi= ch control it is in the body. That said, I think something like Greg's = earlier proposal would help and give us a bit of flexibility.

e.g. 0x0-0x7 =3D=3D data opcodes
0x8-0xF =3D=3D co= ntrol opcodes

we would still have something like 4= unused opcodes in each bucket, and if we wanted to, we could always define= something like "this particular opcode means you should look at this = other place for more information" and still have intermediaries unders= tand that this is a control frame, and shouldn't be e.g. fragmented or = buffered excessively or merged with the next frame etc. It would be a relat= ively cheap change to make.

-Ian

On Tue, Apr 19, = 2011 at 3:33 PM, Greg Wilkins <gregw@intalio.com> wrote:
On 19 April 2011 23:25, Andy Green <andy@warmcat.com> wrote:
> Nothing's using this per-frame extended data at the moment.

I think because it is close to unusable. =C2=A0 One of the oft cited = uses
for it was for MUX, but interleaving of fragments is not possible with
the current design, which has forced x-google-mux to go to great
lengths to associated channel ID's with fragments.

There is effectively no extension data anyway - since with out any
length or structure any extension that used it is essentially just
mutating the payload and then there is nothing to say the extension
data is at the front, end or munged in the middle of the payload. =C2=A0I think at this stage, we need to just embrace this - and rather than
saying we have extension data area, just say extension can mutate
payloads, including pre-pending and/or appending data.

The issue then is that intermediaries cannot fragment or aggregate
frames unless they understand the extension. =C2=A0 Again =C2=A0I think we<= br> should embrace this and allow arbitrary fragment orderings so that
MUXing extensions can interleave fragments. =C2=A0The aggregating of these<= br> fragments into a message for a channel can only be done by something
that understands the MUX extension, but then we already have that
restriction, so why not allow the interleaving?


cheers

--0016364184ffedf85004a14d4c08-- From jat@google.com Tue Apr 19 16:17:58 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8E77E07E0 for ; Tue, 19 Apr 2011 16:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.276 X-Spam-Level: X-Spam-Status: No, score=-104.276 tagged_above=-999 required=5 tests=[AWL=1.700, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TlufkuDt-0I for ; Tue, 19 Apr 2011 16:17:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 2AC58E0814 for ; Tue, 19 Apr 2011 16:17:58 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p3JNHv1Y014767 for ; Tue, 19 Apr 2011 16:17:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303255078; bh=09d6fP4QkELcpnuKNnN8gvC83Kg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=MyUiSLOxhx7s2gQdpYZKm0qdKFAqrIJFr0NJXducryrrGuCLuKf1ktjx/MLbNRUV6 uS1WR+0ajmSTUmbbm4X8g== Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by kpbe14.cbf.corp.google.com with ESMTP id p3JNH26n002179 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 16:17:56 -0700 Received: by gwaa18 with SMTP id a18so78906gwa.33 for ; Tue, 19 Apr 2011 16:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aKUF16Io5Ud/AXD6SAtE6ZriLN7GGXXsHxcVbtsSk58=; b=XhxoqSA4qXA1mxwug6WCcz1Ep3W0ADFdict/0OMnuhB334rsljOysb/YAPffT537Gj YZMgGvAsOVY1A/1tTZvA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=E6LmsWckLTFAiZh9JJnYR/1fQBoAB2YuSSqmp2N8pYW/Yzx9vJHKcbnA1LyRR8g/cH bNo45voRQh4x13RKbLYQ== Received: by 10.151.87.6 with SMTP id p6mr5436725ybl.352.1303255076312; Tue, 19 Apr 2011 16:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Tue, 19 Apr 2011 16:17:36 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> From: John Tamplin Date: Tue, 19 Apr 2011 19:17:36 -0400 Message-ID: To: ifette@google.com Content-Type: multipart/alternative; boundary=000e0cd2da0ee018f904a14db7d3 X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:17:59 -0000 --000e0cd2da0ee018f904a14db7d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2011 at 6:48 PM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3= =83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > Going back to the matter at hand re: the opcodes. I'm fairly convinced I > don't want to have a generic control frame opcode and then define which > control it is in the body. That said, I think something like Greg's earli= er > proposal would help and give us a bit of flexibility. > > e.g. 0x0-0x7 =3D=3D data opcodes > 0x8-0xF =3D=3D control opcodes > > we would still have something like 4 unused opcodes in each bucket, and i= f > we wanted to, we could always define something like "this particular opco= de > means you should look at this other place for more information" and still > have intermediaries understand that this is a control frame, and shouldn'= t > be e.g. fragmented or buffered excessively or merged with the next frame > etc. It would be a relatively cheap change to make. > I don't understand how you can say it would be cheap to add later, yet infeasible now. Either we are saying the entire opcode needs to be visible to intermediaries that don't understand the negotiated extensions, in which case adding it later is just as problematic as adding it now, or we are saying we don't care if they don't understand it in which case it is no problem to add it now. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd2da0ee018f904a14db7d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 19, 2011 at 6:48 PM, Ian Fette (=E3= =82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <ifette@google.com> wrote:
Going back to the matter at hand re: the opcodes. I'm fairly convinced = I don't want to have a generic control frame opcode and then define whi= ch control it is in the body. That said, I think something like Greg's = earlier proposal would help and give us a bit of flexibility.

e.g. 0x0-0x7 =3D=3D data opcodes
0x8-0xF =3D=3D co= ntrol opcodes

we would still have something like 4= unused opcodes in each bucket, and if we wanted to, we could always define= something like "this particular opcode means you should look at this = other place for more information" and still have intermediaries unders= tand that this is a control frame, and shouldn't be e.g. fragmented or = buffered excessively or merged with the next frame etc. It would be a relat= ively cheap change to make.

I don't understand how you can say it = would be cheap to add later, yet infeasible now. =C2=A0Either we are saying= the entire opcode needs to be visible to intermediaries that don't und= erstand the negotiated extensions, in which case adding it later is just as= problematic as adding it now, or we are saying we don't care if they d= on't understand it in which case it is no problem to add it now.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd2da0ee018f904a14db7d3-- From ifette@google.com Tue Apr 19 16:25:03 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25BD7E07C0 for ; Tue, 19 Apr 2011 16:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.676 X-Spam-Level: X-Spam-Status: No, score=-107.676 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8aSEDSmxZ3E for ; Tue, 19 Apr 2011 16:25:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id CDF2CE075C for ; Tue, 19 Apr 2011 16:25:01 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p3JNP0pZ032494 for ; Tue, 19 Apr 2011 16:25:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303255500; bh=F0ARKD/aj6Q+agWxvAJGFa61rtg=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=dTheQqmjdGyLQG9DsalJJtxogNhLk7PE/25483RbHW5LbyXjKN78IR4PUXhuxY1bQ lPPOk5zpJBPu15BjR9eEg== Received: from qwk3 (qwk3.prod.google.com [10.241.195.131]) by wpaz5.hot.corp.google.com with ESMTP id p3JNOw3x024495 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 16:24:59 -0700 Received: by qwk3 with SMTP id 3so100814qwk.19 for ; Tue, 19 Apr 2011 16:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=J59oGvNQRoHdEVO6dI0nAOnZPElgTF8I75gklA8zpo8=; b=xGJaShX0nQbe0heyvinFpBzlKplYRSpo5gKjoozUzsff9hqa5pivcHc9vEBRNwzy2o FCLWUceWjnjgnBq3Mk1Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Q7qUpPky4S+Ytjkbctjr7Sr22+oP1acesl0BFPONpZ+KTZWWy3mBLtSSqzHY3xmq9J BNh4Uozw5cDsaYc8Tgkg== MIME-Version: 1.0 Received: by 10.229.44.198 with SMTP id b6mr4747372qcf.67.1303255498746; Tue, 19 Apr 2011 16:24:58 -0700 (PDT) Received: by 10.229.0.137 with HTTP; Tue, 19 Apr 2011 16:24:58 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> Date: Tue, 19 Apr 2011 16:24:58 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: John Tamplin Content-Type: multipart/alternative; boundary=0016364184ff0ded6704a14dd14c X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:25:03 -0000 --0016364184ff0ded6704a14dd14c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2011 at 4:17 PM, John Tamplin wrote: > On Tue, Apr 19, 2011 at 6:48 PM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3= =E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > >> Going back to the matter at hand re: the opcodes. I'm fairly convinced I >> don't want to have a generic control frame opcode and then define which >> control it is in the body. That said, I think something like Greg's earl= ier >> proposal would help and give us a bit of flexibility. >> >> e.g. 0x0-0x7 =3D=3D data opcodes >> 0x8-0xF =3D=3D control opcodes >> >> we would still have something like 4 unused opcodes in each bucket, and = if >> we wanted to, we could always define something like "this particular opc= ode >> means you should look at this other place for more information" and stil= l >> have intermediaries understand that this is a control frame, and shouldn= 't >> be e.g. fragmented or buffered excessively or merged with the next frame >> etc. It would be a relatively cheap change to make. >> > > I don't understand how you can say it would be cheap to add later, yet > infeasible now. Either we are saying the entire opcode needs to be visib= le > to intermediaries that don't understand the negotiated extensions, in whi= ch > case adding it later is just as problematic as adding it now, or we are > saying we don't care if they don't understand it in which case it is no > problem to add it now. > > I'm saying that I think the opcodes we have now are basic and probably are useful to be understood by intermediaries (e.g. the fact that something is = a control frame is useful to understand. The fact that something is a close frame is useful to understand). If we have additional control frames that w= e designate in the future, they will by definition not be understood by v1 intermediaries. If they are useful to understand standalone, we can allocat= e one of the remaining opcodes. If they are not useful outside some additiona= l context (e.g. an extension wants to introduce its own control frames) we could set aside a single opcode to mean "control frame with additional data at location X (payload)". Either way, by rearranging v1 intermediaries can at least understand that it's a control frame. -Ian > -- > John A. Tamplin > Software Engineer (GWT), Google > --0016364184ff0ded6704a14dd14c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 19, 2011 at 4:17 PM, John Tamplin <jat@google.com>= ; wrote:
On Tue, Apr 19, 2011 at 6:48 P= M, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83= =86=E3=82=A3) <ifette@google.com> wrote:
Going back to the matter at hand re: the opcodes. I'm fairly convinced = I don't want to have a generic control frame opcode and then define whi= ch control it is in the body. That said, I think something like Greg's = earlier proposal would help and give us a bit of flexibility.

e.g. 0x0-0x7 =3D=3D data opcodes
0x8-0xF =3D=3D co= ntrol opcodes

we would still have something like 4= unused opcodes in each bucket, and if we wanted to, we could always define= something like "this particular opcode means you should look at this = other place for more information" and still have intermediaries unders= tand that this is a control frame, and shouldn't be e.g. fragmented or = buffered excessively or merged with the next frame etc. It would be a relat= ively cheap change to make.

I don't understand how you can s= ay it would be cheap to add later, yet infeasible now. =C2=A0Either we are = saying the entire opcode needs to be visible to intermediaries that don'= ;t understand the negotiated extensions, in which case adding it later is j= ust as problematic as adding it now, or we are saying we don't care if = they don't understand it in which case it is no problem to add it now.<= /div>


I'm saying that I think the = opcodes we have now are basic and probably are useful to be understood by i= ntermediaries (e.g. the fact that something is a control frame is useful to= understand. The fact that something is a close frame is useful to understa= nd). If we have additional control frames that we designate in the future, = they will by definition not be understood by v1 intermediaries. If they are= useful to understand standalone, we can allocate one of the remaining opco= des. If they are not useful outside some additional context (e.g. an extens= ion wants to introduce its own control frames) we could set aside a single = opcode to mean "control frame with additional data at location X (payl= oad)". Either way, by rearranging v1 intermediaries can at least under= stand that it's a control frame.

-Ian
=C2=A0
--
John A. Tamplin
Software Engineer (GWT), Google

--0016364184ff0ded6704a14dd14c-- From ifette@google.com Tue Apr 19 19:09:01 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 37F0AE081D for ; Tue, 19 Apr 2011 19:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.009 X-Spam-Level: X-Spam-Status: No, score=-107.009 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz2Kq2F4eABR for ; Tue, 19 Apr 2011 19:09:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id D8D89E06F5 for ; Tue, 19 Apr 2011 19:08:59 -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 p3K28wvQ021892 for ; Tue, 19 Apr 2011 19:08:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303265339; bh=ZQyy69i6e9uH6MSi6FTn7IV1X2U=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=ya7YNwqybPM1Ghtv6/Kta11CEsSUwGIb8AiNjyexEMEsG8+i70+RSUxpEBxTiPdyR 5/qxjHIM5T8uDr8x+TCXA== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by wpaz33.hot.corp.google.com with ESMTP id p3K28fbk014999 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 19:08:57 -0700 Received: by qwj9 with SMTP id 9so230016qwj.35 for ; Tue, 19 Apr 2011 19:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p46DoSL1IfhnH1WOLGHCslnWsY83hSSmhiBlfpcd7lI=; b=oGNfLH2kmBIiSwM7fIW5jwBViQ8TxAoq0DI7vsG/SEpG8opO+DEs4FD6KSTwxHuCy3 BQxRK2P7VeCDJx2zJe7w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=UN3MFeafxYR3J2GEe0z2HO7aVYxf2uq6E0ay50PtfyWxp6gxAKihURphOL1TJxO/cK i4hjH27FLLfxj3ZvtE+Q== MIME-Version: 1.0 Received: by 10.229.118.78 with SMTP id u14mr4961470qcq.29.1303265336986; Tue, 19 Apr 2011 19:08:56 -0700 (PDT) Received: by 10.229.0.137 with HTTP; Tue, 19 Apr 2011 19:08:56 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> Date: Tue, 19 Apr 2011 19:08:56 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: John Tamplin Content-Type: multipart/alternative; boundary=000e0cd5f4aa758c2f04a1501b5c X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:09:01 -0000 --000e0cd5f4aa758c2f04a1501b5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be clear: Right now, we have a situation where intermediaries can't determine what is a control frame and what is not a control frame. We can argue about just ho= w bad this is, but it does seem suboptimal. Greg's proposal of 0x0-0x7 and 0x8-0xF cleans this up with minimal cost. The cost is that it forces an allocation of the remaining opcodes to two buckets, either DATA or CONTROL. The alternative, a single opcode, means that we get into all the nasty issues I described above. I would like to avoid that. If we do continue to allocate opcodes in future versions, we still have some headroom for judiciously allocated opcodes. Should we get close to running out, we can always decide that "Well, we actually did need more opcodes, so let's say 0xF is a control frame opcode that means more data about the control frame is in the payload." We get into the nasty issues I pointed out, but frankly if we define any new opcodes at a later point, we will already have the issues of deployed intermediaries not understanding the opcode, so the marginal cost of that decision is much lower at that point in time, and we still do have the option open to us. As such, I am planning on re-ordering the opcodes in 07 to have 0x0-0x7 be data and 0x8-0xF be control. -Ian 2011/4/19 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83= =E3=83=86=E3=82=A3) > On Tue, Apr 19, 2011 at 4:17 PM, John Tamplin wrote: > >> On Tue, Apr 19, 2011 at 6:48 PM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3= =E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: >> >>> Going back to the matter at hand re: the opcodes. I'm fairly convinced = I >>> don't want to have a generic control frame opcode and then define which >>> control it is in the body. That said, I think something like Greg's ear= lier >>> proposal would help and give us a bit of flexibility. >>> >>> e.g. 0x0-0x7 =3D=3D data opcodes >>> 0x8-0xF =3D=3D control opcodes >>> >>> we would still have something like 4 unused opcodes in each bucket, and >>> if we wanted to, we could always define something like "this particular >>> opcode means you should look at this other place for more information" = and >>> still have intermediaries understand that this is a control frame, and >>> shouldn't be e.g. fragmented or buffered excessively or merged with the= next >>> frame etc. It would be a relatively cheap change to make. >>> >> >> I don't understand how you can say it would be cheap to add later, yet >> infeasible now. Either we are saying the entire opcode needs to be visi= ble >> to intermediaries that don't understand the negotiated extensions, in wh= ich >> case adding it later is just as problematic as adding it now, or we are >> saying we don't care if they don't understand it in which case it is no >> problem to add it now. >> >> > I'm saying that I think the opcodes we have now are basic and probably ar= e > useful to be understood by intermediaries (e.g. the fact that something i= s a > control frame is useful to understand. The fact that something is a close > frame is useful to understand). If we have additional control frames that= we > designate in the future, they will by definition not be understood by v1 > intermediaries. If they are useful to understand standalone, we can alloc= ate > one of the remaining opcodes. If they are not useful outside some additio= nal > context (e.g. an extension wants to introduce its own control frames) we > could set aside a single opcode to mean "control frame with additional da= ta > at location X (payload)". Either way, by rearranging v1 intermediaries ca= n > at least understand that it's a control frame. > > -Ian > > >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> > > --000e0cd5f4aa758c2f04a1501b5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be clear:

Right now, we have a situation where interm= ediaries can't determine what is a control frame and what is not a cont= rol frame. We can argue about just how bad this is, but it does seem subopt= imal. Greg's proposal of 0x0-0x7 and 0x8-0xF cleans this up with minima= l cost. The cost is that it forces an allocation of the remaining opcodes t= o two buckets, either DATA or CONTROL. The alternative, a single opcode, me= ans that we get into all the nasty issues I described above. I would like t= o avoid that. If we do continue to allocate opcodes in future versions, we = still have some headroom for judiciously allocated opcodes. Should we get c= lose to running out, we can always decide that "Well, we actually did = need more opcodes, so let's say 0xF is a control frame opcode that mean= s more data about the control frame is in the payload." We get into th= e nasty issues I pointed out, but frankly if we define any new opcodes at a= later point, we will already have the issues of deployed intermediaries no= t understanding the opcode, so the marginal cost of that decision is much l= ower at that point in time, and we still do have the option open to us.

As such, I am planning on re-ordering the opcodes in 07= to have 0x0-0x7 be data and 0x8-0xF be control.

-= Ian

2011/4/19 Ian Fette (=E3=82=A4=E3=82= =A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <ifette@google.com>=
=
On Tue, Apr 19, 2011 at 4:17 PM, John Tamplin <jat@google= .com> wrote:
On Tue, Apr 19, 2011 at 6:48 PM, Ian Fette = (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) = <ifette@google.com> wrote:
Going back to the matter at hand re: the opcodes. I'm fairly convinced = I don't want to have a generic control frame opcode and then define whi= ch control it is in the body. That said, I think something like Greg's = earlier proposal would help and give us a bit of flexibility.

e.g. 0x0-0x7 =3D=3D data opcodes
0x8-0xF =3D=3D co= ntrol opcodes

we would still have something like 4= unused opcodes in each bucket, and if we wanted to, we could always define= something like "this particular opcode means you should look at this = other place for more information" and still have intermediaries unders= tand that this is a control frame, and shouldn't be e.g. fragmented or = buffered excessively or merged with the next frame etc. It would be a relat= ively cheap change to make.

I don't understand how you can s= ay it would be cheap to add later, yet infeasible now. =C2=A0Either we are = saying the entire opcode needs to be visible to intermediaries that don'= ;t understand the negotiated extensions, in which case adding it later is j= ust as problematic as adding it now, or we are saying we don't care if = they don't understand it in which case it is no problem to add it now.<= /div>


I'm saying that = I think the opcodes we have now are basic and probably are useful to be und= erstood by intermediaries (e.g. the fact that something is a control frame = is useful to understand. The fact that something is a close frame is useful= to understand). If we have additional control frames that we designate in = the future, they will by definition not be understood by v1 intermediaries.= If they are useful to understand standalone, we can allocate one of the re= maining opcodes. If they are not useful outside some additional context (e.= g. an extension wants to introduce its own control frames) we could set asi= de a single opcode to mean "control frame with additional data at loca= tion X (payload)". Either way, by rearranging v1 intermediaries can at= least understand that it's a control frame.

-Ian
=C2=A0
--
John A. Tamplin
Software Engineer (GWT), Google


--000e0cd5f4aa758c2f04a1501b5c-- From stpeter@stpeter.im Tue Apr 19 19:27:39 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6ABCFE0867 for ; Tue, 19 Apr 2011 19:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QrhuyymIgJk for ; Tue, 19 Apr 2011 19:27:38 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 70464E0670 for ; Tue, 19 Apr 2011 19:27:38 -0700 (PDT) Received: from squire.local (dsl-175-253.dynamic-dsl.frii.net [216.17.175.253]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BD08B40D51; Tue, 19 Apr 2011 20:31:13 -0600 (MDT) Message-ID: <4DAE4498.90602@stpeter.im> Date: Tue, 19 Apr 2011 20:27:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ifette@google.com References: <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060101010009040304080300" Cc: Hybi , Greg Wilkins Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:27:39 -0000 This is a cryptographically signed message in MIME format. --------------ms060101010009040304080300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (no hats) On 4/19/11 8:08 PM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82= =A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > To be clear: >=20 > Right now, we have a situation where intermediaries can't determine wha= t > is a control frame and what is not a control frame. We can argue about > just how bad this is, but it does seem suboptimal. Greg's proposal of > 0x0-0x7 and 0x8-0xF cleans this up with minimal cost. The cost is that > it forces an allocation of the remaining opcodes to two buckets, either= > DATA or CONTROL. The alternative, a single opcode, means that we get > into all the nasty issues I described above. I would like to avoid that= =2E > If we do continue to allocate opcodes in future versions, we still have= > some headroom for judiciously allocated opcodes. Should we get close to= > running out, we can always decide that "Well, we actually did need more= > opcodes, so let's say 0xF is a control frame opcode that means more dat= a > about the control frame is in the payload." We get into the nasty issue= s > I pointed out, but frankly if we define any new opcodes at a later > point, we will already have the issues of deployed intermediaries not > understanding the opcode, so the marginal cost of that decision is much= > lower at that point in time, and we still do have the option open to us= =2E >=20 > As such, I am planning on re-ordering the opcodes in 07 to have 0x0-0x7= > be data and 0x8-0xF be control. Based on the discussion so far, that sounds like a reasonable approach. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060101010009040304080300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQy MDAyMjczNlowIwYJKoZIhvcNAQkEMRYEFHvT3HVptxzeeA0e7Y89PhKlXdrWMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQB91gHdtpaNU69+gbg5cRPFeQnDDxeLICcayJj6Fr5X8N2OoiI6vSwKPwss zodYCx7zYmejNNxDv8oq1gLHkXk0KnVhqK8edbIKLdz55kogjMd5bg/CF8IufuhPAmLOig4K wiTOGrtkgyg2LOW+N0409vLsdylWgvY3FE6a6JDDnW78Wm9kgbfhfy21CCE2r/8co9ZnLn6L 7i0ufQnEKzJ5quZNv3JRmj4q9Sga7P7ruLQ//q0HcXywg3bF4vrnY1nIki/x3+h2HGWTfezy SAGdLErSB6Kr5tN9a252+tDBbHq+9SWnj9eh4V46+CbzUNPy5ZzZe1jhTRgdU/mcxL/QAAAA AAAA --------------ms060101010009040304080300-- From jat@google.com Tue Apr 19 19:30:24 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 64BB5E0660 for ; Tue, 19 Apr 2011 19:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.398 X-Spam-Level: X-Spam-Status: No, score=-104.398 tagged_above=-999 required=5 tests=[AWL=1.578, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz-ro3kZiY0h for ; Tue, 19 Apr 2011 19:30:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id E9595E0670 for ; Tue, 19 Apr 2011 19:30:22 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p3K2UMmc029355 for ; Tue, 19 Apr 2011 19:30:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303266622; bh=vDVy+G9k7I0cBToVG090pLMVOEg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GqwPLQ2YBPUbc16qiDvrk3HmwBoHi0N37L1aM5Cagu+xwmuTw3zOz1byWlx2ZCy1j M/JhATJkaNtbKyRxv3V0A== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by wpaz9.hot.corp.google.com with ESMTP id p3K2ULLv002113 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 19:30:21 -0700 Received: by gyf2 with SMTP id 2so116519gyf.39 for ; Tue, 19 Apr 2011 19:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mFcmNfMMVhdh40K9azoVR8/O+bJ7NWRvLT9LqXs0Xhs=; b=JUSv8AByycjbcDCnt/VlRnZo2Q+VeZwLtq3n0kTSotfj9tTjcd1CX0O7qRwR1F702Z vl8D4Tkw0RUUIrMNM39g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Oa+jtSAET+cOcuEKAencL8qa1R9ZrUMJfiaeg5kNqKJCS2zYi5Fpdllh+B7EP+EK2w LoesadUDu0dMdJwUR9gA== Received: by 10.150.69.30 with SMTP id r30mr5584344yba.124.1303266620765; Tue, 19 Apr 2011 19:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.9 with HTTP; Tue, 19 Apr 2011 19:30:00 -0700 (PDT) In-Reply-To: References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> From: John Tamplin Date: Tue, 19 Apr 2011 22:30:00 -0400 Message-ID: To: ifette@google.com Content-Type: multipart/alternative; boundary=000e0cd59196fa770704a15067df X-System-Of-Record: true Cc: Hybi , Greg Wilkins Subject: Re: [hybi] a single CONTROL opcode for all control frames (was Re: Hello frames?) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:30:24 -0000 --000e0cd59196fa770704a15067df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2011 at 10:08 PM, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3= =83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > As such, I am planning on re-ordering the opcodes in 07 to have 0x0-0x7 b= e > data and 0x8-0xF be control. > Ok. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd59196fa770704a15067df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 19, 2011 at 10:08 PM, Ian Fette (=E3= =82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <ifette@google.com> wrote:
As such, I am planning on re-ordering the opcodes in 07 to have 0x0-0x= 7 be data and 0x8-0xF be control.

Ok.= =C2=A0

--
John A. Tamplin
Software Engineer (GWT), Go= ogle
--000e0cd59196fa770704a15067df-- From andy.warmcat.com@googlemail.com Wed Apr 20 00:27:46 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80F03E0794 for ; Wed, 20 Apr 2011 00:27:46 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdVaJVGme3jY for ; Wed, 20 Apr 2011 00:27:45 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 74F76E0778 for ; Wed, 20 Apr 2011 00:27:45 -0700 (PDT) Received: by wyb29 with SMTP id 29so403508wyb.31 for ; Wed, 20 Apr 2011 00:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gKq0k5Siui6YdSwNP9Pcd2YT2+GP4EzUTTfyVgFyTkg=; b=AXo+mB99y063qhhd1vi/XjaTsz4l4cixg0uRevnmhoy5+pKN21KIwnN12epcIC08Vd FS8zdTSZWO3qN6YoKnItV3oD8sHAAEfDmL4L3S2sB2LjcA4hj9yyZW5cZ4JSA70PEESn qBNnYLDdwvIBntBOR9Q6+9Pw809hlmZN5zU0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ATjyX+T5PqM3w6yDYpJrHyTiZy4SjbUQOnfn7ozSZlO8fLqcdSZPLr2b73HbB95AVW Je1oARABNDP/nqKt+BL9AOOjEI21dCmVSorr5Mb8/1o279K16LOZngDrOJKqa1HXmylg TXdPg/gkQHSEw+wUm8l2lXONNft3CENF27ldY= Received: by 10.227.197.199 with SMTP id el7mr7390151wbb.32.1303284464518; Wed, 20 Apr 2011 00:27:44 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o23sm379180wbc.10.2011.04.20.00.27.41 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 00:27:42 -0700 (PDT) Sender: Andy Green Message-ID: <4DAE8AE8.1020100@warmcat.com> Date: Wed, 20 Apr 2011 08:27:36 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] a single CONTROL / mux fragmenting frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 07:27:46 -0000 On 04/19/2011 11:33 PM, Somebody in the thread at some point said: > On 19 April 2011 23:25, Andy Green wrote: >> Nothing's using this per-frame extended data at the moment. > > I think because it is close to unusable. One of the oft cited uses > for it was for MUX, but interleaving of fragments is not possible with > the current design, which has forced x-google-mux to go to great > lengths to associated channel ID's with fragments. > > There is effectively no extension data anyway - since with out any > length or structure any extension that used it is essentially just > mutating the payload and then there is nothing to say the extension > data is at the front, end or munged in the middle of the payload. I Right. But if nobody does use it, actually it has zero footprint in the packet since it is defined as notionally payload in length terms. So if people like to keep it, despite it's a little extra to think about to keep it able to work, it doesn't sound worth complaining against. > think at this stage, we need to just embrace this - and rather than > saying we have extension data area, just say extension can mutate > payloads, including pre-pending and/or appending data. Yeah I guess that is in fact the case, at least nobody not knowing the extension could tell if something had been appended as it has no idea where the payload started or its length even. > The issue then is that intermediaries cannot fragment or aggregate > frames unless they understand the extension. Again I think we > should embrace this and allow arbitrary fragment orderings so that > MUXing extensions can interleave fragments. The aggregating of these > fragments into a message for a channel can only be done by something > that understands the MUX extension, but then we already have that > restriction, so why not allow the interleaving? I agree when you think that frames are already broken up into a bunch of arbitrary packets, there's nothing so special about atomic frames in mux case, and if monster frame lengths are still allowed mux granularity and latency can be held to ransom by a bad client or server insisting to put 2^63 frames down it with extensions the mux doesn't understand so it can't fragment and breaks, just sitting there spamming one channel. The cost of doing that though is so far x-google-mux takes the approach that its "mux block" payload length is a function of the history of handshakes in the heirarchy of channels and sub-muxes and the length of the websocket frame that is the leaf payload at each level - there's no explicit mux block length. If mux blocks can fragment frames how the mux layer likes - which is good I think, certainly a more normal muxing action - then it requires introduction of explicit mux block length field. I don't think that's a big problem but we add, eg, a couple of bytes per mux block then. -Andy From andy.warmcat.com@googlemail.com Wed Apr 20 00:36:40 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36663E0698 for ; Wed, 20 Apr 2011 00:36:40 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mfdh5avDUwk for ; Wed, 20 Apr 2011 00:36:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9C387E0697 for ; Wed, 20 Apr 2011 00:36:38 -0700 (PDT) Received: by wwa36 with SMTP id 36so361361wwa.13 for ; Wed, 20 Apr 2011 00:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cg0OJfLcuK6usg5PR3m6GQtsUDxNLvuQ70Oj1wEXuK4=; b=C/oUMuctFCg/LwqTYlQOT6jjSNgdtKhxN5RAolfkkmZ+rZeVFiQzGr83Vfw5GMvFMh WDwb3v7w0wwltLyUy0T0LwMv9xS9AXNSEtVwLsgh3Y8/CE+CVso6Saj2v3mHc/rq5x+y fOoUWVXtMDGIeP3dvEXVZ2LDwdvtHYMojqsBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iIz2HR4MH+8jEtLGPhVtT2EEzc0w1etfBzW/H/uLxf1n/q8RYee5Mxm/9u2WLg2asN ArcoPezDrEDHtfd9TZCcpNCoWLImeAqxnoUWvju2Pxg2qFTMEAbqUETtjjFPgSTjp2Cl sannAzRN8b1AM8qDNqHEpxgv7pZSDofO7Zb3E= Received: by 10.227.91.77 with SMTP id l13mr7383791wbm.44.1303284997923; Wed, 20 Apr 2011 00:36:37 -0700 (PDT) Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id o6sm381733wbo.20.2011.04.20.00.36.36 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 00:36:36 -0700 (PDT) Sender: Andy Green Message-ID: <4DAE8D03.8030104@warmcat.com> Date: Wed, 20 Apr 2011 08:36:35 +0100 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Greg Wilkins References: <20110301060349.GC9463@1wt.eu> <4D6CEDA5.1060306@warmcat.com> <4D6E4A7F.101@ericsson.com> <4D6FCF1C.3090701@callenish.com> <4DAD8D65.4050608@warmcat.com> <4DAE8AE8.1020100@warmcat.com> In-Reply-To: <4DAE8AE8.1020100@warmcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] a single CONTROL / mux fragmenting frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 07:36:40 -0000 On 04/20/2011 08:27 AM, Somebody in the thread at some point said: > explicit mux block length. If mux blocks can fragment frames how the mux > layer likes - which is good I think, certainly a more normal muxing > action - then it requires introduction of explicit mux block length > field. I don't think that's a big problem but we add, eg, a couple of > bytes per mux block then. ... actually it's enough if the muxed peers tells a mux block MTU to each other at the handshake. Then both sides might understand they expected a frame length of 0x1234 on seeing such a websocket frame header, but understand it will come in mux block chunks each of <= MTU length without having to explicitly say each time. So it's no more expensive than trying to keep atomic frames in the mux. -Andy From gregw@intalio.com Wed Apr 20 00:36:52 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7C6CE0698 for ; Wed, 20 Apr 2011 00:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L2TDiUYr-Lo for ; Wed, 20 Apr 2011 00:36:52 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2A3D0E0697 for ; Wed, 20 Apr 2011 00:36:52 -0700 (PDT) Received: by vws12 with SMTP id 12so461246vws.31 for ; Wed, 20 Apr 2011 00:36:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.138 with SMTP id dk10mr5027491vdb.277.1303285011616; Wed, 20 Apr 2011 00:36:51 -0700 (PDT) Received: by 10.52.158.104 with HTTP; Wed, 20 Apr 2011 00:36:51 -0700 (PDT) Date: Wed, 20 Apr 2011 17:36:51 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: [hybi] Fragment and extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 07:36:52 -0000 Currently the spec says in 4.4: o An intermediary MAY change the fragmentation of a message if the message uses only opcode and reserved bit values known to the intermediary. I'm not sure if that is strong enough. Imagine an extension that sends digital signatures of the payload as extension data, so a frame might look like: DATA_OP length signature message. An intermediary will see neither an opcode nor a resource bit that it does not understand, so it is free to fragment that frame, which will break that extension. I propose that the spec should say: o An intermediary MUST NOT change the fragmentation of a message unless all extension that apply to the message are known to the intermediary. Furthermore, since an intermediary that does not know all the extensions that apply to a connection, must neither fragment nor aggregate frames, then I propose that we allow an extension to interleave the fragments of a message. o Extensions MAY interleave fragments one one message between fragments of a separate message. As such, an end point that accepts connections with such extensions must be capable of handling the interleaving when aggregating the frames of the messages. In the absence of any interleaving extension, an end point MUST NOT interleave the fragments of different messages. I believe that such a change will allow simpler MUX implementations, and the specification says that MUX is one of the two identified reasons for fragmentation, yet currently fragmentation cannot be used for MUX because you cannot interleave messages. regards From ifette@google.com Thu Apr 21 18:45:41 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1272EE0719 for ; Thu, 21 Apr 2011 18:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.376 X-Spam-Level: X-Spam-Status: No, score=-106.376 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOMLFOMOuiS3 for ; Thu, 21 Apr 2011 18:45:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 7A6C4E06E2 for ; Thu, 21 Apr 2011 18:45:28 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p3M1jRFx002339 for ; Thu, 21 Apr 2011 18:45:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303436728; bh=ztzEwHqQn2wwlblUFebxks/YkPk=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=xXkGaDWUf8jlWOrrH/XEn8+coZXF9HGhn0SDuSkwiMhiZeLFy+ZMF3SzvUehkGgdu jGUOX2TXKk4ZJzlbDJG1Q== Received: from qwc23 (qwc23.prod.google.com [10.241.193.151]) by kpbe18.cbf.corp.google.com with ESMTP id p3M1j02F016880 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 21 Apr 2011 18:45:26 -0700 Received: by qwc23 with SMTP id 23so183790qwc.17 for ; Thu, 21 Apr 2011 18:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QfwCI6QtAYW9vkzmJYaU2hU38JC9S16uSW5Uawmixoc=; b=cmzxf0cn//nMBnVyFuFn7qij9QBqJLPfwvJtJmYuHKVlgFedOn9sTWacXhW/OEIvao PsVbh3ZWkPpicyZvZQ9A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=NIpVJESqXAq+Zufqw//DCD3L4hLr7/6lF1Yh8m/R8OH/GuEo5b8RdUQHNIznYHEbma e/9ByKuYcJOIEY4YDNRA== MIME-Version: 1.0 Received: by 10.229.44.198 with SMTP id b6mr466020qcf.67.1303436725550; Thu, 21 Apr 2011 18:45:25 -0700 (PDT) Received: by 10.229.0.137 with HTTP; Thu, 21 Apr 2011 18:45:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2011 18:45:25 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Simon Pieters Content-Type: multipart/alternative; boundary=0016364184ff038cd304a17803e2 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Opera's Pre-Last Call review of websocket -06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:45:41 -0000 --0016364184ff038cd304a17803e2 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2011 at 5:42 AM, Simon Pieters wrote: > Hi, > > We have reviewed > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 > > The introduction section is non-normative but has a number of MUSTs. Please > don't have any requirements in the introduction. > I have ensured that normative requirements are now consistently upper case. There are no upper case MUSTs left in the non-normative introduction in the draf that will be 07. > > Why was Sec-WebSocket-Location removed? > It is now redundant given that there's a path specified in the get request. > > The spec does not define "WebSocket connection is established", "a > WebSocket message has been received", "a WebSocket error has been detected", > "the WebSocket closing handshake has started", which means that the API > spec's hooks don't work and you would never get any 'open', 'message' or > 'error' events. > I will have to take a look at this with Hixie, there also need to be some changes to the HTML spec that we've discussed (e.g. adding binary). I will consult with him to make sure the appropriate hooks are present. > > Should probably have some text about when pings may be sent. > Added "An endpoint MAY send a Ping message any time after the connection is established and before the connection is closed. NOTE: A ping message may serve either as a keepalive, or to verify that the remote endpoint is still responsive." > > Should better cover error handling, e.g. what should happen when the high > bit is set on the 63-bit length, what happens when the RSV bits are set, > what should happen when FIN is set but opcode is 0x00, or a control frame is > fragmented or has length greater than 125? I'd prefer detailed algorithms > that covered every possible case, so that it is easy to argue that all cases > are covered and so that it is clear when to fire relevant events and how > many, etc. Just having a list with cases that are 'errors' does not make it > clear when the error is to be detected or what should be done when multiple > error cases match. > We added a section on error codes for Close frames, that said I did want to leave a bit of flexibility for implementors to provide more specific errors. There are a few areas where I explicitly said an endpoint MAY send the following error code, I don't know if we should say MUST for each possible error? Frankly, most of them are likely to just be 1002 Protocol Error, and unrecoverable and useless to a developer beyond the fact a protocol error occurred. > > > 2. Conformance requirements >> All diagrams, examples, and notes in this specification are non- >> normative, as are all sections explicitly marked non-normative. >> Everything else in this specification is normative. >> The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", >> "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this >> document are to be interpreted as described in RFC2119. For >> readability, these words do not appear in all uppercase letters in >> this specification. [RFC2119] >> > > It seems this specification uses a mix of lowercase and all uppercase. > Fixed. > > Requirements phrased in the imperative as part of algorithms (such as >> "strip any leading space characters" or "return false and abort these >> steps") are to be interpreted with the meaning of the key word >> ("must", "should", "may", etc) used in introducing the algorithm. >> Conformance requirements phrased as algorithms or specific steps may >> be implemented in any manner, so long as the end result is >> equivalent. (In particular, the algorithms defined in this >> specification are intended to be easy to follow, and not intended to >> be performant.) >> Implementations may impose implementation-specific limits on >> otherwise unconstrained inputs, e.g. to prevent denial of service >> attacks, to guard against running out of memory, or to work around >> platform-specific limitations. >> The conformance classes defined by this specification are user agents >> and servers. >> 2.1. Terminology >> *ASCII* shall mean the character-encoding scheme defined in >> [ANSI.X3-4.1986]. >> *Converting a string to ASCII lowercase* means replacing all >> characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER >> A to LATIN CAPITAL LETTER Z) with the corresponding characters in the >> range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL >> LETTER Z). >> Comparing two strings in an *ASCII case-insensitive* manner means >> comparing them exactly, code point for code point, except that the >> characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER >> A to LATIN CAPITAL LETTER Z) and the corresponding characters in the >> range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL >> LETTER Z) are considered to also match. >> The term "URI" is used in this section in a manner consistent with >> the terminology used in HTML, namely, to denote a string that might >> or might not be a valid URI or IRI and to which certain error >> handling behaviors will be applied when the string is parsed. >> [RFC3986] >> > > HTML calls it "URL", so doesn't seem particularly consistent. > I have been chastised to use IRI and URI consistently. > > When an implementation is required to _send_ data as part of the >> WebSocket protocol, the implementation may delay the actual >> transmission arbitrarily, e.g. buffering data so as to send fewer IP >> packets. >> 3. WebSocket URIs >> 3.1. Parsing WebSocket URIs >> The steps to *parse a WebSocket URI's components* from a string /uri/ >> are as follows. These steps return either a /host/, a /port/, a >> /resource name/, and a /secure/ flag, or they fail. >> 1. If the /uri/ string is not an absolute URI, then fail this >> algorithm. [RFC3986] [RFC3987] >> 2. Resolve the /uri/ string using the resolve a Web address >> algorithm defined by the Web addresses specification, with the >> URI character encoding set to UTF-8. [RFC3629] [RFC3986] >> [RFC3987] >> NOTE: It doesn't matter what it is resolved relative to, since >> we already know it is an absolute URI at this point. >> 3. If /uri/ does not have a component whose value, when >> converted to ASCII lowercase, is either "ws" or "wss", then fail >> this algorithm. >> 4. If /uri/ has a component, then fail this algorithm. >> 5. If the component of /uri/ is "ws", set /secure/ to >> false; otherwise, if the component is "wss", set >> /secure/ to true; otherwise, fail this algorithm. >> > > We already know it's either "ws" or "wss", so this can't fail. > True, but it doesn't seem to hurt... > > 6. Let /host/ be the value of the component of /uri/, >> converted to ASCII lowercase. >> 7. If /uri/ has a component, then let /port/ be that >> component's value; otherwise, there is no explicit /port/. >> 8. If there is no explicit /port/, then: if /secure/ is false, let >> /port/ be 80, otherwise let /port/ be 443. >> 9. Let /resource name/ be the value of the component (which >> might be empty) of /uri/. >> 10. If /resource name/ is the empty string, set it to a single >> character U+002F SOLIDUS (/). >> 11. If /uri/ has a component, then append a single U+003F >> QUESTION MARK character (?) to /resource name/, followed by the >> value of the component. >> 12. Return /host/, /port/, /resource name/, and /secure/. >> 3.2. Constructing WebSocket URIs >> The steps to *construct a WebSocket URI* from a /host/, a /port/, a >> /resource name/, and a /secure/ flag, are as follows: >> 1. Let /uri/ be the empty string. >> 2. If the /secure/ flag is false, then append the string "ws://" to >> /uri/. Otherwise, append the string "wss://" to /uri/. >> 3. Append /host/ to /uri/. >> 4. If the /secure/ flag is false and port is not 80, or if the >> /secure/ flag is true and port is not 443, then append the string >> ":" followed by /port/ to /uri/. >> 5. Append /resource name/ to /uri/. >> 6. Return /uri/. >> 3.3. Valid WebSocket URIs >> For a WebSocket URI to be considered valid, the following conditions >> MUST hold. >> o The /host/ must be ASCII-only (i.e. it must have been punycode- >> encoded already if necessary, and MUST NOT contain any characters >> above U+007E). >> o The /resource name/ string must be a non-empty string of >> characters in the range U+0021 to U+007E that starts with a U+002F >> SOLIDUS character (/). >> Any WebSocket URIs not meeting the above criteria are considered >> invalid, and a client MUST NOT attempt to make a connection to an >> invalid WebSocket URI. A client SHOULD attempt to parse a URI >> obtained from any external source (such as a web site or a user) >> using the steps specified in Section 3.1 to obtain a valid WebSocket >> URI, but MUST NOT attempt to connect with such an unparsed URI, and >> instead only use the parsed version and only if that version is >> considered valid by the criteria above. >> 4. Data Framing >> 4.1. Overview >> In the WebSocket protocol, data is transmitted using a sequence of >> frames. Frames sent from the client to the server are masked to >> avoid confusing network intermediaries, such as intercepting proxies. >> Frames sent from the server to the client are not masked. >> The base framing protocol defines a frame type with an opcode, a >> payload length, and designated locations for extension and >> application data, which together define the _payload_ data. Certain >> bits and opcodes are reserved for future expansion of the protocol. >> As such, In the absence of extensions negotiated during the opening >> handshake (Section 5), all reserved bits MUST be 0 and reserved >> opcode values MUST NOT be used. >> A data frame MAY be transmitted by either the client or the server at >> any time after handshake completion and before that endpoint has sent >> a close message (Section 4.5.1). >> 4.2. Client-to-Server Masking >> The client MUST mask all frames sent to the server. >> The masking-key is contained completely within the frame. >> The masking-key is a 32-bit value chosen at random by the client. >> The masking-key MUST be derived from a strong source of entropy, and >> the masking-key for a given frame MUST NOT make it simple for a >> server to predict the masking-key for a subsequent frame. >> Each masked frame consists of a 32-bit masking-key followed by >> masked-data: >> masked-frame = masking-key masked-data >> masking-key = 4full-octet >> masked-data = *full-octet >> full-octet = %x00-FF >> The masked-data is the clear-text frame "encrypted" using a simple >> XOR cipher as follows. >> Octet i of the masked-data is the XOR of octet i of the clear text >> frame with octet i modulo 4 of the masking-key: >> j = i MOD 4 >> masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key >> When preparing a masked-frame, the client MUST pick a fresh masking- >> key uniformly at random from the set of allowed 32-bit values. The >> unpredictability of the masking-nonce is essential to prevent the >> author of malicious application data from selecting the bytes that >> appear on the wire. >> 4.3. Base Framing Protocol >> This wire format for the data transfer part is described by the ABNF >> given in detail in this section. A high level overview of the >> framing is given in the following figure. [RFC5234] >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-------+-+-------------+-------------------------------+ >> |F|R|R|R| opcode|R| Payload len | Extended payload length | >> |I|S|S|S| (4) |S| (7) | (16/63) | >> |N|V|V|V| |V| | (if payload len==126/127) | >> | |1|2|3| |4| | | >> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + >> | Extended payload length continued, if payload len == 127 | >> + - - - - - - - - - - - - - - - +-------------------------------+ >> | | Extension data | >> +-------------------------------+ - - - - - - - - - - - - - - - + >> : : >> +---------------------------------------------------------------+ >> : Application data : >> +---------------------------------------------------------------+ >> FIN: 1 bit >> Indicates that this is the final fragment in a message. The first >> fragment may also be the final fragment. >> RSV1, RSV2, RSV3, RSV4: 1 bit each >> Must be 0 unless an extension is negotiated which defines meanings >> for non-zero values >> Opcode: 4 bits >> Defines the interpretation of the payload data >> Payload length: 7 bits >> The length of the payload: if 0-125, that is the payload length. >> If 126, the following 2 bytes interpreted as a 16 bit unsigned >> integer are the payload length. If 127, the following 8 bytes >> interpreted as a 64-bit unsigned integer (the high bit must be 0) >> are the payload length. Multibyte length quantities are expressed >> in network byte order. The payload length is the length of the >> Extension data + the length of the Application Data. The length >> of the Extension data may be zero, in which case the Payload >> length is the length of the Application data. >> Extension data: n bytes >> The extension data is 0 bytes unless there is a reserved op-code >> or reserved bit present in the frame which indicates an extension >> has been negotiated. Any extension MUST specify the length of the >> extension data, or how that length may be calculated, and its use >> MUST be negotiated during the handshake. If present, the >> extension data is included in the total payload length. >> Application data: n bytes >> Arbitrary application data, taking up the remainder of the frame >> after any extension data. The length of the Application data is >> equal to the payload length minus the length of the Extension >> data. >> The base framing protocol is formally defined by the following ABNF >> [RFC5234]: >> ws-frame = frame-fin >> frame-rsv1 >> frame-rsv2 >> frame-rsv3 >> frame-opcode >> frame-rsv4 >> frame-length >> frame-extension >> application-data; >> frame-fin = %x0 ; more frames of this message follow >> / %x1 ; final frame of message >> frame-rsv1 = %x0 ; 1 bit, must be 0 >> frame-rsv2 = %x0 ; 1 bit, must be 0 >> frame-rsv3 = %x0 ; 1 bit, must be 0 >> frame-opcode = %x0 ; continuation frame >> / %x1 ; connection close >> / %x2 ; ping >> / %x3 ; pong >> / %x4 ; text frame >> / %x5 ; binary frame >> / %x6-F ; reserved >> frame-rsv4 = %x0 ; 1 bit, must be 0 >> frame-length = %x00-7D >> / %x7E frame-length-16 >> / %x7F frame-length-63 >> frame-length-16 = %x0000-FFFF >> frame-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF >> frame-extension = *( %x00-FF ) ; to be defined later >> application-data = *( %x00-FF ) >> 4.4. Fragmentation >> The primary purpose of fragmentation is to allow sending a message >> that is of unknown size when the message is started without having to >> buffer that message. If messages couldn't be fragmented, then an >> endpoint would have to buffer the entire message so its length could >> be counted before first byte is sent. With fragmentation, a server >> or intermediary may choose a reasonable size buffer, and when the >> buffer is full write a fragment to the network. >> A secondary use-case for fragmentation is for multiplexing, where it >> is not desirable for a large message on one logical channel to >> monopolize the output channel, so the MUX needs to be free to split >> the message into smaller fragments to better share the output >> channel. >> The following rules apply to fragmentation: >> o An unfragmented message consists of a single frame with the FIN >> bit set and an opcode other than 0. >> o A fragmented message consists of a single frame with the FIN bit >> clear and an opcode other than 0, followed by zero or more frames >> with the FIN bit clear and the opcode set to 0, and terminated by >> a single frame with the FIN bit set and an opcode of 0. Its >> content is the concatenation of the application data from each of >> those frames in order. As an example, for a text message sent as >> three fragments, the first fragment would have an opcode of 0x4 >> and a FIN bit clear, the second fragment would have an opcode of >> 0x0 and a FIN bit clear, and the third fragment would have an >> opcode of 0x0 and a FIN bit that is set. >> o Control frames MAY be injected in the middle of a fragmented >> message. Control frames themselves MUST NOT be fragmented. _Note: >> if control frames could not be interjected, the latency of a ping, >> for example, would be very long if behind a large message. As >> such, an endpoint MUST be capable of handling control frames in >> the middle of a fragmented message._ >> > > Please don't have MUSTs inside notes, since the conformance section > says notes are non-normative. > fixed > > o A sender MAY create fragments of any size for non control >> messages. >> o Clients and servers MUST support receiving both fragmented and >> unfragmented messages. >> o An intermediary MAY change the fragmentation of a message if the >> message uses only opcode and reserved bit values known to the >> intermediary. >> o As a consequence of these rules, all fragments of a message are of >> the same type, as set by the first fragment's opcode. Since >> Control frames cannot be fragmented, the type for all fragments in >> a message MUST be either text or binary, or one of the reserved >> opcodes. >> 4.5. Control Frames >> Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03 >> (Pong). Control frames are used to communicate state about the >> websocket. Control frames can be interjected in the middle of a >> fragmented message. >> All control frames MUST be 125 bytes or less in length and MUST NOT >> be fragmented. >> 4.5.1. Close >> The Close message contains an opcode of 0x01. >> The Close message MAY contain a body (the "application data" portion >> of the frame) that indicates a reason for closing, such as an >> endpoint shutting down, an endpoint having received a message too >> large, or an endpoint having received a message that does not conform >> to the format expected by the other endpoint. If there is a body, >> the first two bytes of the body MUST be a 2-byte integer (in network >> byte order) representing a status code defined in Section 7.4. >> Following the 2-byte integer the body MAY contain UTF-8 encoded data, >> the interpretation of which is not defined by this specification. >> The application MUST NOT send any more data messages after sending a >> close message. >> > > What are 'data messages'? I see data frames, but not data messages. Are > control frames allowed to be sent after close? > Changed to be data frames. Control frames I believe should still be allowed. Let's say you send a close frame and don't get a response, perhaps you try again? Though I don't feel especially strongly here. > > If an endpoint receives a Close message and that endpoint did not >> previously send a Close message, the endpoint MUST send a Close >> message in response. It SHOULD do so as soon as is practical. >> After both sending and receiving a close message, an endpoint >> considers the websocket connection closed, and SHOULD close the >> underlying TCP connection. >> If a client and server both send a Close message at the same time, >> both endpoints will have sent and received a Close message and should >> consider the websocket connection closed and close the underlying TCP >> connection. >> 4.5.2. Ping >> The Ping message contains an opcode of 0x02. >> Upon receipt of a Ping message, an endpoint MUST send a Pong message >> in response. It SHOULD do so as soon as is practical. The message >> bodies of the Ping and Pong MUST be the same. >> 4.5.3. Pong >> The Pong message contains an opcode of 0x03. >> Upon receipt of a Ping message, an endpoint MUST send a Pong message >> in response. It SHOULD do so as soon as is practical. The message >> bodies of the Ping and Pong MUST be the same. A Pong is issued only >> in response to the most recent Ping. >> > > This text is identical to the text in the previous section, except for > the last sentence. I suggest stating the requirements only once, and > making the last sentence normative by including a MUST. > In the latest draft there are some differences. fixed re: the last sentence. > > 4.6. Data Frames >> All frame types not listed in Section 4.5 are data frames, which >> transport application-layer data. The opcode determines the >> interpretation of the application data: >> Text >> The payload data is text data encoded as UTF-8. >> Binary >> The payload data is arbitrary binary data whose interpretation is >> solely up to the application layer. >> 4.7. Examples >> _This section is non-normative._ >> o A single-frame text message >> * 0x84 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello") >> o A fragmented text message >> * 0x04 0x03 0x48 0x65 0x6c (contains "Hel") >> * 0x80 0x02 0x6c 0x6f (contains "lo") >> o Ping request and response >> * 0x82 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", >> but the contents of the body are arbitrary) >> * 0x83 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", >> matching the body of the ping) >> o 256 bytes binary message in a single frame >> * 0x85 0x7E 0x0100 [256 bytes of binary data] >> o 64KiB binary message in a single frame >> * 0x85 0x7F 0x0000000000010000 [65536 bytes of binary data] >> 4.8. Extensibility >> The protocol is designed to allow for extensions, which will add >> capabilities to the base protocols. The endpoints of a connection >> MUST negotiate the use of any extensions during the handshake. This >> specification provides opcodes 0x6 through 0xF, the extension data >> field, and the frame-rsv1, frame-rsv2, frame-rsv3, and frame-rsv4 >> bits of the frame header for use by extensions. The negotiation of >> extensions is discussed in further detail in Section 8.1. Below are >> some anticipated uses of extensions. This list is neither complete >> nor proscriptive. >> o Extension data may be placed in the payload before the application >> data. >> o Reserved bits can be allocated for per-frame needs. >> o Reserved opcode values can be defined. >> o Reserved bits can be allocated to the opcode field if more opcode >> values are needed. >> o A reserved bit or an "extension" opcode can be defined which >> allocates additional bits out of the payload area to define larger >> opcodes or more per-frame bits. >> 5. Opening Handshake >> 5.1. Client Requirements >> User agents running in controlled environments, e.g. browsers on >> mobile handsets tied to specific carriers, may offload the management >> of the connection to another agent on the network. In such a >> situation, the user agent for the purposes of conformance is >> considered to include both the handset software and any such agents. >> When the user agent is to *establish a WebSocket connection* to a >> WebSocket URI /uri/, it must meet the following requirements. In the >> following text, we will use terms from Section 3 such as "/host/" and >> "/secure/ flag" as defined in that section. >> > > Section 11 says that specifications are to feed this algorithm with > /host/, /port/, /resource name/, /secure/, /origin/ and /subprotocol/. > Not /uri/. The WebSocket API invokes this algorithm in accordance with > section 11. Please make this text closer to what it is in -00. > I have tried to address this by essentially saying the algorithm can be invoked with a URI when then the algorithms in section 3 are invoked to break down that URI, or the algorithm can be invoked by passing in the parameters specified in section 11. I think it results in the same net effect and is somewhat cleaner. > > Actually the WebSocket API also has a /defer cookies/ flag. It seems > this has not been incorporated into the spec, or has been dropped at > some point. Please take in the defer cookies stuff from > http://www.whatwg.org/specs/web-socket-protocol/ (the opening paragraph > in section 5, step 46 and 47 in the algorithm, and the *apply the > cookies* definition. > There are a few hooks that are not consistent, /defer cookies/ was one of them. I need to sit down with Hixie as part of review and iron these out. I don't think reviving /defer cookies/ would be sufficient. > > 1. The WebSocket URI and its components MUST be valid according to >> Section 3.3. If any of the requirements are not met, the client >> MUST fail the WebSocket connection and abort these steps. >> > > Checking this is the responsibility of the API spec, by invoking "parse > a WebSocket URI's components" defined in this specification. If it > fails to parse, this algorithm is not invoked to begin with. > The API spec is not necessarily the only thing that could use the protocol. I don't see harm in leaving this in. > > 2. If the user agent already has a WebSocket connection to the >> remote host (IP address) identified by /host/, even if known by >> another name, the user agent MUST wait until that connection has >> been established or for that connection to have failed. There >> MUST be no more than one connection in a CONNECTING state. If >> > > Regardless of host? So we serialize tabs as well? > I'm not sure I understand what you mean by serializing tabs? The intent was that if a.com resolves to 1.2.3.4 and b.com also resolves to 1.2.3.4, a connection to b.com should wait while a connection to a.com is establishing. > > multiple connections to the same IP address are attempted >> simultaneously, the user agent MUST serialize them so that there >> is no more than one connection at a time running through the >> following steps. >> If the user agent cannot determine the IP address of the remote >> host (for example because all communication is being done through >> a proxy server that performs DNS queries itself), then the user >> agent MUST assume for the purposes of this step that each host >> name refers to a distinct remote host, but should instead limit >> the total number of simultaneous connections that are not >> established to a reasonably low number (e.g., in a Web browser, >> to the number of tabs the user has open). >> NOTE: This makes it harder for a script to perform a denial of >> service attack by just opening a large number of WebSocket >> connections to a remote host. A server can further reduce the >> load on itself when attacked by making use of this by pausing >> before closing the connection, as that will reduce the rate at >> which the client reconnects. >> NOTE: There is no limit to the number of established WebSocket >> connections a user agent can have with a single remote host. >> > > No upper limit? > correct > > Servers can refuse to connect users with an excessive number of >> connections, or disconnect resource-hogging users when suffering >> high load. >> 3. _Proxy Usage_: If the user agent is configured to use a proxy >> when using the WebSocket protocol to connect to host /host/ >> and/or port /port/, then the user agent SHOULD connect to that >> proxy and ask it to open a TCP connection to the host given by >> /host/ and the port given by /port/. >> EXAMPLE: For example, if the user agent uses an HTTP proxy for >> all traffic, then if it was to try to connect to port 80 on >> server example.com, it might send the following lines to the >> proxy server: >> CONNECT example.com:80 HTTP/1.1 >> Host: example.com >> If there was a password, the connection might look like: >> CONNECT example.com:80 HTTP/1.1 >> Host: example.com >> Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= >> If the user agent is not configured to use a proxy, then a direct >> TCP connection SHOULD be opened to the host given by /host/ and >> the port given by /port/. >> NOTE: Implementations that do not expose explicit UI for >> selecting a proxy for WebSocket connections separate from other >> proxies are encouraged to use a SOCKS proxy for WebSocket >> connections, if available, or failing that, to prefer the proxy >> configured for HTTPS connections over the proxy configured for >> HTTP connections. >> For the purpose of proxy autoconfiguration scripts, the URI to >> pass the function must be constructed from /host/, /port/, >> /resource name/, and the /secure/ flag using the steps to >> construct a WebSocket URI. >> NOTE: The WebSocket protocol can be identified in proxy >> autoconfiguration scripts from the scheme ("ws:" for unencrypted >> connections and "wss:" for encrypted connections). >> 4. If the connection could not be opened, either because a direct >> connection failed or because any proxy used returned an error, >> then the user agent MUST fail the WebSocket connection and abort >> the connection attempt. >> 5. If /secure/ is true, the user agent MUST perform a TLS handshake >> over the connection. If this fails (e.g. the server's >> certificate could not be verified), then the user agent MUST fail >> > > What about popping open a dialogue if the cert is self signed? > I think that's up to the UA. The protocol doesn't specify how the certificate is verified. If verifying it involves displaying a prompt to the user, that is IMO at the discretion of the UA.. > > the WebSocket connection and abort the connection. Otherwise, >> all further communication on this channel MUST run through the >> encrypted tunnel. [RFC2246] >> User agents MUST use the Server Name Indication extension in the >> TLS handshake. [RFC4366] >> Once a connection to the server has been established (including a >> connection via a proxy or over a TLS-encrypted tunnel), the client >> MUST send a handshake to the server. The handshake consists of an >> HTTP upgrade request, along with a list of required and optional >> headers. The requirements for this handshake are as follows. >> 1. The handshake must be a valid HTTP request as specified by >> [RFC2616]. >> 2. The Method of the request MUST be GET and the HTTP version MUST >> be at least 1.1. >> For example, if the WebSocket URI is "ws://example.com/chat", >> The first line sent SHOULD be "GET /chat HTTP/1.1" >> > > Please don't use SHOULD in an example, since examples are non-normative. > made lower case > > 3. The request must contain a "Request-URI" as part of the GET >> method. This MUST match the /resource name/ Section 3. >> 4. The request MUST contain a "Host" header whose value is equal to >> the authority component of the WebSocket URI. >> > > Make it equal to /host/ since parsing a WebSocket URI's components will > convert it to lowercase. > done > > 5. The request MUST contain an "Upgrade" header whose value is >> equal to "websocket". >> 6. The request MUST contain a "Connection" header whose value MUST >> include the "Upgrade" token. >> 7. The request MUST include a header with the name "Sec-WebSocket- >> Key". The value of this header MUST be a nonce consisting of a >> randomly selected 16-byte value that has been base64-encoded >> [RFC3548]. The nonce MUST be randomly selected randomly for >> each connection. >> > > Double randomly. > fixed ;-) > > NOTE: As an example, if the randomly selected value was the >> sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 >> 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header >> would be "AQIDBAUGBwgJCgsMDQ4PEC==" >> 8. The request MUST include a header with the name "Sec-WebSocket- >> Origin" if the request is coming from a browser client. If the >> > > Maybe the conformance section should have different conformance classes > for browesr clients and non-browser clients. > I'm not going to touch this one late in the game. How strongly do you feel? > > connection is from a non-browser client, the request MAY include >> this header if the semantics of that client match the use-case >> described here for browser clients. The value of this header >> MUST be the ASCII serialization of origin of the context in >> which the code establishing the connection is running, and MUST >> be lower-case. The value MUST NOT contain letters in the range >> U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL >> LETTER Z) [I-D.ietf-websec-origin]. >> As an example, if code is running on www.example.com attempting >> to establish a connection to ww2.example.com, the value of the >> header would be "http://www.example.com". >> 9. The request MUST include a header with the name "Sec-WebSocket- >> Version". The value of this header must be 6. >> 10. The request MAY include a header with the name "Sec-WebSocket- >> Protocol". If present, this value indicates the subprotocol(s) >> the client wishes to speak. The elements that comprise this >> value MUST be non-empty strings with characters in the range >> U+0021 to U+007E and MUST all be unique. The ABNF for the value >> > > and MUST all be unique strings. (just to make sure you don't think the > characters must be unique) > done > > of this header is 1#(token | quoted-string), where the >> definitions of constructs and rules are as given in [RFC2616]. >> > > I'd like this to say that, at least for browser clients, if the > algorithm was invoked with a non-empty list of /subprotocols/ then the > header MUST be included, with the values of /subprotocols/ joined by a > comma and a space, and otherwise MUST NOT be included. Otherwise a > browser would be conforming for requesting subprotocols at random. > It seems like that should be in the API requirement, not the protocol requirement? > > 11. The request MAY include a header with the name "Sec-WebSocket- >> Extensions". If present, this value indicates the protocol- >> level extension(s) the client wishes to speak. The >> interpretation and format of this header is described in >> Section 8.1. >> 12. The request MAY include headers associated with sending cookies, >> as defined by the appropriate specifications >> [I-D.ietf-httpstate-cookie]. >> > > Any cookies at random? I'd like, at least for browser clients, for this > to be tighter, as it was in -00. > again, i need to sync with hixie on the cross-spec hooks. > > Once the client's opening handshake has been sent, the client MUST >> wait for a response from the server before sending any further data. >> The client MUST validate the server's response as follows: >> o If the status code received from the server is not 101, the client >> MUST fail the WebSocket connection. >> o If the response lacks an Upgrade header or the Upgrade header >> contains a value that is not an ASCII case-insensitive match for >> the value "websocket", the client MUST fail the WebSocket >> connection. >> o If the response lacks a Connection header or the Connection header >> contains a value that is not an ASCII case-insensitive match for >> the value "Upgrade", the client MUST fail the WebSocket >> connection. >> o If the response lacks a Sec-WebSocket-Accept header or the Sec- >> WebSocket-Accept contains a value other than the base64-encoded >> SHA-1 of the concatenation of the Sec-WebSocket-Key (as a string, >> not base64-decoded) with the string "258EAFA5-E914-47DA-95CA- >> C5AB0DC85B11", the client MUST fail the WebSocket connection. >> > > -00 had rules for failing the websocket connection if the response had > certain other errors, like the wrong type of linebreaks. What's the > deal now? I haven't reviewed the security implications, but there may > be some if clients are tolerant in their parsing of the server's > handshake. > The group had a big push towards "it's HTTP and is HTTP compatibile" so this all got re-written... if it's valid HTTP then it's OK, if it's not then not -- that was my interpretation... > > Where the algorithm above requires that a user agent fail the >> WebSocket connection, the user agent may first read an arbitrary >> number of further bytes from the connection (and then discard them) >> before actually *failing the WebSocket connection*. Similarly, if a >> user agent can show that the bytes read from the connection so far >> are such that there is no subsequent sequence of bytes that the >> server can send that would not result in the user agent being >> required to *fail the WebSocket connection*, the user agent may >> immediately *fail the WebSocket connection* without waiting for those >> bytes. >> NOTE: The previous paragraph is intended to make it conforming for >> user agents to implement the algorithm in subtly different ways that >> are equivalent in all ways except that they terminate the connection >> at earlier or later points. For example, it enables an >> implementation to buffer the entire handshake response before >> checking it, or to verify each field as it is received rather than >> collecting all the fields and then checking them as a block. >> > > It seems these two paragraphs aren't needed anymore when you don't have > a detailed algorithm but just some bullet points. > > 5.2. Server-side requirements >> _This section only applies to servers._ >> Servers may offload the management of the connection to other agents >> on the network, for example load balancers and reverse proxies. In >> such a situation, the server for the purposes of conformance is >> considered to include all parts of the server-side infrastructure >> from the first device to terminate the TCP connection all the way to >> the server that processes requests and sends responses. >> EXAMPLE: For example, a data center might have a server that responds >> to WebSocket requests with an appropriate handshake, and then passes >> the connection to another server to actually process the data frames. >> For the purposes of this specification, the "server" is the >> combination of both computers. >> 5.2.1. Reading the client's opening handshake >> When a client starts a WebSocket connection, it sends its part of the >> opening handshake. The server must parse at least part of this >> handshake in order to obtain the necessary information to generate >> the server part of the handshake. >> The client handshake consists of the following parts. If the server, >> while reading the handshake, finds that the client did not send a >> handshake that matches the description below, the server must abort >> the WebSocket connection. >> 1. An HTTP/1.1 or higher GET request, including a "Request-URI" >> [RFC2616] that should be interpreted as a /resource name/ >> Section 3. >> 2. A "Host" header containing the server's authority. >> 3. A "Sec-WebSocket-Key" header with a base64-encoded value that, >> when decoded, is 16 bytes in length. >> 4. A "Sec-WebSocket-Version" header, with a value of 6. >> 5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent >> by all browser clients. A connection attempt lacking this header >> SHOULD NOT be interpreted as coming from a browser client. >> 6. Optionally, a "Sec-WebSocket-Protocol header, with a list of >> values indicating which protocols the client would like to speak, >> ordered by preference. >> > > Missing quote. > > -00 was stricter about the Sec-WebSocket-Protocol header: if the algorithm > was fed with an empty /subprotocols/ then the header must not be included, > else the header must be included with the values of /subprotocols/. I prefer > that over anything-goes "optinally". > > 7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of >> values indicating which extensions the client would like to >> speak. The interpretation of this header is discussed in >> Section 8.1. >> 8. Optionally, other headers, such as those used to send cookies to >> a server. Unknown headers MUST be ignored. >> 5.2.2. Sending the server's opening handshake >> When a client establishes a WebSocket connection to a server, the >> server must complete the following steps to accept the connection and >> send the server's opening handshake. >> 1. If the server supports encryption, perform a TLS handshake over >> the connection. If this fails (e.g. the client indicated a host >> > > If the server supports encryption? A bit unclear... if can support > encryption but the requested URL might be ws: > will chat with hixie on cross-protocol things, frankly I hold firm that tls with http:// is rather useless and i really don't worry about it for ws... > > name in the extended client hello "server_name" extension that >> the server does not host), then close the connection; otherwise, >> all further communication for the connection (including the >> server handshake) must run through the encrypted tunnel. >> [RFC2246] >> 2. Establish the following information: >> /origin/ >> The |Sec-WebSocket-Origin| header in the client's handshake >> indicates the origin of the script establishing the >> connection. The origin is serialized to ASCII and converted >> to lowercase. The server MAY use this information as part of >> a determination of whether to accept the incoming connection. >> > > I'd like a warning here that if the server doesn't validate the origin, > it means that it will accept connections from anywhere. Normally it's > the browser's responsibility to enforce same-origin restrictions, but > with websockets it's the server application developer's responsibility, > and this needs to be pointed out explicitly IMHO. > > I see now that there's a paragraph discussing this in security > considerations. I'd be happy with a pointer to security considerations > here. > done > > /key/ >> The |Sec-WebSocket-Key| header in the client's handshake >> includes a base64-encoded value that, if decoded, is 16 bytes >> in length. This (encoded) value is used in the creation of >> the server's handshake to indicate an acceptance of the >> connection. It is not necessary for the server to base64- >> decode the Sec-WebSocket-Key value. >> /version/ >> The |Sec-WebSocket-Version| header in the client's handshake >> includes the version of the WebSocket protocol the client is >> attempting to communicate with. If this version does not >> match a version understood by the server, the server MUST >> abort the WebSocket connection. The server MAY send a non-200 >> response code with a |Sec-WebSocket-Version| header indicating >> the version(s) the server is capable of understanding along >> with this non-200 response code. >> /resource name/ >> An identifier for the service provided by the server. If the >> server provides multiple services, then the value should be >> derived from the resource name given in the client's handshake >> from the Request-URI [RFC2616] of the GET method. >> /subprotocol/ >> A (possibly empty) list representing the subprotocol the >> server is ready to use. If the server supports multiple >> subprotocols, then the value should be derived from the >> client's handshake, specifically by selecting one of the >> values from the "Sec-WebSocket-Protocol" field. The absence >> of such a field is equivalent to the null value. The empty >> string is not the same as the null value for these purposes. >> /extensions/ >> A (possibly empty) list representing the protocol-level >> extensions the server is ready to use. If the server supports >> multiple extensions, then the value should be derived from the >> client's handshake, specifically by selecting one or more of >> the values from the "Sec-WebSocket-Extensions" field. The >> absence of such a field is equivalent to the null value. The >> empty string is not the same as the null value for these >> purposes. Extensions not listed by the client MUST NOT be >> listed. The method by which these values should be selected >> and interpreted is discussed in Section 8.1. >> 3. If the server chooses to accept the incoming connection, it must >> reply with a valid HTTP response indicating the following. >> 1. A 101 response code. Such a response could look like >> "HTTP/1.1 101 Switching Protocols" >> 2. A "Sec-WebSocket-Accept" header. The value of this header is >> constructed by concatenating /key/, defined above in >> Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914- >> 47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this >> concatenated value to obtain a 20-byte value, and base64- >> encoding this 20-byte hash. >> NOTE: As an example, if the value of the "Sec-WebSocket-Key" >> header in the client's handshake were >> "dGhlIHNhbXBsZSBub25jZQ==", the server would append the >> string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the >> string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- >> C5AB0DC85B11". The server would then take the SHA-1 hash of >> this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 >> 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe >> 0xc4 0xea. This value is then base64-encoded, to give the >> value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned >> in the "Sec-WebSocket-Accept" header. >> 3. Optionally, a "Sec-WebSocket-Protocol" header, with a value >> /subprotocol/ as defined in Paragraph 2 of Section 5.2.2. >> 4. Optionally, a "Sec-WebSocket-Extensions" header, with a value >> /extensions/ as defined in Paragraph 2 of Section 5.2.2. >> This completes the server's handshake. If the server finishes these >> steps without aborting the WebSocket connection, and if the client >> does not then fail the WebSocket connection, then the connection is >> established and the server may begin sending and receiving data, as >> described in the next section. >> > > The next section doesn't describe sending and receiving data. > done > > 6. Error Handling >> 6.1. Handling errors in UTF-8 from the server >> When a client is to interpret a byte stream as UTF-8 but finds that >> the byte stream is not in fact a valid UTF-8 stream, then any bytes >> or sequences of bytes that are not valid UTF-8 sequences must be >> interpreted as a U+FFFD REPLACEMENT CHARACTER. >> > > Maybe use the HTML spec's definition of UTF-8 with error handling: > > http://www.whatwg.org/specs/web-apps/current-work/complete/infrastructure.html#decoded-as-utf-8,-with-error-handling > > 6.2. Handling errors in UTF-8 from the client >> When a server is to interpret a byte stream as UTF-8 but finds that >> the byte stream is not in fact a valid UTF-8 stream, behavior is >> undefined. A server could close the connection, convert invalid byte >> sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim, >> or perform application-specific processing. Subprotocols layered on >> the WebSocket protocol might define specific behavior for servers. >> 7. Closing the connection >> 7.1. Definitions >> 7.1.1. Close the WebSocket Connection >> To _Close the WebSocket Connection_, an endpoint closes the >> underlying TCP connection. An endpoint SHOULD use a method that >> cleanly closes the TCP connection, discarding any trailing bytes that >> may be received. And endpoint MAY close the connection via any means >> > > s/And/An/ > done > > available when necessary, such as when under attack. >> As an example of how to obtain a clean closure in C using Berkeley >> sockets, one would call shutdown() with SHUT_WR on the socket, call >> recv() until obtaining a return value of 0 indicating that the peer >> has also performed an orderly shutdown, and finally calling close() >> on the socket. >> > > Hmm, this example seems a bit out of place. > > 7.1.2. Start the WebSocket Closing Handshake >> To _start the WebSocket closing handshake_, and endpoint MUST send a >> > > s/and/an/ > done > > Close control frame, as described in Section 4.5.1. Upon receiving a >> Close control frame, the other party sends a Close control frame in >> response. Once an endpoint has both sent and received a Close >> control frame, that endpoint should _Close the WebSocket Connection_ >> as defined in Section 7.1.1. >> > > Again this repeats the same requirements from 4.5.1, but subtly > different, such that it's not clear which to follow. Please only have > the same requirement once. > I removed what I think is duplicative and what remains is about the minimal set. > > 7.1.3. The WebSocket Connection Is Closed >> When the underlying TCP connection is closed, it is said that _the >> WebSocket connection is closed_. If the tcp connection was closed >> after the WebSocket closing handshake was completed, the WebSocket >> connection is said to have been closed _cleanly_. >> 7.1.4. Fail the WebSocket Connection >> Certain algorithms and specifications require a user agent to _fail >> the WebSocket connection_. To do so, the user agent must _Close the >> WebSocket Connection_, and MAY report the problem to the user (which >> would be especially useful for developers) in an appropriate manner. >> Except as indicated above or as specified by the application layer >> (e.g. a script using the WebSocket API), user agents SHOULD NOT close >> the connection. >> 7.2. Abnormal closures >> 7.2.1. Client-initiated closure >> Certain algorithms, namely during the initial handshake, require the >> user agent to *fail the WebSocket connection*. To do so, the user >> agent must _Close the WebSocket connection_ as previously defined, >> and may report the problem to the user via an appropriate mechanism >> (which would be especially useful for developers). >> Except as indicated above or as specified by the application layer >> (e.g. a script using the WebSocket API), user agents should not close >> the connection. >> 7.2.2. Server-initiated closure >> Certain algorithms require or recommend that the server _abort the >> WebSocket connection_ during the opening handshake. To do so, the >> server must simply _close the WebSocket connection_ (Section 7.1.1). >> 7.3. Normal closure of connections >> Servers MAY close the WebSocket connection whenever desired. User >> agents SHOULD NOT close the WebSocket connection arbitrarily. In >> either case, an endpoint initiates a closure by following the >> procedures to _start the WebSocket closing handshake_ >> (Section 7.1.2). >> 7.4. Status codes >> When closing an established connection (e.g. when sending a Close >> frame, after the handshake has completed), an endpoint MAY indicate a >> reason for closure. The interpretation of this reason by an >> endpoint, and the action an endpoint should take given this reason, >> are left undefined by this specification. This specification defines >> a set of pre-defined status codes, and specifies which ranges may be >> used by extensions, frameworks, and end applications. The status >> code and any associated textual message are optional components of a >> Close frame. >> 7.4.1. Defined Status Codes >> Endpoints MAY use the following pre-defined status codes when sending >> a Close frame. >> 1000 >> 1000 indicates a normal closure, meaning whatever purpose the >> connection was established for has been fulfilled. >> 1001 >> 1001 indicates that an endpoint is "going away", such as a server >> going down, or a browser having navigated away from a page. >> 1002 >> 1002 indicates that an endpoint is terminating the connection due >> to a protocol error. >> 1003 >> 1003 indicates that an endpoint is terminating the connection >> because it has received a type of data it cannot accept (e.g. an >> endpoint that understands only text data may send this if it >> receives a binary message.) >> 1004 >> 1004 indicates that an endpoint is terminating the connection >> because it has received a message that is too large. >> 7.4.2. Reserved status code ranges >> 0-999 >> Status codes in the range 0-999 are not used. >> 1000-1999 >> Status codes in the range 1000-1999 are reserved for definition by >> this protocol. >> 2000-2999 >> Status codes in the range 2000-2999 are reserved for use by >> extensions. >> 3000-3999 >> Status codes in the range 3000-3999 MAY be used by libraries and >> frameworks. The interpretation of these codes is undefined by >> this protocol. End applications MUST NOT use status codes in this >> range. >> 4000-4999 >> Status codes in the range 4000-4999 MAY be used by application >> code. The interpretaion of these codes is undefined by this >> protocol. >> 8. Extensions >> WebSocket clients MAY request extensions to this specification, and >> WebSocket servers MAY accept some or all extensions requested by the >> client. A server MUST NOT respond with any extension not requested >> by the client. If extension parameters are included in negotiations >> between the client and the server, those parameters MUST be chosen in >> accordance with the specification of the extension to which the >> parameters apply. >> 8.1. Negotiating extensions >> A client requests extensions by including a "Sec-WebSocket- >> Extensions" header, which follows the normal rules for HTTP headers >> (see [RFC2616] section 4.2) and the value of the header is defined by >> the following ABNF: >> extension-list = 1#extension >> extension = extension-token *( ";" extension-param ) >> extension-token = registered-token | private-use-token >> registered-token = token >> private-use-token = "x-" token >> extension-param = token [ "=" ( token | quoted-string ) ] >> Note that like other HTTP headers, this header may be split or >> combined across multiple lines. Ergo, the following are equivalent: >> Sec-WebSocket-Extensions: foo >> Sec-WebSocket-Extensions: bar; baz=2 >> is exactly equivalent to >> Sec-WebSocket-Extensions: foo, bar; baz=2 >> Any extension-token used must either be a registered token >> (registration TBD), or have a prefix of "x-" to indicate a private- >> use token. The parameters supplied with any given extension MUST be >> defined for that extension. Note that the client is only offering to >> use any advertised extensions, and MUST NOT use them unless the >> server accepts the extension. >> Note that the order of extensions is significant. Any interactions >> between multiple extensions MAY be defined in the documents defining >> the extensions. In the absence of such definition, the >> interpretation is that the headers listed by the client in its >> request represent a preference of the headers it wishes to use, with >> the first options listed being most preferable. The extensions >> listed by the server in response represent the extensions actually in >> use. Should the extensions modify the data and/or framing, the order >> of operations on the data should be assumed to be the same as the >> order in which the extensions are listed in the server's response in >> the opening handshake. >> For example, if there are two extensions "foo" and "bar", if the >> header |Sec-WebSocket-Extensions| sent by the server has the value >> "foo, bar" then operations on the data will be made as >> bar(foo(data)), be those changes to the data itself (such as >> compression) or changes to the framing thay may "stack". >> Non-normative examples of acceptable extension headers: >> Sec-WebSocket-Extensions: deflate-stream >> Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, >> deflate-stream >> Sec-WebSocket-Extensions: x-private-extension >> A server accepts one or more extensions by including a |Sec- >> WebSocket-Extensions| header containing one or more extensions which >> were requested by the client. The interpretation of any extension >> parameters, and what constitutes a valid response by a server to a >> requested set of parameters by a client, will be defined by each such >> extension. >> 8.2. Known extensions >> Extensions provide a mechanism for implementations to opt-in to >> additional protocol features. This section defines the meaning of >> well-known extensions but implementations may use extensions defined >> separately as well. >> 8.2.1. Compression >> The registered extension token for this compression extension is >> "deflate-stream". >> The extension does not have any per message extension data and it >> does not define the use of any WebSocket reserved bits or op codes. >> Senders using this extension MUST apply RFC 1951 encodings to all >> bytes of the data stream following the handshake including both data >> and control messages. The data stream MAY include multiple blocks of >> both compressed and uncompressed types as defined by RFC 1951. >> [RFC1951] >> Senders MUST NOT delay the transmission of any portion of a WebSocket >> message because the deflate encoding of the message does not end on a >> byte boundary. The encodings for adjacent messages MAY appear in the >> same byte if no delay in transmission is occurred by doing so. >> 9. Security considerations >> While this protocol is intended to be used by scripts in Web pages, >> it can also be used directly by hosts. Such hosts are acting on >> their own behalf, and can therefore send fake "Origin" fields, >> misleading the server. Servers should therefore be careful about >> assuming that they are talking directly to scripts from known >> origins, and must consider that they might be accessed in unexpected >> ways. In particular, a server should not trust that any input is >> valid. >> EXAMPLE: For example, if the server uses input as part of SQL >> queries, all input text should be escaped before being passed to the >> SQL server, lest the server be susceptible to SQL injection. >> Servers that are not intended to process input from any Web page but >> only for certain sites should verify the "Origin" field is an origin >> they expect, and should only respond with the corresponding "Sec- >> WebSocket-Origin" if it is an accepted origin. Servers that only >> accept input from one origin can just send back that value in the >> "Sec-WebSocket-Origin" field, without bothering to check the client's >> value. >> >> If at any time a server is faced with data that it does not >> understand, or that violates some criteria by which the server >> determines safety of input, or when the server sees a handshake that >> does not correspond to the values the server is expecting (e.g. >> incorrect path or origin), the server should just disconnect. It is >> always safe to disconnect. >> The biggest security risk when sending text data using this protocol >> is sending data using the wrong encoding. If an attacker can trick >> the server into sending data encoded as ISO-8859-1 verbatim (for >> instance), rather than encoded as UTF-8, then the attacker could >> inject arbitrary frames into the data stream. >> In addition to endpoints being the target of attacks via WebSockets, >> other parts of web infrastructure, such as proxies, may be the >> subject of an attack. In particular, an intermediary may interpret a >> WebSocket message from a client as a request, and a message from the >> server as a response to that request. For instance, an attacker >> could get a browser to establish a connection to its server, get the >> browser to send a message that looks to an intermediary like a GET >> request for a common piece of JavaScript on another domain, and send >> back a message that is interpreted as a cacheable response to that >> request, thus poisioning the cache for other users. To prevent this >> attack, messages sent from clients are masked on the wire with a 32- >> bit value, to prevent an attacker from controlling the bits on the >> wire and thus lessen the probability of an attacker being able to >> construct a message that can be misinterpreted by a proxy as a non- >> WebSocket request. >> 10. IANA considerations >> 10.1. Registration of ws: scheme >> A |ws:| URI identifies a WebSocket server and resource name. >> URI scheme name. >> ws >> Status. >> Permanent. >> URI scheme syntax. >> In ABNF terms using the terminals from the URI specifications: >> [RFC5234] [RFC3986] >> "ws" ":" hier-part [ "?" query ] >> The path and query components form the resource name sent to the >> server to identify the kind of service desired. Other components >> have the meanings described in RFC3986. >> URI scheme semantics. >> The only operation for this scheme is to open a connection using >> the WebSocket protocol. >> Encoding considerations. >> Characters in the host component that are excluded by the syntax >> defined above must be converted from Unicode to ASCII by applying >> the IDNA ToASCII algorithm to the Unicode host name, with both the >> AllowUnassigned and UseSTD3ASCIIRules flags set, and using the >> result of this algorithm as the host in the URI. [RFC3490] >> Characters in other components that are excluded by the syntax >> defined above must be converted from Unicode to ASCII by first >> encoding the characters as UTF-8 and then replacing the >> corresponding bytes using their percent-encoded form as defined in >> the URI and IRI specification. [RFC3986] [RFC3987] >> Applications/protocols that use this URI scheme name. >> WebSocket protocol. >> Interoperability considerations. >> None. >> Security considerations. >> See "Security considerations" section above. >> Contact. >> Ian Hickson >> Author/Change controller. >> Ian Hickson >> References. >> This document. >> 10.2. Registration of wss: scheme >> A |wss:| URI identifies a WebSocket server and resource name, and >> indicates that traffic over that connection is to be encrypted. >> URI scheme name. >> wss >> Status. >> Permanent. >> URI scheme syntax. >> In ABNF terms using the terminals from the URI specifications: >> [RFC5234] [RFC3986] >> "wss" ":" hier-part [ "?" query ] >> The path and query components form the resource name sent to the >> server to identify the kind of service desired. Other components >> have the meanings described in RFC3986. >> URI scheme semantics. >> The only operation for this scheme is to open a connection using >> the WebSocket protocol, encrypted using TLS. >> Encoding considerations. >> Characters in the host component that are excluded by the syntax >> defined above must be converted from Unicode to ASCII by applying >> the IDNA ToASCII algorithm to the Unicode host name, with both the >> AllowUnassigned and UseSTD3ASCIIRules flags set, and using the >> result of this algorithm as the host in the URI. [RFC3490] >> Characters in other components that are excluded by the syntax >> defined above must be converted from Unicode to ASCII by first >> encoding the characters as UTF-8 and then replacing the >> corresponding bytes using their percent-encoded form as defined in >> the URI and IRI specification. [RFC3986] [RFC3987] >> Applications/protocols that use this URI scheme name. >> WebSocket protocol over TLS. >> Interoperability considerations. >> None. >> Security considerations. >> See "Security considerations" section above. >> Contact. >> Ian Hickson >> Author/Change controller. >> Ian Hickson >> References. >> This document. >> 10.3. Registration of the "WebSocket" HTTP Upgrade keyword >> Name of token. >> WebSocket >> Author/Change controller. >> Ian Hickson >> Contact. >> Ian Hickson >> References. >> This document. >> 10.4. Sec-WebSocket-Key >> This section describes a header field for registration in the >> Permanent Message Header Field Registry. [RFC3864] >> Header field name >> Sec-WebSocket-Key >> Applicable protocol >> http >> Status >> reserved; do not use outside WebSocket handshake >> Author/Change controller >> IETF >> Specification document(s) >> This document is the relevant specification. >> Related information >> None. >> The |Sec-WebSocket-Key| header is used in the WebSocket handshake. >> It is sent from the client to the server to provide part of the >> information used by the server to prove that it received a valid >> WebSocket handshake. This helps ensure that the server does not >> accept connections from non-WebSocket clients (e.g. HTTP clients) >> that are being abused to send data to unsuspecting WebSocket servers. >> 10.5. Sec-WebSocket-Extensions >> This section describes a header field for registration in the >> Permanent Message Header Field Registry. [RFC3864] >> Header field name >> Sec-WebSocket-Extensions >> Applicable protocol >> http >> Status >> reserved; do not use outside WebSocket handshake >> Author/Change controller >> IETF >> Specification document(s) >> This document is the relevant specification. >> Related information >> None. >> The |Sec-WebSocket-Extensions| header is used in the WebSocket >> handshake. It is initially sent from the client to the server, and >> then subsequently sent from the servver to the client, to agree on a >> set of protocol-level extensions to use during the connection. >> 10.6. Sec-WebSocket-Accept >> This section describes a header field for registration in the >> Permanent Message Header Field Registry. [RFC3864] >> Header field name >> Sec-WebSocket-Accept >> Applicable protocol >> http >> Status >> reserved; do not use outside WebSocket handshake >> Author/Change controller >> IETF >> Specification document(s) >> This document is the relevant specification. >> Related information >> None. >> The |Sec-WebSocket-Accept| header is used in the WebSocket handshake. >> It is sent from the server to the client to confirm that the server >> is willing to initiate the connection. >> 10.7. Sec-WebSocket-Origin >> This section describes a header field for registration in the >> Permanent Message Header Field Registry. [RFC3864] >> Header field name >> Sec-WebSocket-Origin >> Applicable protocol >> http >> Status >> reserved; do not use outside WebSocket handshake >> Author/Change controller >> IETF >> Specification document(s) >> This document is the relevant specification. >> Related information >> None. >> The |Sec-WebSocket-Origin| header is used in the WebSocket handshake. >> It is sent from the server to the client to confirm the origin of the >> script that opened the connection. This enables user agents to >> verify that the server is willing to serve the script that opened the >> connection. >> 10.8. Sec-WebSocket-Protocol >> This section describes a header field for registration in the >> Permanent Message Header Field Registry. [RFC3864] >> Header field name >> Sec-WebSocket-Protocol >> Applicable protocol >> http >> Status >> reserved; do not use outside WebSocket handshake >> Author/Change controller >> IETF >> Specification document(s) >> This document is the relevant specification. >> Related information >> None. >> The |Sec-WebSocket-Protocol| header is used in the WebSocket >> handshake. It is sent from the client to the server and back from >> the server to the client to confirm the subprotocol of the >> connection. This enables scripts to both select a subprotocol and be >> sure that the server agreed to serve that subprotocol. >> 10.9. Sec-WebSocket-Version >> This section describes a header field for registration in the >> Permanent Message Header Field Registry. [RFC3864] >> Header field name >> Sec-WebSocket-Version >> Applicable protocol >> http >> Status >> reserved; do not use outside WebSocket handshake >> Author/Change controller >> IETF >> Specification document(s) >> This document is the relevant specification. >> Related information >> None. >> The |Sec-WebSocket-Version| header is used in the WebSocket >> handshake. It is sent from the client to the server to indicate the >> protocol version of the connection. This enables servers to >> correctly interpret the handshake and subsequent data being sent from >> the data, and close the connection if the server cannot interpret >> that data in a safe manner. >> 11. Using the WebSocket protocol from other specifications >> The WebSocket protocol is intended to be used by another >> specification to provide a generic mechanism for dynamic author- >> defined content, e.g. in a specification defining a scripted API. >> Such a specification first needs to "establish a WebSocket >> connection", providing that algorithm with: >> o The destination, consisting of a /host/ and a /port/. >> o A /resource name/, which allows for multiple services to be >> identified at one host and port. >> o A /secure/ flag, which is true if the connection is to be >> encrypted, and false otherwise. >> o An ASCII serialization of an origin that is being made responsible >> for the connection. [I-D.ietf-websec-origin] >> o Optionally a string identifying a protocol that is to be layered >> over the WebSocket connection. >> The /host/, /port/, /resource name/, and /secure/ flag are usually >> obtained from a URI using the steps to parse a WebSocket URI's >> components. These steps fail if the URI does not specify a >> WebSocket. >> If a connection can be established, then it is said that the >> "WebSocket connection is established". >> If at any time the connection is to be closed, then the specification >> needs to use the "close the WebSocket connection" algorithm. >> When the connection is closed, for any reason including failure to >> establish the connection in the first place, it is said that the >> "WebSocket connection is closed". >> While a connection is open, the specification will need to handle the >> cases when "a WebSocket message has been received" with text /data/. >> To send some text /data/ to an open connection, the specification >> needs to "send /data/ using the WebSocket". >> > > -- > Simon Pieters > Opera Software > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016364184ff038cd304a17803e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2011 at 5:42 AM, Simon Pieters <simonp@opera.com> wrote:
Hi,

We have reviewed http://tools.ietf.org/html/draft-iet= f-hybi-thewebsocketprotocol-06

The introduction section is non-normative but has a number of MUSTs. Please= don't have any requirements in the introduction.
=
I have ensured that normative requirements are now consisten= tly upper case. There are no upper case MUSTs left in the non-normative int= roduction in the draf that will be 07.
=C2=A0

Why was Sec-WebSocket-Location removed?


It is now redundant given that there's a path specified= in the get request.
=C2=A0

The spec does not define "WebSocket connection is established", &= quot;a WebSocket message has been received", "a WebSocket error h= as been detected", "the WebSocket closing handshake has started&q= uot;, which means that the API spec's hooks don't work and you woul= d never get any 'open', 'message' or 'error' events= .

I will have to take a look at this with Hi= xie, there also need to be some changes to the HTML spec that we've dis= cussed (e.g. adding binary). I will consult with him to make sure the appro= priate hooks are present.
=C2=A0

Should probably have some text about when pings may be sent.


Added "An endpoint MAY send a Pin= g message any time after the connection
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 is established and before the connection is closed. NOTE: A ping= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message may serve either as a keepa= live, or to verify that the=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 remote endpoint is still responsive."
=C2=A0

Should better cover error handling, e.g. what should happen when the high b= it is set on the 63-bit length, what happens when the RSV bits are set, wha= t should happen when FIN is set but opcode is 0x00, or a control frame is f= ragmented or has length greater than 125? I'd prefer detailed algorithm= s that covered every possible case, so that it is easy to argue that all ca= ses are covered and so that it is clear when to fire relevant events and ho= w many, etc. Just having a list with cases that are 'errors' does n= ot make it clear when the error is to be detected or what should be done wh= en multiple error cases match.

We added a section on error codes for Clos= e frames, that said I did want to leave a bit of flexibility for implemento= rs to provide more specific errors. There are a few areas where I explicitl= y said an endpoint MAY send the following error code, I don't know if w= e should say MUST for each possible error? Frankly, most of them are likely= to just be 1002 Protocol Error, and unrecoverable and useless to a develop= er beyond the fact a protocol error occurred.=C2=A0

=C2=A0


2. =C2=A0Conformance requirements
=C2=A0All diagrams, examples, and notes in this specification are non-
=C2=A0 normative, as are all sections explicitly marked non-normative.
=C2=A0 Everything else in this specification is normative.
=C2=A0The key words "MUST", "MUST NOT", "REQUIRED= ", "SHOULD", "SHOULD NOT",
=C2=A0 "RECOMMENDED", "MAY", and "OPTIONAL" = in the normative parts of this
=C2=A0 document are to be interpreted as described in RFC2119. =C2=A0For =C2=A0 readability, these words do not appear in all uppercase letters in<= br> =C2=A0 this specification. =C2=A0[RFC2119]

It seems this specification uses a mix of lowercase and all uppercase.
<= /blockquote>

Fixed.

=C2=A0

=C2=A0 Requirements phrased in the imperative as part of algorithms (such = as
=C2=A0 "strip any leading space characters" or "return fals= e and abort these
=C2=A0 steps") are to be interpreted with the meaning of the key word=
=C2=A0 ("must", "should", "may", etc) used i= n introducing the algorithm.
=C2=A0Conformance requirements phrased as algorithms or specific steps may=
=C2=A0 be implemented in any manner, so long as the end result is
=C2=A0 equivalent. =C2=A0(In particular, the algorithms defined in this =C2=A0 specification are intended to be easy to follow, and not intended t= o
=C2=A0 be performant.)
=C2=A0Implementations may impose implementation-specific limits on
=C2=A0 otherwise unconstrained inputs, e.g. to prevent denial of service =C2=A0 attacks, to guard against running out of memory, or to work around<= br> =C2=A0 platform-specific limitations.
=C2=A0The conformance classes defined by this specification are user agent= s
=C2=A0 and servers.
2.1. =C2=A0Terminology
=C2=A0*ASCII* shall mean the character-encoding scheme defined in
=C2=A0 [ANSI.X3-4.1986].
=C2=A0*Converting a string to ASCII lowercase* means replacing all
=C2=A0 characters in the range U+0041 to U+005A (i.e. =C2=A0LATIN CAPITAL = LETTER
=C2=A0 A to LATIN CAPITAL LETTER Z) with the corresponding characters in t= he
=C2=A0 range U+0061 to U+007A (i.e. =C2=A0LATIN SMALL LETTER A to LATIN SM= ALL
=C2=A0 LETTER Z).
=C2=A0Comparing two strings in an *ASCII case-insensitive* manner means =C2=A0 comparing them exactly, code point for code point, except that the<= br> =C2=A0 characters in the range U+0041 to U+005A (i.e. =C2=A0LATIN CAPITAL = LETTER
=C2=A0 A to LATIN CAPITAL LETTER Z) and the corresponding characters in th= e
=C2=A0 range U+0061 to U+007A (i.e. =C2=A0LATIN SMALL LETTER A to LATIN SM= ALL
=C2=A0 LETTER Z) are considered to also match.
=C2=A0The term "URI" is used in this section in a manner consist= ent with
=C2=A0 the terminology used in HTML, namely, to denote a string that might=
=C2=A0 or might not be a valid URI or IRI and to which certain error
=C2=A0 handling behaviors will be applied when the string is parsed.
=C2=A0 [RFC3986]

HTML calls it "URL", so doesn't seem particularly consistent.=

I have been chastised to use IRI and U= RI consistently.

=C2=A0

=C2=A0 When an implementation is required to _send_ data as part of the =C2=A0 WebSocket protocol, the implementation may delay the actual
=C2=A0 transmission arbitrarily, e.g. buffering data so as to send fewer I= P
=C2=A0 packets.
3. =C2=A0WebSocket URIs
3.1. =C2=A0Parsing WebSocket URIs
=C2=A0The steps to *parse a WebSocket URI's components* from a string = /uri/
=C2=A0 are as follows. =C2=A0These steps return either a /host/, a /port/,= a
=C2=A0 /resource name/, and a /secure/ flag, or they fail.
=C2=A01. =C2=A0 If the /uri/ string is not an absolute URI, then fail this=
=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm. =C2=A0[RFC3986] [RFC3987]
=C2=A02. =C2=A0 Resolve the /uri/ string using the resolve a Web address =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm defined by the Web addresses specific= ation, with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0URI character encoding set to UTF-8. =C2=A0[RFC= 3629] [RFC3986]
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC3987]
=C2=A0 =C2=A0 =C2=A0 NOTE: It doesn't matter what it is resolved relat= ive to, since
=C2=A0 =C2=A0 =C2=A0 =C2=A0we already know it is an absolute URI at this p= oint.
=C2=A03. =C2=A0 If /uri/ does not have a <scheme> component whose va= lue, when
=C2=A0 =C2=A0 =C2=A0 =C2=A0converted to ASCII lowercase, is either "w= s" or "wss", then fail
=C2=A0 =C2=A0 =C2=A0 =C2=A0this algorithm.
=C2=A04. =C2=A0 If /uri/ has a <fragment> component, then fail this = algorithm.
=C2=A05. =C2=A0 If the <scheme> component of /uri/ is "ws"= , set /secure/ to
=C2=A0 =C2=A0 =C2=A0 =C2=A0false; otherwise, if the <scheme> compone= nt is "wss", set
=C2=A0 =C2=A0 =C2=A0 =C2=A0/secure/ to true; otherwise, fail this algorith= m.

We already know it's either "ws" or "wss", so this = can't fail.


True, bu= t it doesn't seem to hurt...
=C2=A0

=C2=A0 6. =C2=A0 Let /host/ be the value of the <host> component of = /uri/,
=C2=A0 =C2=A0 =C2=A0 =C2=A0converted to ASCII lowercase.
=C2=A07. =C2=A0 If /uri/ has a <port> component, then let /port/ be = that
=C2=A0 =C2=A0 =C2=A0 =C2=A0component's value; otherwise, there is no e= xplicit /port/.
=C2=A08. =C2=A0 If there is no explicit /port/, then: if /secure/ is false= , let
=C2=A0 =C2=A0 =C2=A0 =C2=A0/port/ be 80, otherwise let /port/ be 443.
=C2=A09. =C2=A0 Let /resource name/ be the value of the <path> compo= nent (which
=C2=A0 =C2=A0 =C2=A0 =C2=A0might be empty) of /uri/.
=C2=A010. =C2=A0If /resource name/ is the empty string, set it to a single=
=C2=A0 =C2=A0 =C2=A0 =C2=A0character U+002F SOLIDUS (/).
=C2=A011. =C2=A0If /uri/ has a <query> component, then append a sing= le U+003F
=C2=A0 =C2=A0 =C2=A0 =C2=A0QUESTION MARK character (?) to /resource name/,= followed by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0value of the <query> component.
=C2=A012. =C2=A0Return /host/, /port/, /resource name/, and /secure/.
3.2. =C2=A0Constructing WebSocket URIs
=C2=A0The steps to *construct a WebSocket URI* from a /host/, a /port/, a<= br> =C2=A0 /resource name/, and a /secure/ flag, are as follows:
=C2=A01. =C2=A0Let /uri/ be the empty string.
=C2=A02. =C2=A0If the /secure/ flag is false, then append the string "= ;ws://" to
=C2=A0 =C2=A0 =C2=A0 /uri/. =C2=A0Otherwise, append the string "wss:/= /" to /uri/.
=C2=A03. =C2=A0Append /host/ to /uri/.
=C2=A04. =C2=A0If the /secure/ flag is false and port is not 80, or if the=
=C2=A0 =C2=A0 =C2=A0 /secure/ flag is true and port is not 443, then appen= d the string
=C2=A0 =C2=A0 =C2=A0 ":" followed by /port/ to /uri/.
=C2=A05. =C2=A0Append /resource name/ to /uri/.
=C2=A06. =C2=A0Return /uri/.
3.3. =C2=A0Valid WebSocket URIs
=C2=A0For a WebSocket URI to be considered valid, the following conditions=
=C2=A0 MUST hold.
=C2=A0o =C2=A0The /host/ must be ASCII-only (i.e. it must have been punyco= de-
=C2=A0 =C2=A0 =C2=A0encoded already if necessary, and MUST NOT contain any= characters
=C2=A0 =C2=A0 =C2=A0above U+007E).
=C2=A0o =C2=A0The /resource name/ string must be a non-empty string of
=C2=A0 =C2=A0 =C2=A0characters in the range U+0021 to U+007E that starts w= ith a U+002F
=C2=A0 =C2=A0 =C2=A0SOLIDUS character (/).
=C2=A0Any WebSocket URIs not meeting the above criteria are considered
=C2=A0 invalid, and a client MUST NOT attempt to make a connection to an =C2=A0 invalid WebSocket URI. =C2=A0A client SHOULD attempt to parse a URI=
=C2=A0 obtained from any external source (such as a web site or a user) =C2=A0 using the steps specified in Section 3.1 to obtain a valid WebSocke= t
=C2=A0 URI, but MUST NOT attempt to connect with such an unparsed URI, and=
=C2=A0 instead only use the parsed version and only if that version is
=C2=A0 considered valid by the criteria above.
4. =C2=A0Data Framing
4.1. =C2=A0Overview
=C2=A0In the WebSocket protocol, data is transmitted using a sequence of =C2=A0 frames. =C2=A0Frames sent from the client to the server are masked = to
=C2=A0 avoid confusing network intermediaries, such as intercepting proxie= s.
=C2=A0 Frames sent from the server to the client are not masked.
=C2=A0The base framing protocol defines a frame type with an opcode, a
=C2=A0 payload length, and designated locations for extension and
=C2=A0 application data, which together define the _payload_ data. =C2=A0C= ertain
=C2=A0 bits and opcodes are reserved for future expansion of the protocol.=
=C2=A0 As such, In the absence of extensions negotiated during the opening=
=C2=A0 handshake (Section 5), all reserved bits MUST be 0 and reserved
=C2=A0 opcode values MUST NOT be used.
=C2=A0A data frame MAY be transmitted by either the client or the server a= t
=C2=A0 any time after handshake completion and before that endpoint has se= nt
=C2=A0 a close message (Section 4.5.1).
4.2. =C2=A0Client-to-Server Masking
=C2=A0The client MUST mask all frames sent to the server.
=C2=A0The masking-key is contained completely within the frame.
=C2=A0The masking-key is a 32-bit value chosen at random by the client. =C2=A0 The masking-key MUST be derived from a strong source of entropy, an= d
=C2=A0 the masking-key for a given frame MUST NOT make it simple for a
=C2=A0 server to predict the masking-key for a subsequent frame.
=C2=A0Each masked frame consists of a 32-bit masking-key followed by
=C2=A0 masked-data:
=C2=A0 =C2=A0masked-frame =C2=A0=3D masking-key masked-data
=C2=A0 =C2=A0 masking-key =C2=A0 =3D 4full-octet
=C2=A0 =C2=A0 masked-data =C2=A0 =3D *full-octet
=C2=A0 =C2=A0 full-octet =C2=A0 =C2=A0=3D %x00-FF
=C2=A0The masked-data is the clear-text frame "encrypted" using = a simple
=C2=A0 XOR cipher as follows.
=C2=A0Octet i of the masked-data is the XOR of octet i of the clear text =C2=A0 frame with octet i modulo 4 of the masking-key:
=C2=A0 =C2=A0j =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D i MOD 4=
=C2=A0 =C2=A0 masked-octet-i =3D clear-text-octet-i XOR octet-j-of-masking= -key
=C2=A0When preparing a masked-frame, the client MUST pick a fresh masking-=
=C2=A0 key uniformly at random from the set of allowed 32-bit values. =C2= =A0The
=C2=A0 unpredictability of the masking-nonce is essential to prevent the =C2=A0 author of malicious application data from selecting the bytes that<= br> =C2=A0 appear on the wire.
4.3. =C2=A0Base Framing Protocol
=C2=A0This wire format for the data transfer part is described by the ABNF=
=C2=A0 given in detail in this section. =C2=A0A high level overview of the=
=C2=A0 framing is given in the following figure. =C2=A0[RFC5234]
=C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 +-+-+-+-+-------+-+-------------+---------------------------= ----+
=C2=A0 =C2=A0 |F|R|R|R| opcode|R| Payload len | =C2=A0 =C2=A0Extended payl= oad length =C2=A0 =C2=A0|
=C2=A0 =C2=A0 |I|S|S|S| =C2=A0(4) =C2=A0|S| =C2=A0 =C2=A0 (7) =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (16/63) =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 |N|V|V|V| =C2=A0 =C2=A0 =C2=A0 |V| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 (if payload len=3D=3D126/127) =C2=A0 |
=C2=A0 =C2=A0 | |1|2|3| =C2=A0 =C2=A0 =C2=A0 |4| =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= =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 Extended payload length continued, if payloa= d len =3D=3D 127 =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Extension data =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 =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 =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 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Application data =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 +-----------------------------------------------------------= ----+
=C2=A0FIN: =C2=A01 bit
=C2=A0 =C2=A0 Indicates that this is the final fragment in a message. =C2= =A0The first
=C2=A0 =C2=A0 =C2=A0fragment may also be the final fragment.
=C2=A0RSV1, RSV2, RSV3, RSV4: =C2=A01 bit each
=C2=A0 =C2=A0 Must be 0 unless an extension is negotiated which defines me= anings
=C2=A0 =C2=A0 =C2=A0for non-zero values
=C2=A0Opcode: =C2=A04 bits
=C2=A0 =C2=A0 Defines the interpretation of the payload data
=C2=A0Payload length: =C2=A07 bits
=C2=A0 =C2=A0 The length of the payload: if 0-125, that is the payload len= gth.
=C2=A0 =C2=A0 =C2=A0If 126, the following 2 bytes interpreted as a 16 bit = unsigned
=C2=A0 =C2=A0 =C2=A0integer are the payload length. =C2=A0If 127, the foll= owing 8 bytes
=C2=A0 =C2=A0 =C2=A0interpreted as a 64-bit unsigned integer (the high bit= must be 0)
=C2=A0 =C2=A0 =C2=A0are the payload length. =C2=A0Multibyte length quantit= ies are expressed
=C2=A0 =C2=A0 =C2=A0in network byte order. =C2=A0The payload length is the= length of the
=C2=A0 =C2=A0 =C2=A0Extension data + the length of the Application Data. = =C2=A0The length
=C2=A0 =C2=A0 =C2=A0of the Extension data may be zero, in which case the P= ayload
=C2=A0 =C2=A0 =C2=A0length is the length of the Application data.
=C2=A0Extension data: =C2=A0n bytes
=C2=A0 =C2=A0 The extension data is 0 bytes unless there is a reserved op-= code
=C2=A0 =C2=A0 =C2=A0or reserved bit present in the frame which indicates a= n extension
=C2=A0 =C2=A0 =C2=A0has been negotiated. =C2=A0Any extension MUST specify = the length of the
=C2=A0 =C2=A0 =C2=A0extension data, or how that length may be calculated, = and its use
=C2=A0 =C2=A0 =C2=A0MUST be negotiated during the handshake. =C2=A0If pres= ent, the
=C2=A0 =C2=A0 =C2=A0extension data is included in the total payload length= .
=C2=A0Application data: =C2=A0n bytes
=C2=A0 =C2=A0 Arbitrary application data, taking up the remainder of the f= rame
=C2=A0 =C2=A0 =C2=A0after any extension data. =C2=A0The length of the Appl= ication data is
=C2=A0 =C2=A0 =C2=A0equal to the payload length minus the length of the Ex= tension
=C2=A0 =C2=A0 =C2=A0data.
=C2=A0The base framing protocol is formally defined by the following ABNF<= br> =C2=A0 [RFC5234]:
=C2=A0 =C2=A0 ws-frame =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =3D frame-fin
=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 =C2=A0 frame-rsv1
=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 =C2=A0 frame-rsv2
=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 =C2=A0 frame-rsv3
=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 =C2=A0 frame-opcode
=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 =C2=A0 frame-rsv4
=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 =C2=A0 frame-length
=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 =C2=A0 frame-extension
=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 =C2=A0 application-data;
=C2=A0 =C2=A0 frame-fin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D %x0 ; more frames of this message follow
=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 / %x1 ; final frame of message
=C2=A0 =C2=A0 frame-rsv1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x0= ; 1 bit, must be 0
=C2=A0 =C2=A0 frame-rsv2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x0= ; 1 bit, must be 0
=C2=A0 =C2=A0 frame-rsv3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x0= ; 1 bit, must be 0
=C2=A0 =C2=A0 frame-opcode =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x0 ; co= ntinuation frame
=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 / %x1 ; connection close
=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 / %x2 ; ping
=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 / %x3 ; pong
=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 / %x4 ; text frame
=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 / %x5 ; binary frame
=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 / %x6-F ; reserved
=C2=A0 =C2=A0 frame-rsv4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x0= ; 1 bit, must be 0
=C2=A0 =C2=A0 frame-length =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %x00-7D<= br> =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 / %x7E frame-length-16
=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 / %x7F frame-length-63
=C2=A0 =C2=A0 frame-length-16 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D %x0000-FFFF =C2=A0 =C2=A0 frame-length-63 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D %x00000000000= 00000-7FFFFFFFFFFFFFFF
=C2=A0 =C2=A0 frame-extension =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D *( %x00-FF ) = ; to be defined later
=C2=A0 =C2=A0 application-data =C2=A0 =C2=A0 =C2=A0 =3D *( %x00-FF )
4.4. =C2=A0Fragmentation
=C2=A0The primary purpose of fragmentation is to allow sending a message =C2=A0 that is of unknown size when the message is started without having = to
=C2=A0 buffer that message. =C2=A0If messages couldn't be fragmented, = then an
=C2=A0 endpoint would have to buffer the entire message so its length coul= d
=C2=A0 be counted before first byte is sent. =C2=A0With fragmentation, a s= erver
=C2=A0 or intermediary may choose a reasonable size buffer, and when the =C2=A0 buffer is full write a fragment to the network.
=C2=A0A secondary use-case for fragmentation is for multiplexing, where it=
=C2=A0 is not desirable for a large message on one logical channel to
=C2=A0 monopolize the output channel, so the MUX needs to be free to split=
=C2=A0 the message into smaller fragments to better share the output
=C2=A0 channel.
=C2=A0The following rules apply to fragmentation:
=C2=A0o =C2=A0An unfragmented message consists of a single frame with the = FIN
=C2=A0 =C2=A0 =C2=A0bit set and an opcode other than 0.
=C2=A0o =C2=A0A fragmented message consists of a single frame with the FIN= bit
=C2=A0 =C2=A0 =C2=A0clear and an opcode other than 0, followed by zero or = more frames
=C2=A0 =C2=A0 =C2=A0with the FIN bit clear and the opcode set to 0, and te= rminated by
=C2=A0 =C2=A0 =C2=A0a single frame with the FIN bit set and an opcode of 0= . =C2=A0Its
=C2=A0 =C2=A0 =C2=A0content is the concatenation of the application data f= rom each of
=C2=A0 =C2=A0 =C2=A0those frames in order. =C2=A0As an example, for a text= message sent as
=C2=A0 =C2=A0 =C2=A0three fragments, the first fragment would have an opco= de of 0x4
=C2=A0 =C2=A0 =C2=A0and a FIN bit clear, the second fragment would have an= opcode of
=C2=A0 =C2=A0 =C2=A00x0 and a FIN bit clear, and the third fragment would = have an
=C2=A0 =C2=A0 =C2=A0opcode of 0x0 and a FIN bit that is set.
=C2=A0o =C2=A0Control frames MAY be injected in the middle of a fragmented=
=C2=A0 =C2=A0 =C2=A0message. =C2=A0Control frames themselves MUST NOT be f= ragmented. _Note:
=C2=A0 =C2=A0 =C2=A0if control frames could not be interjected, the latenc= y of a ping,
=C2=A0 =C2=A0 =C2=A0for example, would be very long if behind a large mess= age. =C2=A0As
=C2=A0 =C2=A0 =C2=A0such, an endpoint MUST be capable of handling control = frames in
=C2=A0 =C2=A0 =C2=A0the middle of a fragmented message._

Please don't have MUSTs inside notes, since the conformance section
says notes are non-normative.


fixed
=C2=A0

=C2=A0 o =C2=A0A sender MAY create fragments of any size for non control =C2=A0 =C2=A0 =C2=A0messages.
=C2=A0o =C2=A0Clients and servers MUST support receiving both fragmented a= nd
=C2=A0 =C2=A0 =C2=A0unfragmented messages.
=C2=A0o =C2=A0An intermediary MAY change the fragmentation of a message if= the
=C2=A0 =C2=A0 =C2=A0message uses only opcode and reserved bit values known= to the
=C2=A0 =C2=A0 =C2=A0intermediary.
=C2=A0o =C2=A0As a consequence of these rules, all fragments of a message = are of
=C2=A0 =C2=A0 =C2=A0the same type, as set by the first fragment's opco= de. =C2=A0Since
=C2=A0 =C2=A0 =C2=A0Control frames cannot be fragmented, the type for all = fragments in
=C2=A0 =C2=A0 =C2=A0a message MUST be either text or binary, or one of the= reserved
=C2=A0 =C2=A0 =C2=A0opcodes.
4.5. =C2=A0Control Frames
=C2=A0Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03 =C2=A0 (Pong). =C2=A0Control frames are used to communicate state about th= e
=C2=A0 websocket. =C2=A0Control frames can be interjected in the middle of= a
=C2=A0 fragmented message.
=C2=A0All control frames MUST be 125 bytes or less in length and MUST NOT<= br> =C2=A0 be fragmented.
4.5.1. =C2=A0Close
=C2=A0The Close message contains an opcode of 0x01.
=C2=A0The Close message MAY contain a body (the "application data&quo= t; portion
=C2=A0 of the frame) that indicates a reason for closing, such as an
=C2=A0 endpoint shutting down, an endpoint having received a message too =C2=A0 large, or an endpoint having received a message that does not confo= rm
=C2=A0 to the format expected by the other endpoint. =C2=A0If there is a b= ody,
=C2=A0 the first two bytes of the body MUST be a 2-byte integer (in networ= k
=C2=A0 byte order) representing a status code defined in Section 7.4.
=C2=A0 Following the 2-byte integer the body MAY contain UTF-8 encoded dat= a,
=C2=A0 the interpretation of which is not defined by this specification. =C2=A0The application MUST NOT send any more data messages after sending a=
=C2=A0 close message.

What are 'data messages'? I see data frames, but not data messages.= Are
control frames allowed to be sent after close?


Changed to be data frames. Control frames I believe = should still be allowed. Let's say you send a close frame and don't= get a response, perhaps you try again? Though I don't feel especially = strongly here.
=C2=A0

=C2=A0 If an endpoint receives a Close message and that endpoint did not =C2=A0 previously send a Close message, the endpoint MUST send a Close
=C2=A0 message in response. =C2=A0It SHOULD do so as soon as is practical.=
=C2=A0After both sending and receiving a close message, an endpoint
=C2=A0 considers the websocket connection closed, and SHOULD close the
=C2=A0 underlying TCP connection.
=C2=A0If a client and server both send a Close message at the same time, =C2=A0 both endpoints will have sent and received a Close message and shou= ld
=C2=A0 consider the websocket connection closed and close the underlying T= CP
=C2=A0 connection.
4.5.2. =C2=A0Ping
=C2=A0The Ping message contains an opcode of 0x02.
=C2=A0Upon receipt of a Ping message, an endpoint MUST send a Pong message=
=C2=A0 in response. =C2=A0It SHOULD do so as soon as is practical. =C2=A0T= he message
=C2=A0 bodies of the Ping and Pong MUST be the same.
4.5.3. =C2=A0Pong
=C2=A0The Pong message contains an opcode of 0x03.
=C2=A0Upon receipt of a Ping message, an endpoint MUST send a Pong message=
=C2=A0 in response. =C2=A0It SHOULD do so as soon as is practical. =C2=A0T= he message
=C2=A0 bodies of the Ping and Pong MUST be the same. =C2=A0A Pong is issue= d only
=C2=A0 in response to the most recent Ping.

This text is identical to the text in the previous section, except for
the last sentence. I suggest stating the requirements only once, and
making the last sentence normative by including a MUST.


In the latest draft there are some differen= ces. =C2=A0fixed re: the last sentence.
=C2=A0

4.6. =C2=A0Data Frames
=C2=A0All frame types not listed in Section 4.5 are data frames, which
=C2=A0 transport application-layer data. =C2=A0The opcode determines the =C2=A0 interpretation of the application data:
=C2=A0Text
=C2=A0 =C2=A0 The payload data is text data encoded as UTF-8.
=C2=A0Binary
=C2=A0 =C2=A0 The payload data is arbitrary binary data whose interpretati= on is
=C2=A0 =C2=A0 =C2=A0solely up to the application layer.
4.7. =C2=A0Examples
=C2=A0_This section is non-normative._
=C2=A0o =C2=A0A single-frame text message
=C2=A0 =C2=A0 * =C2=A00x84 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "H= ello")
=C2=A0o =C2=A0A fragmented text message
=C2=A0 =C2=A0 * =C2=A00x04 0x03 0x48 0x65 0x6c (contains "Hel")<= br> =C2=A0 =C2=A0 * =C2=A00x80 0x02 0x6c 0x6f (contains "lo")
=C2=A0o =C2=A0Ping request and response
=C2=A0 =C2=A0 * =C2=A00x82 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body = of "Hello",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 but the contents of the body are arbitrary) =C2=A0 =C2=A0 * =C2=A00x83 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body = of "Hello",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 matching the body of the ping)
=C2=A0o =C2=A0256 bytes binary message in a single frame
=C2=A0 =C2=A0 * =C2=A00x85 0x7E 0x0100 [256 bytes of binary data]
=C2=A0o =C2=A064KiB binary message in a single frame
=C2=A0 =C2=A0 * =C2=A00x85 0x7F 0x0000000000010000 [65536 bytes of binary = data]
4.8. =C2=A0Extensibility
=C2=A0The protocol is designed to allow for extensions, which will add
=C2=A0 capabilities to the base protocols. =C2=A0The endpoints of a connec= tion
=C2=A0 MUST negotiate the use of any extensions during the handshake. =C2= =A0This
=C2=A0 specification provides opcodes 0x6 through 0xF, the extension data<= br> =C2=A0 field, and the frame-rsv1, frame-rsv2, frame-rsv3, and frame-rsv4 =C2=A0 bits of the frame header for use by extensions. =C2=A0The negotiati= on of
=C2=A0 extensions is discussed in further detail in Section 8.1. =C2=A0Bel= ow are
=C2=A0 some anticipated uses of extensions. =C2=A0This list is neither com= plete
=C2=A0 nor proscriptive.
=C2=A0o =C2=A0Extension data may be placed in the payload before the appli= cation
=C2=A0 =C2=A0 =C2=A0data.
=C2=A0o =C2=A0Reserved bits can be allocated for per-frame needs.
=C2=A0o =C2=A0Reserved opcode values can be defined.
=C2=A0o =C2=A0Reserved bits can be allocated to the opcode field if more o= pcode
=C2=A0 =C2=A0 =C2=A0values are needed.
=C2=A0o =C2=A0A reserved bit or an "extension" opcode can be def= ined which
=C2=A0 =C2=A0 =C2=A0allocates additional bits out of the payload area to d= efine larger
=C2=A0 =C2=A0 =C2=A0opcodes or more per-frame bits.
5. =C2=A0Opening Handshake
5.1. =C2=A0Client Requirements
=C2=A0User agents running in controlled environments, e.g. browsers on
=C2=A0 mobile handsets tied to specific carriers, may offload the manageme= nt
=C2=A0 of the connection to another agent on the network. =C2=A0In such a<= br> =C2=A0 situation, the user agent for the purposes of conformance is
=C2=A0 considered to include both the handset software and any such agents= .
=C2=A0When the user agent is to *establish a WebSocket connection* to a =C2=A0 WebSocket URI /uri/, it must meet the following requirements. =C2= =A0In the
=C2=A0 following text, we will use terms from Section 3 such as "/hos= t/" and
=C2=A0 "/secure/ flag" as defined in that section.

Section 11 says that specifications are to feed this algorithm with
/host/, /port/, /resource name/, /secure/, /origin/ and /subprotocol/.
Not /uri/. The WebSocket API invokes this algorithm in accordance with
section 11. Please make this text closer to what it is in -00.


I have tried to address this by esse= ntially saying the algorithm can be invoked with a URI when then the algori= thms in section 3 are invoked to break down that URI, or the algorithm can = be invoked by passing in the parameters specified in section 11. I think it= results in the same net effect and is somewhat cleaner.
=C2=A0

Actually the WebSocket API also has a /defer cookies/ flag. It seems
this has not been incorporated into the spec, or has been dropped at
some point. Please take in the defer cookies stuff from
http://www.whatwg.org/specs/web-socket-protocol/ (the opening parag= raph
in section 5, step 46 and 47 in the algorithm, and the *apply the
cookies* definition.


The= re are a few hooks that are not consistent, /defer cookies/ was one of them= . I need to sit down with Hixie as part of review and iron these out. I don= 't think reviving /defer cookies/ would be sufficient.



=C2=A0

=C2=A0 1. =C2=A0The WebSocket URI and its components MUST be valid accordi= ng to
=C2=A0 =C2=A0 =C2=A0 Section 3.3. =C2=A0If any of the requirements are not= met, the client
=C2=A0 =C2=A0 =C2=A0 MUST fail the WebSocket connection and abort these st= eps.

Checking this is the responsibility of the API spec, by invoking "pars= e
a WebSocket URI's components" defined in this specification. If it=
fails to parse, this algorithm is not invoked to begin with.

The API spec is not necessarily the only thing that c= ould use the protocol. I don't see harm in leaving this in.
=C2=A0

=C2=A0 2. =C2=A0If the user agent already has a WebSocket connection to th= e
=C2=A0 =C2=A0 =C2=A0 remote host (IP address) identified by /host/, even i= f known by
=C2=A0 =C2=A0 =C2=A0 another name, the user agent MUST wait until that con= nection has
=C2=A0 =C2=A0 =C2=A0 been established or for that connection to have faile= d. =C2=A0There
=C2=A0 =C2=A0 =C2=A0 MUST be no more than one connection in a CONNECTING s= tate. =C2=A0If

Regardless of host? So we serialize tabs as well?

=
I'm not sure I understand what you mean by serializing tabs?= The intent was that if a.com resolves to 1.2.= 3.4 and b.com also resolves to 1.2.3.4, a conn= ection to b.com should wait while a connection= to a.com is establishing.
=C2=A0

=C2=A0 =C2=A0 =C2=A0 multiple connections to the same IP address are attem= pted
=C2=A0 =C2=A0 =C2=A0 simultaneously, the user agent MUST serialize them so= that there
=C2=A0 =C2=A0 =C2=A0 is no more than one connection at a time running thro= ugh the
=C2=A0 =C2=A0 =C2=A0 following steps.
=C2=A0 =C2=A0 =C2=A0If the user agent cannot determine the IP address of t= he remote
=C2=A0 =C2=A0 =C2=A0 host (for example because all communication is being = done through
=C2=A0 =C2=A0 =C2=A0 a proxy server that performs DNS queries itself), the= n the user
=C2=A0 =C2=A0 =C2=A0 agent MUST assume for the purposes of this step that = each host
=C2=A0 =C2=A0 =C2=A0 name refers to a distinct remote host, but should ins= tead limit
=C2=A0 =C2=A0 =C2=A0 the total number of simultaneous connections that are= not
=C2=A0 =C2=A0 =C2=A0 established to a reasonably low number (e.g., in a We= b browser,
=C2=A0 =C2=A0 =C2=A0 to the number of tabs the user has open).
=C2=A0 =C2=A0 =C2=A0NOTE: This makes it harder for a script to perform a d= enial of
=C2=A0 =C2=A0 =C2=A0 service attack by just opening a large number of WebS= ocket
=C2=A0 =C2=A0 =C2=A0 connections to a remote host. =C2=A0A server can furt= her reduce the
=C2=A0 =C2=A0 =C2=A0 load on itself when attacked by making use of this by= pausing
=C2=A0 =C2=A0 =C2=A0 before closing the connection, as that will reduce th= e rate at
=C2=A0 =C2=A0 =C2=A0 which the client reconnects.
=C2=A0 =C2=A0 =C2=A0NOTE: There is no limit to the number of established W= ebSocket
=C2=A0 =C2=A0 =C2=A0 connections a user agent can have with a single remot= e host.

No upper limit?

correct

<= /div>
=C2=A0

=C2=A0 =C2=A0 =C2=A0 Servers can refuse to connect users with an excessive= number of
=C2=A0 =C2=A0 =C2=A0 connections, or disconnect resource-hogging users whe= n suffering
=C2=A0 =C2=A0 =C2=A0 high load.
=C2=A03. =C2=A0_Proxy Usage_: If the user agent is configured to use a pro= xy
=C2=A0 =C2=A0 =C2=A0 when using the WebSocket protocol to connect to host = /host/
=C2=A0 =C2=A0 =C2=A0 and/or port /port/, then the user agent SHOULD connec= t to that
=C2=A0 =C2=A0 =C2=A0 proxy and ask it to open a TCP connection to the host= given by
=C2=A0 =C2=A0 =C2=A0 /host/ and the port given by /port/.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 EXAMPLE: For example, if the user agent uses a= n HTTP proxy for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0all traffic, then if it was to try to co= nnect to port 80 on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server example.com, it might send the following lines to the =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxy server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CONNECT example.com:80 HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Host: example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If there was a password, the connection might = look like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CONNECT example.com:80 HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Host: example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Proxy-authorization: Basic= ZWRuYW1vZGU6bm9jYXBlcyE=3D
=C2=A0 =C2=A0 =C2=A0If the user agent is not configured to use a proxy, th= en a direct
=C2=A0 =C2=A0 =C2=A0 TCP connection SHOULD be opened to the host given by = /host/ and
=C2=A0 =C2=A0 =C2=A0 the port given by /port/.
=C2=A0 =C2=A0 =C2=A0NOTE: Implementations that do not expose explicit UI f= or
=C2=A0 =C2=A0 =C2=A0 selecting a proxy for WebSocket connections separate = from other
=C2=A0 =C2=A0 =C2=A0 proxies are encouraged to use a SOCKS proxy for WebSo= cket
=C2=A0 =C2=A0 =C2=A0 connections, if available, or failing that, to prefer= the proxy
=C2=A0 =C2=A0 =C2=A0 configured for HTTPS connections over the proxy confi= gured for
=C2=A0 =C2=A0 =C2=A0 HTTP connections.
=C2=A0 =C2=A0 =C2=A0For the purpose of proxy autoconfiguration scripts, th= e URI to
=C2=A0 =C2=A0 =C2=A0 pass the function must be constructed from /host/, /p= ort/,
=C2=A0 =C2=A0 =C2=A0 /resource name/, and the /secure/ flag using the step= s to
=C2=A0 =C2=A0 =C2=A0 construct a WebSocket URI.
=C2=A0 =C2=A0 =C2=A0NOTE: The WebSocket protocol can be identified in prox= y
=C2=A0 =C2=A0 =C2=A0 autoconfiguration scripts from the scheme ("ws:&= quot; for unencrypted
=C2=A0 =C2=A0 =C2=A0 connections and "wss:" for encrypted connec= tions).
=C2=A04. =C2=A0If the connection could not be opened, either because a dir= ect
=C2=A0 =C2=A0 =C2=A0 connection failed or because any proxy used returned = an error,
=C2=A0 =C2=A0 =C2=A0 then the user agent MUST fail the WebSocket connectio= n and abort
=C2=A0 =C2=A0 =C2=A0 the connection attempt.
=C2=A05. =C2=A0If /secure/ is true, the user agent MUST perform a TLS hand= shake
=C2=A0 =C2=A0 =C2=A0 over the connection. =C2=A0If this fails (e.g. the se= rver's
=C2=A0 =C2=A0 =C2=A0 certificate could not be verified), then the user age= nt MUST fail

What about popping open a dialogue if the cert is self signed?


I think that's up to the UA. The= protocol doesn't specify how the certificate is verified. If verifying= it involves displaying a prompt to the user, that is IMO at the discretion= of the UA..
=C2=A0

=C2=A0 =C2=A0 =C2=A0 the WebSocket connection and abort the connection. = =C2=A0Otherwise,
=C2=A0 =C2=A0 =C2=A0 all further communication on this channel MUST run th= rough the
=C2=A0 =C2=A0 =C2=A0 encrypted tunnel. =C2=A0[RFC2246]
=C2=A0 =C2=A0 =C2=A0User agents MUST use the Server Name Indication extens= ion in the
=C2=A0 =C2=A0 =C2=A0 TLS handshake. =C2=A0[RFC4366]
=C2=A0Once a connection to the server has been established (including a =C2=A0 connection via a proxy or over a TLS-encrypted tunnel), the client<= br> =C2=A0 MUST send a handshake to the server. =C2=A0The handshake consists o= f an
=C2=A0 HTTP upgrade request, along with a list of required and optional =C2=A0 headers. =C2=A0The requirements for this handshake are as follows.<= br> =C2=A01. =C2=A0 The handshake must be a valid HTTP request as specified by=
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC2616].
=C2=A02. =C2=A0 The Method of the request MUST be GET and the HTTP version= MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0be at least 1.1.
=C2=A0 =C2=A0 =C2=A0 For example, if the WebSocket URI is "ws://example.com/chat"= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0The first line sent SHOULD be "GET /chat H= TTP/1.1"

Please don't use SHOULD in an example, since examples are non-normative= .

made lower case
=C2=A0

=C2=A0 3. =C2=A0 The request must contain a "Request-URI" as par= t of the GET
=C2=A0 =C2=A0 =C2=A0 =C2=A0method. =C2=A0This MUST match the /resource nam= e/ Section 3.
=C2=A04. =C2=A0 The request MUST contain a "Host" header whose v= alue is equal to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the authority component of the WebSocket URI.

Make it equal to /host/ since parsing a WebSocket URI's components will=
convert it to lowercase.

done

=C2=A0

=C2=A0 5. =C2=A0 The request MUST contain an "Upgrade" header wh= ose value is
=C2=A0 =C2=A0 =C2=A0 =C2=A0equal to "websocket".
=C2=A06. =C2=A0 The request MUST contain a "Connection" header w= hose value MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0include the "Upgrade" token.
=C2=A07. =C2=A0 The request MUST include a header with the name "Sec-= WebSocket-
=C2=A0 =C2=A0 =C2=A0 =C2=A0Key". =C2=A0The value of this header MUST = be a nonce consisting of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0randomly selected 16-byte value that has been b= ase64-encoded
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC3548]. =C2=A0The nonce MUST be randomly sel= ected randomly for
=C2=A0 =C2=A0 =C2=A0 =C2=A0each connection.

Double randomly.

fixed ;-)
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0NOTE: As an example, if the randomly selected v= alue was the
=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06= 0x07 0x08 0x09
=C2=A0 =C2=A0 =C2=A0 =C2=A00x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value o= f the header
=C2=A0 =C2=A0 =C2=A0 =C2=A0would be "AQIDBAUGBwgJCgsMDQ4PEC=3D=3D&quo= t;
=C2=A08. =C2=A0 The request MUST include a header with the name "Sec-= WebSocket-
=C2=A0 =C2=A0 =C2=A0 =C2=A0Origin" if the request is coming from a br= owser client. =C2=A0If the

Maybe the conformance section should have different conformance classes
for browesr clients and non-browser clients.


I'm not going to touch this one late in the game. = How strongly do you feel?
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0connection is from a non-browser client, the re= quest MAY include
=C2=A0 =C2=A0 =C2=A0 =C2=A0this header if the semantics of that client mat= ch the use-case
=C2=A0 =C2=A0 =C2=A0 =C2=A0described here for browser clients. =C2=A0The v= alue of this header
=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be the ASCII serialization of origin of th= e context in
=C2=A0 =C2=A0 =C2=A0 =C2=A0which the code establishing the connection is r= unning, and MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0be lower-case. =C2=A0The value MUST NOT contain= letters in the range
=C2=A0 =C2=A0 =C2=A0 =C2=A0U+0041 to U+005A (i.e. =C2=A0LATIN CAPITAL LETT= ER A to LATIN CAPITAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0LETTER Z) [I-D.ietf-websec-origin].
=C2=A0 =C2=A0 =C2=A0 As an example, if code is running on www.example.com attempting
=C2=A0 =C2=A0 =C2=A0 =C2=A0to establish a connection to ww2.example.com, the value of the =C2=A0 =C2=A0 =C2=A0 =C2=A0header would be "http://www.example.com".
=C2=A09. =C2=A0 The request MUST include a header with the name "Sec-= WebSocket-
=C2=A0 =C2=A0 =C2=A0 =C2=A0Version". =C2=A0The value of this header m= ust be 6.
=C2=A010. =C2=A0The request MAY include a header with the name "Sec-W= ebSocket-
=C2=A0 =C2=A0 =C2=A0 =C2=A0Protocol". =C2=A0If present, this value in= dicates the subprotocol(s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0the client wishes to speak. =C2=A0The elements = that comprise this
=C2=A0 =C2=A0 =C2=A0 =C2=A0value MUST be non-empty strings with characters= in the range
=C2=A0 =C2=A0 =C2=A0 =C2=A0U+0021 to U+007E and MUST all be unique. =C2=A0= The ABNF for the value

and MUST all be unique strings. (just to make sure you don't think the<= br> characters must be unique)

done
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0of this header is 1#(token | quoted-string), wh= ere the
=C2=A0 =C2=A0 =C2=A0 =C2=A0definitions of constructs and rules are as give= n in [RFC2616].

I'd like this to say that, at least for browser clients, if the
algorithm was invoked with a non-empty list of /subprotocols/ then the
header MUST be included, with the values of /subprotocols/ joined by a
comma and a space, and otherwise MUST NOT be included. Otherwise a
browser would be conforming for requesting subprotocols at random.

It seems like that should be in the API require= ment, not the protocol requirement?
=C2=A0

=C2=A0 11. =C2=A0The request MAY include a header with the name "Sec-= WebSocket-
=C2=A0 =C2=A0 =C2=A0 =C2=A0Extensions". =C2=A0If present, this value = indicates the protocol-
=C2=A0 =C2=A0 =C2=A0 =C2=A0level extension(s) the client wishes to speak. = =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0interpretation and format of this header is des= cribed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 8.1.
=C2=A012. =C2=A0The request MAY include headers associated with sending co= okies,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as defined by the appropriate specifications =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-httpstate-cookie].

Any cookies at random? I'd like, at least for browser clients, for this=
to be tighter, as it was in -00.

again,= i need to sync with hixie on the cross-spec hooks.

=C2=A0

=C2=A0 Once the client's opening handshake has been sent, the client M= UST
=C2=A0 wait for a response from the server before sending any further data= .
=C2=A0 The client MUST validate the server's response as follows:
=C2=A0o =C2=A0If the status code received from the server is not 101, the = client
=C2=A0 =C2=A0 =C2=A0MUST fail the WebSocket connection.
=C2=A0o =C2=A0If the response lacks an Upgrade header or the Upgrade heade= r
=C2=A0 =C2=A0 =C2=A0contains a value that is not an ASCII case-insensitive= match for
=C2=A0 =C2=A0 =C2=A0the value "websocket", the client MUST fail = the WebSocket
=C2=A0 =C2=A0 =C2=A0connection.
=C2=A0o =C2=A0If the response lacks a Connection header or the Connection = header
=C2=A0 =C2=A0 =C2=A0contains a value that is not an ASCII case-insensitive= match for
=C2=A0 =C2=A0 =C2=A0the value "Upgrade", the client MUST fail th= e WebSocket
=C2=A0 =C2=A0 =C2=A0connection.
=C2=A0o =C2=A0If the response lacks a Sec-WebSocket-Accept header or the S= ec-
=C2=A0 =C2=A0 =C2=A0WebSocket-Accept contains a value other than the base6= 4-encoded
=C2=A0 =C2=A0 =C2=A0SHA-1 of the concatenation of the Sec-WebSocket-Key (a= s a string,
=C2=A0 =C2=A0 =C2=A0not base64-decoded) with the string "258EAFA5-E91= 4-47DA-95CA-
=C2=A0 =C2=A0 =C2=A0C5AB0DC85B11", the client MUST fail the WebSocket= connection.

-00 had rules for failing the websocket connection if the response had
certain other errors, like the wrong type of linebreaks. What's the
deal now? I haven't reviewed the security implications, but there may be some if clients are tolerant in their parsing of the server's
handshake.

The group had a big push tow= ards "it's HTTP and is HTTP compatibile" so this all got re-w= ritten... if it's valid HTTP then it's OK, if it's not then not= -- that was my interpretation...
=C2=A0

=C2=A0 Where the algorithm above requires that a user agent fail the
=C2=A0 WebSocket connection, the user agent may first read an arbitrary =C2=A0 number of further bytes from the connection (and then discard them)=
=C2=A0 before actually *failing the WebSocket connection*. =C2=A0Similarly= , if a
=C2=A0 user agent can show that the bytes read from the connection so far<= br> =C2=A0 are such that there is no subsequent sequence of bytes that the
=C2=A0 server can send that would not result in the user agent being
=C2=A0 required to *fail the WebSocket connection*, the user agent may
=C2=A0 immediately *fail the WebSocket connection* without waiting for tho= se
=C2=A0 bytes.
=C2=A0NOTE: The previous paragraph is intended to make it conforming for =C2=A0 user agents to implement the algorithm in subtly different ways tha= t
=C2=A0 are equivalent in all ways except that they terminate the connectio= n
=C2=A0 at earlier or later points. =C2=A0For example, it enables an
=C2=A0 implementation to buffer the entire handshake response before
=C2=A0 checking it, or to verify each field as it is received rather than<= br> =C2=A0 collecting all the fields and then checking them as a block.

It seems these two paragraphs aren't needed anymore when you don't = have
a detailed algorithm but just some bullet points.

5.2. =C2=A0Server-side requirements
=C2=A0_This section only applies to servers._
=C2=A0Servers may offload the management of the connection to other agents=
=C2=A0 on the network, for example load balancers and reverse proxies. =C2= =A0In
=C2=A0 such a situation, the server for the purposes of conformance is
=C2=A0 considered to include all parts of the server-side infrastructure =C2=A0 from the first device to terminate the TCP connection all the way t= o
=C2=A0 the server that processes requests and sends responses.
=C2=A0EXAMPLE: For example, a data center might have a server that respond= s
=C2=A0 to WebSocket requests with an appropriate handshake, and then passe= s
=C2=A0 the connection to another server to actually process the data frame= s.
=C2=A0 For the purposes of this specification, the "server" is t= he
=C2=A0 combination of both computers.
5.2.1. =C2=A0Reading the client's opening handshake
=C2=A0When a client starts a WebSocket connection, it sends its part of th= e
=C2=A0 opening handshake. =C2=A0The server must parse at least part of thi= s
=C2=A0 handshake in order to obtain the necessary information to generate<= br> =C2=A0 the server part of the handshake.
=C2=A0The client handshake consists of the following parts. =C2=A0If the s= erver,
=C2=A0 while reading the handshake, finds that the client did not send a =C2=A0 handshake that matches the description below, the server must abort=
=C2=A0 the WebSocket connection.
=C2=A01. =C2=A0An HTTP/1.1 or higher GET request, including a "Reques= t-URI"
=C2=A0 =C2=A0 =C2=A0 [RFC2616] that should be interpreted as a /resource n= ame/
=C2=A0 =C2=A0 =C2=A0 Section 3.
=C2=A02. =C2=A0A "Host" header containing the server's autho= rity.
=C2=A03. =C2=A0A "Sec-WebSocket-Key" header with a base64-encode= d value that,
=C2=A0 =C2=A0 =C2=A0 when decoded, is 16 bytes in length.
=C2=A04. =C2=A0A "Sec-WebSocket-Version" header, with a value of= 6.
=C2=A05. =C2=A0Optionally, a "Sec-WebSocket-Origin" header. =C2= =A0This header is sent
=C2=A0 =C2=A0 =C2=A0 by all browser clients. =C2=A0A connection attempt la= cking this header
=C2=A0 =C2=A0 =C2=A0 SHOULD NOT be interpreted as coming from a browser cl= ient.
=C2=A06. =C2=A0Optionally, a "Sec-WebSocket-Protocol header, with a l= ist of
=C2=A0 =C2=A0 =C2=A0 values indicating which protocols the client would li= ke to speak,
=C2=A0 =C2=A0 =C2=A0 ordered by preference.

Missing quote.

-00 was stricter about the Sec-WebSocket-Protocol header: if the algorithm = was fed with an empty /subprotocols/ then the header must not be included, = else the header must be included with the values of /subprotocols/. I prefe= r that over anything-goes "optinally".

=C2=A0 7. =C2=A0Optionally, a "Sec-WebSocket-Extensions" header,= with a list of
=C2=A0 =C2=A0 =C2=A0 values indicating which extensions the client would l= ike to
=C2=A0 =C2=A0 =C2=A0 speak. =C2=A0The interpretation of this header is dis= cussed in
=C2=A0 =C2=A0 =C2=A0 Section 8.1.
=C2=A08. =C2=A0Optionally, other headers, such as those used to send cooki= es to
=C2=A0 =C2=A0 =C2=A0 a server. =C2=A0Unknown headers MUST be ignored.
5.2.2. =C2=A0Sending the server's opening handshake
=C2=A0When a client establishes a WebSocket connection to a server, the =C2=A0 server must complete the following steps to accept the connection a= nd
=C2=A0 send the server's opening handshake.
=C2=A01. =C2=A0If the server supports encryption, perform a TLS handshake = over
=C2=A0 =C2=A0 =C2=A0 the connection. =C2=A0If this fails (e.g. the client = indicated a host

If the server supports encryption? A bit unclear... if can support
encryption but the requested URL might be ws:


will chat with hixie on cross-protocol things, frankl= y I hold firm that tls with http:// is rather useless and i really don'= t worry about it for ws...

=C2=A0

=C2=A0 =C2=A0 =C2=A0 name in the extended client hello "server_name&q= uot; extension that
=C2=A0 =C2=A0 =C2=A0 the server does not host), then close the connection;= otherwise,
=C2=A0 =C2=A0 =C2=A0 all further communication for the connection (includi= ng the
=C2=A0 =C2=A0 =C2=A0 server handshake) must run through the encrypted tunn= el.
=C2=A0 =C2=A0 =C2=A0 [RFC2246]
=C2=A02. =C2=A0Establish the following information:
=C2=A0 =C2=A0 =C2=A0/origin/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The |Sec-WebSocket-Origin| header in the= client's handshake
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0indicates the origin of the script estab= lishing the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection. =C2=A0The origin is serializ= ed to ASCII and converted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to lowercase. =C2=A0The server MAY use t= his information as part of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a determination of whether to accept the= incoming connection.

I'd like a warning here that if the server doesn't validate the ori= gin,
it means that it will accept connections from anywhere. Normally it's the browser's responsibility to enforce same-origin restrictions, but with websockets it's the server application developer's responsibil= ity,
and this needs to be pointed out explicitly IMHO.

I see now that there's a paragraph discussing this in security
considerations. I'd be happy with a pointer to security considerations<= br> here.

done
=C2=A0

=C2=A0 =C2=A0 =C2=A0 /key/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The |Sec-WebSocket-Key| header in the cl= ient's handshake
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0includes a base64-encoded value that, if= decoded, is 16 bytes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in length. =C2=A0This (encoded) value is= used in the creation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the server's handshake to indicate a= n acceptance of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection. =C2=A0It is not necessary fo= r the server to base64-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decode the Sec-WebSocket-Key value.
=C2=A0 =C2=A0 =C2=A0/version/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The |Sec-WebSocket-Version| header in th= e client's handshake
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0includes the version of the WebSocket pr= otocol the client is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attempting to communicate with. =C2=A0If= this version does not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0match a version understood by the server= , the server MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abort the WebSocket connection. =C2=A0Th= e server MAY send a non-200
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response code with a |Sec-WebSocket-Vers= ion| header indicating
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the version(s) the server is capable of = understanding along
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with this non-200 response code.
=C2=A0 =C2=A0 =C2=A0/resource name/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An identifier for the service provided b= y the server. =C2=A0If the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server provides multiple services, then = the value should be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0derived from the resource name given in = the client's handshake
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the Request-URI [RFC2616] of the GE= T method.
=C2=A0 =C2=A0 =C2=A0/subprotocol/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A (possibly empty) list representing the= subprotocol the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server is ready to use. =C2=A0If the ser= ver supports multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subprotocols, then the value should be d= erived from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client's handshake, specifically by = selecting one of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0values from the "Sec-WebSocket-Prot= ocol" field. =C2=A0The absence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of such a field is equivalent to the nul= l value. =C2=A0The empty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string is not the same as the null value= for these purposes.
=C2=A0 =C2=A0 =C2=A0/extensions/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A (possibly empty) list representing the= protocol-level
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extensions the server is ready to use. = =C2=A0If the server supports
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple extensions, then the value shou= ld be derived from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client's handshake, specifically by = selecting one or more of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the values from the "Sec-WebSocket-= Extensions" field. =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0absence of such a field is equivalent to= the null value. =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0empty string is not the same as the null= value for these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0purposes. =C2=A0Extensions not listed by= the client MUST NOT be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0listed. =C2=A0The method by which these = values should be selected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and interpreted is discussed in Section = 8.1.
=C2=A03. =C2=A0If the server chooses to accept the incoming connection, it= must
=C2=A0 =C2=A0 =C2=A0 reply with a valid HTTP response indicating the follo= wing.
=C2=A0 =C2=A0 =C2=A01. =C2=A0A 101 response code. =C2=A0Such a response co= uld look like
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "HTTP/1.1 101 Switching Protocols&= quot;
=C2=A0 =C2=A0 =C2=A02. =C2=A0A "Sec-WebSocket-Accept" header. = =C2=A0The value of this header is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constructed by concatenating /key/, def= ined above in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paragraph 2 of Section 5.2.2, with the = string "258EAFA5-E914-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 47DA-95CA-C5AB0DC85B11", taking th= e SHA-1 hash of this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 concatenated value to obtain a 20-byte = value, and base64-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encoding this 20-byte hash.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NOTE: As an example, if the value of the= "Sec-WebSocket-Key"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 header in the client's handshake we= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "dGhlIHNhbXBsZSBub25jZQ=3D=3D"= ;, the server would append the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string "258EAFA5-E914-47DA-95CA-C5= AB0DC85B11" to form the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string "dGhlIHNhbXBsZSBub25jZQ=3D= =3D258EAFA5-E914-47DA-95CA-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C5AB0DC85B11". =C2=A0The server wo= uld then take the SHA-1 hash of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this string, giving the value 0xb3 0x7a= 0x4f 0x2c 0xc0 0x62
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38= 0x59 0x45 0xb2 0xbe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0xc4 0xea. =C2=A0This value is then bas= e64-encoded, to give the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo= =3D", which would be returned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the "Sec-WebSocket-Accept"= header.
=C2=A0 =C2=A0 =C2=A03. =C2=A0Optionally, a "Sec-WebSocket-Protocol&qu= ot; header, with a value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /subprotocol/ as defined in Paragraph 2= of Section 5.2.2.
=C2=A0 =C2=A0 =C2=A04. =C2=A0Optionally, a "Sec-WebSocket-Extensions&= quot; header, with a value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /extensions/ as defined in Paragraph 2 = of Section 5.2.2.
=C2=A0This completes the server's handshake. =C2=A0If the server finis= hes these
=C2=A0 steps without aborting the WebSocket connection, and if the client<= br> =C2=A0 does not then fail the WebSocket connection, then the connection is=
=C2=A0 established and the server may begin sending and receiving data, as=
=C2=A0 described in the next section.

The next section doesn't describe sending and receiving data.


done

=C2= =A0

6. =C2=A0Error Handling
6.1. =C2=A0Handling errors in UTF-8 from the server
=C2=A0When a client is to interpret a byte stream as UTF-8 but finds that<= br> =C2=A0 the byte stream is not in fact a valid UTF-8 stream, then any bytes=
=C2=A0 or sequences of bytes that are not valid UTF-8 sequences must be =C2=A0 interpreted as a U+FFFD REPLACEMENT CHARACTER.

Maybe use the HTML spec's definition of UTF-8 with error handling:
htt= p://www.whatwg.org/specs/web-apps/current-work/complete/infrastructure.html= #decoded-as-utf-8,-with-error-handling

6.2. =C2=A0Handling errors in UTF-8 from the client
=C2=A0When a server is to interpret a byte stream as UTF-8 but finds that<= br> =C2=A0 the byte stream is not in fact a valid UTF-8 stream, behavior is =C2=A0 undefined. =C2=A0A server could close the connection, convert inval= id byte
=C2=A0 sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim= ,
=C2=A0 or perform application-specific processing. =C2=A0Subprotocols laye= red on
=C2=A0 the WebSocket protocol might define specific behavior for servers.<= br> 7. =C2=A0Closing the connection
7.1. =C2=A0Definitions
7.1.1. =C2=A0Close the WebSocket Connection
=C2=A0To _Close the WebSocket Connection_, an endpoint closes the
=C2=A0 underlying TCP connection. =C2=A0An endpoint SHOULD use a method th= at
=C2=A0 cleanly closes the TCP connection, discarding any trailing bytes th= at
=C2=A0 may be received. =C2=A0And endpoint MAY close the connection via an= y means

s/And/An/

done
=C2=A0

=C2=A0 available when necessary, such as when under attack.
=C2=A0As an example of how to obtain a clean closure in C using Berkeley =C2=A0 sockets, one would call shutdown() with SHUT_WR on the socket, call=
=C2=A0 recv() until obtaining a return value of 0 indicating that the peer=
=C2=A0 has also performed an orderly shutdown, and finally calling close()=
=C2=A0 on the socket.

Hmm, this example seems a bit out of place.

7.1.2. =C2=A0Start the WebSocket Closing Handshake
=C2=A0To _start the WebSocket closing handshake_, and endpoint MUST send a=

s/and/an/

done
=C2=A0

=C2=A0 Close control frame, as described in Section 4.5.1. =C2=A0Upon rece= iving a
=C2=A0 Close control frame, the other party sends a Close control frame in=
=C2=A0 response. =C2=A0Once an endpoint has both sent and received a Close=
=C2=A0 control frame, that endpoint should _Close the WebSocket Connection= _
=C2=A0 as defined in Section 7.1.1.

Again this repeats the same requirements from 4.5.1, but subtly
different, such that it's not clear which to follow. Please only have the same requirement once.


I removed what I think is=C2=A0duplicative=C2=A0and what remains is abou= t the minimal set.=C2=A0
=C2=A0

7.1.3. =C2=A0The WebSocket Connection Is Closed
=C2=A0When the underlying TCP connection is closed, it is said that _the =C2=A0 WebSocket connection is closed_. =C2=A0If the tcp connection was cl= osed
=C2=A0 after the WebSocket closing handshake was completed, the WebSocket<= br> =C2=A0 connection is said to have been closed _cleanly_.
7.1.4. =C2=A0Fail the WebSocket Connection
=C2=A0Certain algorithms and specifications require a user agent to _fail<= br> =C2=A0 the WebSocket connection_. =C2=A0To do so, the user agent must _Clo= se the
=C2=A0 WebSocket Connection_, and MAY report the problem to the user (whic= h
=C2=A0 would be especially useful for developers) in an appropriate manner= .
=C2=A0Except as indicated above or as specified by the application layer =C2=A0 (e.g. a script using the WebSocket API), user agents SHOULD NOT clo= se
=C2=A0 the connection.
7.2. =C2=A0Abnormal closures
7.2.1. =C2=A0Client-initiated closure
=C2=A0Certain algorithms, namely during the initial handshake, require the=
=C2=A0 user agent to *fail the WebSocket connection*. =C2=A0To do so, the = user
=C2=A0 agent must _Close the WebSocket connection_ as previously defined,<= br> =C2=A0 and may report the problem to the user via an appropriate mechanism=
=C2=A0 (which would be especially useful for developers).
=C2=A0Except as indicated above or as specified by the application layer =C2=A0 (e.g. a script using the WebSocket API), user agents should not clo= se
=C2=A0 the connection.
7.2.2. =C2=A0Server-initiated closure
=C2=A0Certain algorithms require or recommend that the server _abort the =C2=A0 WebSocket connection_ during the opening handshake. =C2=A0To do so,= the
=C2=A0 server must simply _close the WebSocket connection_ (Section 7.1.1)= .
7.3. =C2=A0Normal closure of connections
=C2=A0Servers MAY close the WebSocket connection whenever desired. =C2=A0U= ser
=C2=A0 agents SHOULD NOT close the WebSocket connection arbitrarily. =C2= =A0In
=C2=A0 either case, an endpoint initiates a closure by following the
=C2=A0 procedures to _start the WebSocket closing handshake_
=C2=A0 (Section 7.1.2).
7.4. =C2=A0Status codes
=C2=A0When closing an established connection (e.g. when sending a Close =C2=A0 frame, after the handshake has completed), an endpoint MAY indicate= a
=C2=A0 reason for closure. =C2=A0The interpretation of this reason by an =C2=A0 endpoint, and the action an endpoint should take given this reason,=
=C2=A0 are left undefined by this specification. =C2=A0This specification = defines
=C2=A0 a set of pre-defined status codes, and specifies which ranges may b= e
=C2=A0 used by extensions, frameworks, and end applications. =C2=A0The sta= tus
=C2=A0 code and any associated textual message are optional components of = a
=C2=A0 Close frame.
7.4.1. =C2=A0Defined Status Codes
=C2=A0Endpoints MAY use the following pre-defined status codes when sendin= g
=C2=A0 a Close frame.
=C2=A01000
=C2=A0 =C2=A0 1000 indicates a normal closure, meaning whatever purpose th= e
=C2=A0 =C2=A0 =C2=A0connection was established for has been fulfilled.
=C2=A01001
=C2=A0 =C2=A0 1001 indicates that an endpoint is "going away", s= uch as a server
=C2=A0 =C2=A0 =C2=A0going down, or a browser having navigated away from a = page.
=C2=A01002
=C2=A0 =C2=A0 1002 indicates that an endpoint is terminating the connectio= n due
=C2=A0 =C2=A0 =C2=A0to a protocol error.
=C2=A01003
=C2=A0 =C2=A0 1003 indicates that an endpoint is terminating the connectio= n
=C2=A0 =C2=A0 =C2=A0because it has received a type of data it cannot accep= t (e.g. an
=C2=A0 =C2=A0 =C2=A0endpoint that understands only text data may send this= if it
=C2=A0 =C2=A0 =C2=A0receives a binary message.)
=C2=A01004
=C2=A0 =C2=A0 1004 indicates that an endpoint is terminating the connectio= n
=C2=A0 =C2=A0 =C2=A0because it has received a message that is too large. 7.4.2. =C2=A0Reserved status code ranges
=C2=A00-999
=C2=A0 =C2=A0 Status codes in the range 0-999 are not used.
=C2=A01000-1999
=C2=A0 =C2=A0 Status codes in the range 1000-1999 are reserved for definit= ion by
=C2=A0 =C2=A0 =C2=A0this protocol.
=C2=A02000-2999
=C2=A0 =C2=A0 Status codes in the range 2000-2999 are reserved for use by<= br> =C2=A0 =C2=A0 =C2=A0extensions.
=C2=A03000-3999
=C2=A0 =C2=A0 Status codes in the range 3000-3999 MAY be used by libraries= and
=C2=A0 =C2=A0 =C2=A0frameworks. =C2=A0The interpretation of these codes is= undefined by
=C2=A0 =C2=A0 =C2=A0this protocol. =C2=A0End applications MUST NOT use sta= tus codes in this
=C2=A0 =C2=A0 =C2=A0range.
=C2=A04000-4999
=C2=A0 =C2=A0 Status codes in the range 4000-4999 MAY be used by applicati= on
=C2=A0 =C2=A0 =C2=A0code. =C2=A0The interpretaion of these codes is undefi= ned by this
=C2=A0 =C2=A0 =C2=A0protocol.
8. =C2=A0Extensions
=C2=A0WebSocket clients MAY request extensions to this specification, and<= br> =C2=A0 WebSocket servers MAY accept some or all extensions requested by th= e
=C2=A0 client. =C2=A0A server MUST NOT respond with any extension not requ= ested
=C2=A0 by the client. =C2=A0If extension parameters are included in negoti= ations
=C2=A0 between the client and the server, those parameters MUST be chosen = in
=C2=A0 accordance with the specification of the extension to which the
=C2=A0 parameters apply.
8.1. =C2=A0Negotiating extensions
=C2=A0A client requests extensions by including a "Sec-WebSocket-
=C2=A0 Extensions" header, which follows the normal rules for HTTP he= aders
=C2=A0 (see [RFC2616] section 4.2) and the value of the header is defined = by
=C2=A0 the following ABNF:
=C2=A0 =C2=A0 =C2=A0 =C2=A0extension-list =3D 1#extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 extension =3D extension-token *( ";"= extension-param )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 extension-token =3D registered-token | private= -use-token
=C2=A0 =C2=A0 =C2=A0 =C2=A0 registered-token =3D token
=C2=A0 =C2=A0 =C2=A0 =C2=A0 private-use-token =3D "x-" token
=C2=A0 =C2=A0 =C2=A0 =C2=A0 extension-param =3D token [ "=3D" ( = token | quoted-string ) ]
=C2=A0Note that like other HTTP headers, this header may be split or
=C2=A0 combined across multiple lines. =C2=A0Ergo, the following are equiv= alent:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Extensions: foo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sec-WebSocket-Extensions: bar; baz=3D2
=C2=A0is exactly equivalent to
=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Extensions: foo, bar; baz=3D2
=C2=A0Any extension-token used must either be a registered token
=C2=A0 (registration TBD), or have a prefix of "x-" to indicate = a private-
=C2=A0 use token. =C2=A0The parameters supplied with any given extension M= UST be
=C2=A0 defined for that extension. =C2=A0Note that the client is only offe= ring to
=C2=A0 use any advertised extensions, and MUST NOT use them unless the
=C2=A0 server accepts the extension.
=C2=A0Note that the order of extensions is significant. =C2=A0Any interact= ions
=C2=A0 between multiple extensions MAY be defined in the documents definin= g
=C2=A0 the extensions. =C2=A0In the absence of such definition, the
=C2=A0 interpretation is that the headers listed by the client in its
=C2=A0 request represent a preference of the headers it wishes to use, wit= h
=C2=A0 the first options listed being most preferable. =C2=A0The extension= s
=C2=A0 listed by the server in response represent the extensions actually = in
=C2=A0 use. =C2=A0Should the extensions modify the data and/or framing, th= e order
=C2=A0 of operations on the data should be assumed to be the same as the =C2=A0 order in which the extensions are listed in the server's respon= se in
=C2=A0 the opening handshake.
=C2=A0For example, if there are two extensions "foo" and "b= ar", if the
=C2=A0 header |Sec-WebSocket-Extensions| sent by the server has the value<= br> =C2=A0 "foo, bar" then operations on the data will be made as =C2=A0 bar(foo(data)), be those changes to the data itself (such as
=C2=A0 compression) or changes to the framing thay may "stack".<= br> =C2=A0Non-normative examples of acceptable extension headers:
=C2=A0 =C2=A0 Sec-WebSocket-Extensions: deflate-stream
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Extensions: mux; max-channels=3D4; flow-= control, deflate-stream
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Extensions: x-private-extension
=C2=A0A server accepts one or more extensions by including a |Sec-
=C2=A0 WebSocket-Extensions| header containing one or more extensions whic= h
=C2=A0 were requested by the client. =C2=A0The interpretation of any exten= sion
=C2=A0 parameters, and what constitutes a valid response by a server to a<= br> =C2=A0 requested set of parameters by a client, will be defined by each su= ch
=C2=A0 extension.
8.2. =C2=A0Known extensions
=C2=A0Extensions provide a mechanism for implementations to opt-in to
=C2=A0 additional protocol features. =C2=A0This section defines the meanin= g of
=C2=A0 well-known extensions but implementations may use extensions define= d
=C2=A0 separately as well.
8.2.1. =C2=A0Compression
=C2=A0The registered extension token for this compression extension is
=C2=A0 "deflate-stream".
=C2=A0The extension does not have any per message extension data and it =C2=A0 does not define the use of any WebSocket reserved bits or op codes.=
=C2=A0Senders using this extension MUST apply RFC 1951 encodings to all =C2=A0 bytes of the data stream following the handshake including both dat= a
=C2=A0 and control messages. =C2=A0The data stream MAY include multiple bl= ocks of
=C2=A0 both compressed and uncompressed types as defined by RFC 1951.
=C2=A0 [RFC1951]
=C2=A0Senders MUST NOT delay the transmission of any portion of a WebSocke= t
=C2=A0 message because the deflate encoding of the message does not end on= a
=C2=A0 byte boundary. =C2=A0The encodings for adjacent messages MAY appear= in the
=C2=A0 same byte if no delay in transmission is occurred by doing so.
9. =C2=A0Security considerations
=C2=A0While this protocol is intended to be used by scripts in Web pages,<= br> =C2=A0 it can also be used directly by hosts. =C2=A0Such hosts are acting = on
=C2=A0 their own behalf, and can therefore send fake "Origin" fi= elds,
=C2=A0 misleading the server. =C2=A0Servers should therefore be careful ab= out
=C2=A0 assuming that they are talking directly to scripts from known
=C2=A0 origins, and must consider that they might be accessed in unexpecte= d
=C2=A0 ways. =C2=A0In particular, a server should not trust that any input= is
=C2=A0 valid.
=C2=A0EXAMPLE: For example, if the server uses input as part of SQL
=C2=A0 queries, all input text should be escaped before being passed to th= e
=C2=A0 SQL server, lest the server be susceptible to SQL injection.
=C2=A0Servers that are not intended to process input from any Web page but=
=C2=A0 only for certain sites should verify the "Origin" field i= s an origin
=C2=A0 they expect, and should only respond with the corresponding "S= ec-
=C2=A0 WebSocket-Origin" if it is an accepted origin. =C2=A0Servers t= hat only
=C2=A0 accept input from one origin can just send back that value in the =C2=A0 "Sec-WebSocket-Origin" field, without bothering to check = the client's
=C2=A0 value.

=C2=A0If at any time a server is faced with data that it does not
=C2=A0 understand, or that violates some criteria by which the server
=C2=A0 determines safety of input, or when the server sees a handshake tha= t
=C2=A0 does not correspond to the values the server is expecting (e.g.
=C2=A0 incorrect path or origin), the server should just disconnect. =C2= =A0It is
=C2=A0 always safe to disconnect.
=C2=A0The biggest security risk when sending text data using this protocol=
=C2=A0 is sending data using the wrong encoding. =C2=A0If an attacker can = trick
=C2=A0 the server into sending data encoded as ISO-8859-1 verbatim (for =C2=A0 instance), rather than encoded as UTF-8, then the attacker could =C2=A0 inject arbitrary frames into the data stream.
=C2=A0In addition to endpoints being the target of attacks via WebSockets,=
=C2=A0 other parts of web infrastructure, such as proxies, may be the
=C2=A0 subject of an attack. =C2=A0In particular, an intermediary may inte= rpret a
=C2=A0 WebSocket message from a client as a request, and a message from th= e
=C2=A0 server as a response to that request. =C2=A0For instance, an attack= er
=C2=A0 could get a browser to establish a connection to its server, get th= e
=C2=A0 browser to send a message that looks to an intermediary like a GET<= br> =C2=A0 request for a common piece of JavaScript on another domain, and sen= d
=C2=A0 back a message that is interpreted as a cacheable response to that<= br> =C2=A0 request, thus poisioning the cache for other users. =C2=A0To preven= t this
=C2=A0 attack, messages sent from clients are masked on the wire with a 32= -
=C2=A0 bit value, to prevent an attacker from controlling the bits on the<= br> =C2=A0 wire and thus lessen the probability of an attacker being able to =C2=A0 construct a message that can be misinterpreted by a proxy as a non-=
=C2=A0 WebSocket request.
10. =C2=A0IANA considerations
10.1. =C2=A0Registration of ws: scheme
=C2=A0A |ws:| URI identifies a WebSocket server and resource name.
=C2=A0URI scheme name.
=C2=A0 =C2=A0 =C2=A0ws
=C2=A0Status.
=C2=A0 =C2=A0 =C2=A0Permanent.
=C2=A0URI scheme syntax.
=C2=A0 =C2=A0 =C2=A0In ABNF terms using the terminals from the URI specifi= cations:
=C2=A0 =C2=A0 =C2=A0[RFC5234] [RFC3986]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ws" ":" hier-part [= "?" query ]
=C2=A0 =C2=A0 The path and query components form the resource name sent to= the
=C2=A0 =C2=A0 =C2=A0server to identify the kind of service desired. =C2=A0= Other components
=C2=A0 =C2=A0 =C2=A0have the meanings described in RFC3986.
=C2=A0URI scheme semantics.
=C2=A0 =C2=A0 =C2=A0The only operation for this scheme is to open a connec= tion using
=C2=A0 =C2=A0 =C2=A0the WebSocket protocol.
=C2=A0Encoding considerations.
=C2=A0 =C2=A0 =C2=A0Characters in the host component that are excluded by = the syntax
=C2=A0 =C2=A0 =C2=A0defined above must be converted from Unicode to ASCII = by applying
=C2=A0 =C2=A0 =C2=A0the IDNA ToASCII algorithm to the Unicode host name, w= ith both the
=C2=A0 =C2=A0 =C2=A0AllowUnassigned and UseSTD3ASCIIRules flags set, and u= sing the
=C2=A0 =C2=A0 =C2=A0result of this algorithm as the host in the URI. =C2= =A0[RFC3490]
=C2=A0 =C2=A0 Characters in other components that are excluded by the synt= ax
=C2=A0 =C2=A0 =C2=A0defined above must be converted from Unicode to ASCII = by first
=C2=A0 =C2=A0 =C2=A0encoding the characters as UTF-8 and then replacing th= e
=C2=A0 =C2=A0 =C2=A0corresponding bytes using their percent-encoded form a= s defined in
=C2=A0 =C2=A0 =C2=A0the URI and IRI specification. =C2=A0[RFC3986] [RFC398= 7]
=C2=A0Applications/protocols that use this URI scheme name.
=C2=A0 =C2=A0 =C2=A0WebSocket protocol.
=C2=A0Interoperability considerations.
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0Security considerations.
=C2=A0 =C2=A0 =C2=A0See "Security considerations" section above.=
=C2=A0Contact.
=C2=A0 =C2=A0 =C2=A0Ian Hickson <ian@hixie.ch>
=C2=A0Author/Change controller.
=C2=A0 =C2=A0 =C2=A0Ian Hickson <ian@hixie.ch>
=C2=A0References.
=C2=A0 =C2=A0 =C2=A0This document.
10.2. =C2=A0Registration of wss: scheme
=C2=A0A |wss:| URI identifies a WebSocket server and resource name, and =C2=A0 indicates that traffic over that connection is to be encrypted.
=C2=A0URI scheme name.
=C2=A0 =C2=A0 =C2=A0wss
=C2=A0Status.
=C2=A0 =C2=A0 =C2=A0Permanent.
=C2=A0URI scheme syntax.
=C2=A0 =C2=A0 =C2=A0In ABNF terms using the terminals from the URI specifi= cations:
=C2=A0 =C2=A0 =C2=A0[RFC5234] [RFC3986]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"wss" ":" hier-part = [ "?" query ]
=C2=A0 =C2=A0 The path and query components form the resource name sent to= the
=C2=A0 =C2=A0 =C2=A0server to identify the kind of service desired. =C2=A0= Other components
=C2=A0 =C2=A0 =C2=A0have the meanings described in RFC3986.
=C2=A0URI scheme semantics.
=C2=A0 =C2=A0 =C2=A0The only operation for this scheme is to open a connec= tion using
=C2=A0 =C2=A0 =C2=A0the WebSocket protocol, encrypted using TLS.
=C2=A0Encoding considerations.
=C2=A0 =C2=A0 =C2=A0Characters in the host component that are excluded by = the syntax
=C2=A0 =C2=A0 =C2=A0defined above must be converted from Unicode to ASCII = by applying
=C2=A0 =C2=A0 =C2=A0the IDNA ToASCII algorithm to the Unicode host name, w= ith both the
=C2=A0 =C2=A0 =C2=A0AllowUnassigned and UseSTD3ASCIIRules flags set, and u= sing the
=C2=A0 =C2=A0 =C2=A0result of this algorithm as the host in the URI. =C2= =A0[RFC3490]
=C2=A0 =C2=A0 Characters in other components that are excluded by the synt= ax
=C2=A0 =C2=A0 =C2=A0defined above must be converted from Unicode to ASCII = by first
=C2=A0 =C2=A0 =C2=A0encoding the characters as UTF-8 and then replacing th= e
=C2=A0 =C2=A0 =C2=A0corresponding bytes using their percent-encoded form a= s defined in
=C2=A0 =C2=A0 =C2=A0the URI and IRI specification. =C2=A0[RFC3986] [RFC398= 7]
=C2=A0Applications/protocols that use this URI scheme name.
=C2=A0 =C2=A0 =C2=A0WebSocket protocol over TLS.
=C2=A0Interoperability considerations.
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0Security considerations.
=C2=A0 =C2=A0 =C2=A0See "Security considerations" section above.=
=C2=A0Contact.
=C2=A0 =C2=A0 =C2=A0Ian Hickson <ian@hixie.ch>
=C2=A0Author/Change controller.
=C2=A0 =C2=A0 =C2=A0Ian Hickson <ian@hixie.ch>
=C2=A0References.
=C2=A0 =C2=A0 =C2=A0This document.
10.3. =C2=A0Registration of the "WebSocket" HTTP Upgrade keyword<= br> =C2=A0Name of token.
=C2=A0 =C2=A0 =C2=A0WebSocket
=C2=A0Author/Change controller.
=C2=A0 =C2=A0 =C2=A0Ian Hickson <ian@hixie.ch>
=C2=A0Contact.
=C2=A0 =C2=A0 =C2=A0Ian Hickson <ian@hixie.ch>
=C2=A0References.
=C2=A0 =C2=A0 =C2=A0This document.
10.4. =C2=A0Sec-WebSocket-Key
=C2=A0This section describes a header field for registration in the
=C2=A0 Permanent Message Header Field Registry. =C2=A0[RFC3864]
=C2=A0Header field name
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Key
=C2=A0Applicable protocol
=C2=A0 =C2=A0 =C2=A0http
=C2=A0Status
=C2=A0 =C2=A0 =C2=A0reserved; do not use outside WebSocket handshake
=C2=A0Author/Change controller
=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0Specification document(s)
=C2=A0 =C2=A0 =C2=A0This document is the relevant specification.
=C2=A0Related information
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0The |Sec-WebSocket-Key| header is used in the WebSocket handshake. =C2=A0 It is sent from the client to the server to provide part of the
=C2=A0 information used by the server to prove that it received a valid =C2=A0 WebSocket handshake. =C2=A0This helps ensure that the server does n= ot
=C2=A0 accept connections from non-WebSocket clients (e.g. =C2=A0HTTP clie= nts)
=C2=A0 that are being abused to send data to unsuspecting WebSocket server= s.
10.5. =C2=A0Sec-WebSocket-Extensions
=C2=A0This section describes a header field for registration in the
=C2=A0 Permanent Message Header Field Registry. =C2=A0[RFC3864]
=C2=A0Header field name
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Extensions
=C2=A0Applicable protocol
=C2=A0 =C2=A0 =C2=A0http
=C2=A0Status
=C2=A0 =C2=A0 =C2=A0reserved; do not use outside WebSocket handshake
=C2=A0Author/Change controller
=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0Specification document(s)
=C2=A0 =C2=A0 =C2=A0This document is the relevant specification.
=C2=A0Related information
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0The |Sec-WebSocket-Extensions| header is used in the WebSocket
=C2=A0 handshake. =C2=A0It is initially sent from the client to the server= , and
=C2=A0 then subsequently sent from the servver to the client, to agree on = a
=C2=A0 set of protocol-level extensions to use during the connection.
10.6. =C2=A0Sec-WebSocket-Accept
=C2=A0This section describes a header field for registration in the
=C2=A0 Permanent Message Header Field Registry. =C2=A0[RFC3864]
=C2=A0Header field name
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Accept
=C2=A0Applicable protocol
=C2=A0 =C2=A0 =C2=A0http
=C2=A0Status
=C2=A0 =C2=A0 =C2=A0reserved; do not use outside WebSocket handshake
=C2=A0Author/Change controller
=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0Specification document(s)
=C2=A0 =C2=A0 =C2=A0This document is the relevant specification.
=C2=A0Related information
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0The |Sec-WebSocket-Accept| header is used in the WebSocket handshake= .
=C2=A0 It is sent from the server to the client to confirm that the server=
=C2=A0 is willing to initiate the connection.
10.7. =C2=A0Sec-WebSocket-Origin
=C2=A0This section describes a header field for registration in the
=C2=A0 Permanent Message Header Field Registry. =C2=A0[RFC3864]
=C2=A0Header field name
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Origin
=C2=A0Applicable protocol
=C2=A0 =C2=A0 =C2=A0http
=C2=A0Status
=C2=A0 =C2=A0 =C2=A0reserved; do not use outside WebSocket handshake
=C2=A0Author/Change controller
=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0Specification document(s)
=C2=A0 =C2=A0 =C2=A0This document is the relevant specification.
=C2=A0Related information
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0The |Sec-WebSocket-Origin| header is used in the WebSocket handshake= .
=C2=A0 It is sent from the server to the client to confirm the origin of t= he
=C2=A0 script that opened the connection. =C2=A0This enables user agents t= o
=C2=A0 verify that the server is willing to serve the script that opened t= he
=C2=A0 connection.
10.8. =C2=A0Sec-WebSocket-Protocol
=C2=A0This section describes a header field for registration in the
=C2=A0 Permanent Message Header Field Registry. =C2=A0[RFC3864]
=C2=A0Header field name
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Protocol
=C2=A0Applicable protocol
=C2=A0 =C2=A0 =C2=A0http
=C2=A0Status
=C2=A0 =C2=A0 =C2=A0reserved; do not use outside WebSocket handshake
=C2=A0Author/Change controller
=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0Specification document(s)
=C2=A0 =C2=A0 =C2=A0This document is the relevant specification.
=C2=A0Related information
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0The |Sec-WebSocket-Protocol| header is used in the WebSocket
=C2=A0 handshake. =C2=A0It is sent from the client to the server and back = from
=C2=A0 the server to the client to confirm the subprotocol of the
=C2=A0 connection. =C2=A0This enables scripts to both select a subprotocol= and be
=C2=A0 sure that the server agreed to serve that subprotocol.
10.9. =C2=A0Sec-WebSocket-Version
=C2=A0This section describes a header field for registration in the
=C2=A0 Permanent Message Header Field Registry. =C2=A0[RFC3864]
=C2=A0Header field name
=C2=A0 =C2=A0 =C2=A0Sec-WebSocket-Version
=C2=A0Applicable protocol
=C2=A0 =C2=A0 =C2=A0http
=C2=A0Status
=C2=A0 =C2=A0 =C2=A0reserved; do not use outside WebSocket handshake
=C2=A0Author/Change controller
=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0Specification document(s)
=C2=A0 =C2=A0 =C2=A0This document is the relevant specification.
=C2=A0Related information
=C2=A0 =C2=A0 =C2=A0None.
=C2=A0The |Sec-WebSocket-Version| header is used in the WebSocket
=C2=A0 handshake. =C2=A0It is sent from the client to the server to indica= te the
=C2=A0 protocol version of the connection. =C2=A0This enables servers to =C2=A0 correctly interpret the handshake and subsequent data being sent fr= om
=C2=A0 the data, and close the connection if the server cannot interpret =C2=A0 that data in a safe manner.
11. =C2=A0Using the WebSocket protocol from other specifications
=C2=A0The WebSocket protocol is intended to be used by another
=C2=A0 specification to provide a generic mechanism for dynamic author- =C2=A0 defined content, e.g. in a specification defining a scripted API. =C2=A0Such a specification first needs to "establish a WebSocket
=C2=A0 connection", providing that algorithm with:
=C2=A0o =C2=A0The destination, consisting of a /host/ and a /port/.
=C2=A0o =C2=A0A /resource name/, which allows for multiple services to be<= br> =C2=A0 =C2=A0 =C2=A0identified at one host and port.
=C2=A0o =C2=A0A /secure/ flag, which is true if the connection is to be =C2=A0 =C2=A0 =C2=A0encrypted, and false otherwise.
=C2=A0o =C2=A0An ASCII serialization of an origin that is being made respo= nsible
=C2=A0 =C2=A0 =C2=A0for the connection. =C2=A0[I-D.ietf-websec-origin]
=C2=A0o =C2=A0Optionally a string identifying a protocol that is to be lay= ered
=C2=A0 =C2=A0 =C2=A0over the WebSocket connection.
=C2=A0The /host/, /port/, /resource name/, and /secure/ flag are usually =C2=A0 obtained from a URI using the steps to parse a WebSocket URI's<= br> =C2=A0 components. =C2=A0These steps fail if the URI does not specify a =C2=A0 WebSocket.
=C2=A0If a connection can be established, then it is said that the
=C2=A0 "WebSocket connection is established".
=C2=A0If at any time the connection is to be closed, then the specificatio= n
=C2=A0 needs to use the "close the WebSocket connection" algorit= hm.
=C2=A0When the connection is closed, for any reason including failure to =C2=A0 establish the connection in the first place, it is said that the =C2=A0 "WebSocket connection is closed".
=C2=A0While a connection is open, the specification will need to handle th= e
=C2=A0 cases when "a WebSocket message has been received" with t= ext /data/.
=C2=A0To send some text /data/ to an open connection, the specification =C2=A0 needs to "send /data/ using the WebSocket".

--
Simon Pieters
Opera Software
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016364184ff038cd304a17803e2-- From simonp@opera.com Fri Apr 22 01:44:49 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7B141E0697 for ; Fri, 22 Apr 2011 01:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.149 X-Spam-Level: X-Spam-Status: No, score=-7.149 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqMrMy9BIrFY for ; Fri, 22 Apr 2011 01:44:42 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfc.amsl.com (Postfix) with ESMTP id EDFC6E0692 for ; Fri, 22 Apr 2011 01:44:41 -0700 (PDT) Received: from simon-pieterss-macbook.local (c-039ee355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.158.3]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3M8iWb6029181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2011 08:44:33 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= References: Date: Fri, 22 Apr 2011 10:44:34 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.10 (MacIntel) Cc: "hybi@ietf.org" Subject: Re: [hybi] Opera's Pre-Last Call review of websocket -06 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 08:44:49 -0000 Thank you. Initial responses below. I have not reviewed the spec changes yet. Added Hixie to cc; some discussion about the WebSocket API spec below. On Fri, 22 Apr 2011 03:45:25 +0200, Ian Fette (イアンフェッティ) wrote: > On Mon, Apr 4, 2011 at 5:42 AM, Simon Pieters wrote: > >> Hi, >> >> We have reviewed >> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 >> >> The introduction section is non-normative but has a number of MUSTs. >> Please >> don't have any requirements in the introduction. >> > > I have ensured that normative requirements are now consistently upper > case. > There are no upper case MUSTs left in the non-normative introduction in > the > draf that will be 07. > > >> >> Why was Sec-WebSocket-Location removed? >> > > > It is now redundant given that there's a path specified in the get > request. It was a *response* header, not a request header. > >> >> The spec does not define "WebSocket connection is established", "a >> WebSocket message has been received", "a WebSocket error has been >> detected", >> "the WebSocket closing handshake has started", which means that the API >> spec's hooks don't work and you would never get any 'open', 'message' or >> 'error' events. >> > > I will have to take a look at this with Hixie, there also need to be some > changes to the HTML spec that we've discussed (e.g. adding binary). I > will > consult with him to make sure the appropriate hooks are present. > > >> >> Should probably have some text about when pings may be sent. >> > > > Added "An endpoint MAY send a Ping message any time after the connection > is established and before the connection is closed. NOTE: A > ping > message may serve either as a keepalive, or to verify that the > remote endpoint is still responsive." > > >> >> Should better cover error handling, e.g. what should happen when the >> high >> bit is set on the 63-bit length, what happens when the RSV bits are set, >> what should happen when FIN is set but opcode is 0x00, or a control >> frame is >> fragmented or has length greater than 125? I'd prefer detailed >> algorithms >> that covered every possible case, so that it is easy to argue that all >> cases >> are covered and so that it is clear when to fire relevant events and how >> many, etc. Just having a list with cases that are 'errors' does not >> make it >> clear when the error is to be detected or what should be done when >> multiple >> error cases match. >> > > We added a section on error codes for Close frames, that said I did want > to > leave a bit of flexibility for implementors to provide more specific > errors. > There are a few areas where I explicitly said an endpoint MAY send the > following error code, I don't know if we should say MUST for each > possible > error? Frankly, most of them are likely to just be 1002 Protocol Error, > and > unrecoverable and useless to a developer beyond the fact a protocol error > occurred. Not all error handling need to result in a close frame. In -00, a bogus/unsupported frame sent to the client would result in 'a WebSocket error has been detected', which keeps the connection open but fires an 'error' event on the WebSocket object in the WebSocket API. As a browser vendor, I do *not* want any flexibility in what to do with error conditions. I want all possible cases to have a specified correct behavior (even if that is "do nothing" if that's appropriate), because experience suggests that on the Web, people will do everything that is not impossible to do and rely on the behavior of the browser that the author cared to test in. Not specifying error handling thus has a higher cost for browser vendors in the form of reverse engineering other browsers' error handling and never quite getting the same behavior (until it is properly specified). Please specify correct behavior for clients (or at least browser clients) for all possible cases. > > >> >> >> 2. Conformance requirements >>> All diagrams, examples, and notes in this specification are non- >>> normative, as are all sections explicitly marked non-normative. >>> Everything else in this specification is normative. >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", >>> "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this >>> document are to be interpreted as described in RFC2119. For >>> readability, these words do not appear in all uppercase letters in >>> this specification. [RFC2119] >>> >> >> It seems this specification uses a mix of lowercase and all uppercase. >> > > Fixed. > > > >> >> Requirements phrased in the imperative as part of algorithms (such as >>> "strip any leading space characters" or "return false and abort these >>> steps") are to be interpreted with the meaning of the key word >>> ("must", "should", "may", etc) used in introducing the algorithm. >>> Conformance requirements phrased as algorithms or specific steps may >>> be implemented in any manner, so long as the end result is >>> equivalent. (In particular, the algorithms defined in this >>> specification are intended to be easy to follow, and not intended to >>> be performant.) >>> Implementations may impose implementation-specific limits on >>> otherwise unconstrained inputs, e.g. to prevent denial of service >>> attacks, to guard against running out of memory, or to work around >>> platform-specific limitations. >>> The conformance classes defined by this specification are user agents >>> and servers. >>> 2.1. Terminology >>> *ASCII* shall mean the character-encoding scheme defined in >>> [ANSI.X3-4.1986]. >>> *Converting a string to ASCII lowercase* means replacing all >>> characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER >>> A to LATIN CAPITAL LETTER Z) with the corresponding characters in the >>> range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL >>> LETTER Z). >>> Comparing two strings in an *ASCII case-insensitive* manner means >>> comparing them exactly, code point for code point, except that the >>> characters in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER >>> A to LATIN CAPITAL LETTER Z) and the corresponding characters in the >>> range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL >>> LETTER Z) are considered to also match. >>> The term "URI" is used in this section in a manner consistent with >>> the terminology used in HTML, namely, to denote a string that might >>> or might not be a valid URI or IRI and to which certain error >>> handling behaviors will be applied when the string is parsed. >>> [RFC3986] >>> >> >> HTML calls it "URL", so doesn't seem particularly consistent. >> > > I have been chastised to use IRI and URI consistently. > > > >> >> When an implementation is required to _send_ data as part of the >>> WebSocket protocol, the implementation may delay the actual >>> transmission arbitrarily, e.g. buffering data so as to send fewer IP >>> packets. >>> 3. WebSocket URIs >>> 3.1. Parsing WebSocket URIs >>> The steps to *parse a WebSocket URI's components* from a string /uri/ >>> are as follows. These steps return either a /host/, a /port/, a >>> /resource name/, and a /secure/ flag, or they fail. >>> 1. If the /uri/ string is not an absolute URI, then fail this >>> algorithm. [RFC3986] [RFC3987] >>> 2. Resolve the /uri/ string using the resolve a Web address >>> algorithm defined by the Web addresses specification, with the >>> URI character encoding set to UTF-8. [RFC3629] [RFC3986] >>> [RFC3987] >>> NOTE: It doesn't matter what it is resolved relative to, since >>> we already know it is an absolute URI at this point. >>> 3. If /uri/ does not have a component whose value, when >>> converted to ASCII lowercase, is either "ws" or "wss", then fail >>> this algorithm. >>> 4. If /uri/ has a component, then fail this algorithm. >>> 5. If the component of /uri/ is "ws", set /secure/ to >>> false; otherwise, if the component is "wss", set >>> /secure/ to true; otherwise, fail this algorithm. >>> >> >> We already know it's either "ws" or "wss", so this can't fail. >> > > > True, but it doesn't seem to hurt... I disagree. Having no-op steps in the spec wastes time for implementors because they either spend time implementing dead code or spend time realizing that it is a no-op step and inform the WG about the spec bug. Or worse, if it seems to be no-op but is actually subtly different, it can lead to interop problems if some implementors think it's no-op and don't implement it. > >> >> 6. Let /host/ be the value of the component of /uri/, >>> converted to ASCII lowercase. >>> 7. If /uri/ has a component, then let /port/ be that >>> component's value; otherwise, there is no explicit /port/. >>> 8. If there is no explicit /port/, then: if /secure/ is false, let >>> /port/ be 80, otherwise let /port/ be 443. >>> 9. Let /resource name/ be the value of the component (which >>> might be empty) of /uri/. >>> 10. If /resource name/ is the empty string, set it to a single >>> character U+002F SOLIDUS (/). >>> 11. If /uri/ has a component, then append a single U+003F >>> QUESTION MARK character (?) to /resource name/, followed by the >>> value of the component. >>> 12. Return /host/, /port/, /resource name/, and /secure/. >>> 3.2. Constructing WebSocket URIs >>> The steps to *construct a WebSocket URI* from a /host/, a /port/, a >>> /resource name/, and a /secure/ flag, are as follows: >>> 1. Let /uri/ be the empty string. >>> 2. If the /secure/ flag is false, then append the string "ws://" to >>> /uri/. Otherwise, append the string "wss://" to /uri/. >>> 3. Append /host/ to /uri/. >>> 4. If the /secure/ flag is false and port is not 80, or if the >>> /secure/ flag is true and port is not 443, then append the string >>> ":" followed by /port/ to /uri/. >>> 5. Append /resource name/ to /uri/. >>> 6. Return /uri/. >>> 3.3. Valid WebSocket URIs >>> For a WebSocket URI to be considered valid, the following conditions >>> MUST hold. >>> o The /host/ must be ASCII-only (i.e. it must have been punycode- >>> encoded already if necessary, and MUST NOT contain any characters >>> above U+007E). >>> o The /resource name/ string must be a non-empty string of >>> characters in the range U+0021 to U+007E that starts with a U+002F >>> SOLIDUS character (/). >>> Any WebSocket URIs not meeting the above criteria are considered >>> invalid, and a client MUST NOT attempt to make a connection to an >>> invalid WebSocket URI. A client SHOULD attempt to parse a URI >>> obtained from any external source (such as a web site or a user) >>> using the steps specified in Section 3.1 to obtain a valid WebSocket >>> URI, but MUST NOT attempt to connect with such an unparsed URI, and >>> instead only use the parsed version and only if that version is >>> considered valid by the criteria above. >>> 4. Data Framing >>> 4.1. Overview >>> In the WebSocket protocol, data is transmitted using a sequence of >>> frames. Frames sent from the client to the server are masked to >>> avoid confusing network intermediaries, such as intercepting proxies. >>> Frames sent from the server to the client are not masked. >>> The base framing protocol defines a frame type with an opcode, a >>> payload length, and designated locations for extension and >>> application data, which together define the _payload_ data. Certain >>> bits and opcodes are reserved for future expansion of the protocol. >>> As such, In the absence of extensions negotiated during the opening >>> handshake (Section 5), all reserved bits MUST be 0 and reserved >>> opcode values MUST NOT be used. >>> A data frame MAY be transmitted by either the client or the server at >>> any time after handshake completion and before that endpoint has sent >>> a close message (Section 4.5.1). >>> 4.2. Client-to-Server Masking >>> The client MUST mask all frames sent to the server. >>> The masking-key is contained completely within the frame. >>> The masking-key is a 32-bit value chosen at random by the client. >>> The masking-key MUST be derived from a strong source of entropy, and >>> the masking-key for a given frame MUST NOT make it simple for a >>> server to predict the masking-key for a subsequent frame. >>> Each masked frame consists of a 32-bit masking-key followed by >>> masked-data: >>> masked-frame = masking-key masked-data >>> masking-key = 4full-octet >>> masked-data = *full-octet >>> full-octet = %x00-FF >>> The masked-data is the clear-text frame "encrypted" using a simple >>> XOR cipher as follows. >>> Octet i of the masked-data is the XOR of octet i of the clear text >>> frame with octet i modulo 4 of the masking-key: >>> j = i MOD 4 >>> masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key >>> When preparing a masked-frame, the client MUST pick a fresh masking- >>> key uniformly at random from the set of allowed 32-bit values. The >>> unpredictability of the masking-nonce is essential to prevent the >>> author of malicious application data from selecting the bytes that >>> appear on the wire. >>> 4.3. Base Framing Protocol >>> This wire format for the data transfer part is described by the ABNF >>> given in detail in this section. A high level overview of the >>> framing is given in the following figure. [RFC5234] >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-------+-+-------------+-------------------------------+ >>> |F|R|R|R| opcode|R| Payload len | Extended payload length | >>> |I|S|S|S| (4) |S| (7) | (16/63) | >>> |N|V|V|V| |V| | (if payload len==126/127) | >>> | |1|2|3| |4| | | >>> +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + >>> | Extended payload length continued, if payload len == 127 | >>> + - - - - - - - - - - - - - - - +-------------------------------+ >>> | | Extension data | >>> +-------------------------------+ - - - - - - - - - - - - - - - + >>> : : >>> +---------------------------------------------------------------+ >>> : Application data : >>> +---------------------------------------------------------------+ >>> FIN: 1 bit >>> Indicates that this is the final fragment in a message. The first >>> fragment may also be the final fragment. >>> RSV1, RSV2, RSV3, RSV4: 1 bit each >>> Must be 0 unless an extension is negotiated which defines meanings >>> for non-zero values >>> Opcode: 4 bits >>> Defines the interpretation of the payload data >>> Payload length: 7 bits >>> The length of the payload: if 0-125, that is the payload length. >>> If 126, the following 2 bytes interpreted as a 16 bit unsigned >>> integer are the payload length. If 127, the following 8 bytes >>> interpreted as a 64-bit unsigned integer (the high bit must be 0) >>> are the payload length. Multibyte length quantities are expressed >>> in network byte order. The payload length is the length of the >>> Extension data + the length of the Application Data. The length >>> of the Extension data may be zero, in which case the Payload >>> length is the length of the Application data. >>> Extension data: n bytes >>> The extension data is 0 bytes unless there is a reserved op-code >>> or reserved bit present in the frame which indicates an extension >>> has been negotiated. Any extension MUST specify the length of the >>> extension data, or how that length may be calculated, and its use >>> MUST be negotiated during the handshake. If present, the >>> extension data is included in the total payload length. >>> Application data: n bytes >>> Arbitrary application data, taking up the remainder of the frame >>> after any extension data. The length of the Application data is >>> equal to the payload length minus the length of the Extension >>> data. >>> The base framing protocol is formally defined by the following ABNF >>> [RFC5234]: >>> ws-frame = frame-fin >>> frame-rsv1 >>> frame-rsv2 >>> frame-rsv3 >>> frame-opcode >>> frame-rsv4 >>> frame-length >>> frame-extension >>> application-data; >>> frame-fin = %x0 ; more frames of this message follow >>> / %x1 ; final frame of message >>> frame-rsv1 = %x0 ; 1 bit, must be 0 >>> frame-rsv2 = %x0 ; 1 bit, must be 0 >>> frame-rsv3 = %x0 ; 1 bit, must be 0 >>> frame-opcode = %x0 ; continuation frame >>> / %x1 ; connection close >>> / %x2 ; ping >>> / %x3 ; pong >>> / %x4 ; text frame >>> / %x5 ; binary frame >>> / %x6-F ; reserved >>> frame-rsv4 = %x0 ; 1 bit, must be 0 >>> frame-length = %x00-7D >>> / %x7E frame-length-16 >>> / %x7F frame-length-63 >>> frame-length-16 = %x0000-FFFF >>> frame-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF >>> frame-extension = *( %x00-FF ) ; to be defined later >>> application-data = *( %x00-FF ) >>> 4.4. Fragmentation >>> The primary purpose of fragmentation is to allow sending a message >>> that is of unknown size when the message is started without having to >>> buffer that message. If messages couldn't be fragmented, then an >>> endpoint would have to buffer the entire message so its length could >>> be counted before first byte is sent. With fragmentation, a server >>> or intermediary may choose a reasonable size buffer, and when the >>> buffer is full write a fragment to the network. >>> A secondary use-case for fragmentation is for multiplexing, where it >>> is not desirable for a large message on one logical channel to >>> monopolize the output channel, so the MUX needs to be free to split >>> the message into smaller fragments to better share the output >>> channel. >>> The following rules apply to fragmentation: >>> o An unfragmented message consists of a single frame with the FIN >>> bit set and an opcode other than 0. >>> o A fragmented message consists of a single frame with the FIN bit >>> clear and an opcode other than 0, followed by zero or more frames >>> with the FIN bit clear and the opcode set to 0, and terminated by >>> a single frame with the FIN bit set and an opcode of 0. Its >>> content is the concatenation of the application data from each of >>> those frames in order. As an example, for a text message sent as >>> three fragments, the first fragment would have an opcode of 0x4 >>> and a FIN bit clear, the second fragment would have an opcode of >>> 0x0 and a FIN bit clear, and the third fragment would have an >>> opcode of 0x0 and a FIN bit that is set. >>> o Control frames MAY be injected in the middle of a fragmented >>> message. Control frames themselves MUST NOT be fragmented. _Note: >>> if control frames could not be interjected, the latency of a ping, >>> for example, would be very long if behind a large message. As >>> such, an endpoint MUST be capable of handling control frames in >>> the middle of a fragmented message._ >>> >> >> Please don't have MUSTs inside notes, since the conformance section >> says notes are non-normative. >> > > > fixed > > >> >> o A sender MAY create fragments of any size for non control >>> messages. >>> o Clients and servers MUST support receiving both fragmented and >>> unfragmented messages. >>> o An intermediary MAY change the fragmentation of a message if the >>> message uses only opcode and reserved bit values known to the >>> intermediary. >>> o As a consequence of these rules, all fragments of a message are of >>> the same type, as set by the first fragment's opcode. Since >>> Control frames cannot be fragmented, the type for all fragments in >>> a message MUST be either text or binary, or one of the reserved >>> opcodes. >>> 4.5. Control Frames >>> Control frames have opcodes of 0x01 (Close), 0x02 (Ping), or 0x03 >>> (Pong). Control frames are used to communicate state about the >>> websocket. Control frames can be interjected in the middle of a >>> fragmented message. >>> All control frames MUST be 125 bytes or less in length and MUST NOT >>> be fragmented. >>> 4.5.1. Close >>> The Close message contains an opcode of 0x01. >>> The Close message MAY contain a body (the "application data" portion >>> of the frame) that indicates a reason for closing, such as an >>> endpoint shutting down, an endpoint having received a message too >>> large, or an endpoint having received a message that does not conform >>> to the format expected by the other endpoint. If there is a body, >>> the first two bytes of the body MUST be a 2-byte integer (in network >>> byte order) representing a status code defined in Section 7.4. >>> Following the 2-byte integer the body MAY contain UTF-8 encoded data, >>> the interpretation of which is not defined by this specification. >>> The application MUST NOT send any more data messages after sending a >>> close message. >>> >> >> What are 'data messages'? I see data frames, but not data messages. Are >> control frames allowed to be sent after close? >> > > > Changed to be data frames. Control frames I believe should still be > allowed. > Let's say you send a close frame and don't get a response, perhaps you > try > again? Though I don't feel especially strongly here. I think nothing should be allowed to be sent after sending a close frame. If you don't get a response in a UA-defined timeout, you should just close the connection. > >> >> If an endpoint receives a Close message and that endpoint did not >>> previously send a Close message, the endpoint MUST send a Close >>> message in response. It SHOULD do so as soon as is practical. >>> After both sending and receiving a close message, an endpoint >>> considers the websocket connection closed, and SHOULD close the >>> underlying TCP connection. >>> If a client and server both send a Close message at the same time, >>> both endpoints will have sent and received a Close message and should >>> consider the websocket connection closed and close the underlying TCP >>> connection. >>> 4.5.2. Ping >>> The Ping message contains an opcode of 0x02. >>> Upon receipt of a Ping message, an endpoint MUST send a Pong message >>> in response. It SHOULD do so as soon as is practical. The message >>> bodies of the Ping and Pong MUST be the same. >>> 4.5.3. Pong >>> The Pong message contains an opcode of 0x03. >>> Upon receipt of a Ping message, an endpoint MUST send a Pong message >>> in response. It SHOULD do so as soon as is practical. The message >>> bodies of the Ping and Pong MUST be the same. A Pong is issued only >>> in response to the most recent Ping. >>> >> >> This text is identical to the text in the previous section, except for >> the last sentence. I suggest stating the requirements only once, and >> making the last sentence normative by including a MUST. >> > > > In the latest draft there are some differences. fixed re: the last > sentence. > > >> >> 4.6. Data Frames >>> All frame types not listed in Section 4.5 are data frames, which >>> transport application-layer data. The opcode determines the >>> interpretation of the application data: >>> Text >>> The payload data is text data encoded as UTF-8. >>> Binary >>> The payload data is arbitrary binary data whose interpretation is >>> solely up to the application layer. >>> 4.7. Examples >>> _This section is non-normative._ >>> o A single-frame text message >>> * 0x84 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello") >>> o A fragmented text message >>> * 0x04 0x03 0x48 0x65 0x6c (contains "Hel") >>> * 0x80 0x02 0x6c 0x6f (contains "lo") >>> o Ping request and response >>> * 0x82 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", >>> but the contents of the body are arbitrary) >>> * 0x83 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", >>> matching the body of the ping) >>> o 256 bytes binary message in a single frame >>> * 0x85 0x7E 0x0100 [256 bytes of binary data] >>> o 64KiB binary message in a single frame >>> * 0x85 0x7F 0x0000000000010000 [65536 bytes of binary data] >>> 4.8. Extensibility >>> The protocol is designed to allow for extensions, which will add >>> capabilities to the base protocols. The endpoints of a connection >>> MUST negotiate the use of any extensions during the handshake. This >>> specification provides opcodes 0x6 through 0xF, the extension data >>> field, and the frame-rsv1, frame-rsv2, frame-rsv3, and frame-rsv4 >>> bits of the frame header for use by extensions. The negotiation of >>> extensions is discussed in further detail in Section 8.1. Below are >>> some anticipated uses of extensions. This list is neither complete >>> nor proscriptive. >>> o Extension data may be placed in the payload before the application >>> data. >>> o Reserved bits can be allocated for per-frame needs. >>> o Reserved opcode values can be defined. >>> o Reserved bits can be allocated to the opcode field if more opcode >>> values are needed. >>> o A reserved bit or an "extension" opcode can be defined which >>> allocates additional bits out of the payload area to define larger >>> opcodes or more per-frame bits. >>> 5. Opening Handshake >>> 5.1. Client Requirements >>> User agents running in controlled environments, e.g. browsers on >>> mobile handsets tied to specific carriers, may offload the management >>> of the connection to another agent on the network. In such a >>> situation, the user agent for the purposes of conformance is >>> considered to include both the handset software and any such agents. >>> When the user agent is to *establish a WebSocket connection* to a >>> WebSocket URI /uri/, it must meet the following requirements. In the >>> following text, we will use terms from Section 3 such as "/host/" and >>> "/secure/ flag" as defined in that section. >>> >> >> Section 11 says that specifications are to feed this algorithm with >> /host/, /port/, /resource name/, /secure/, /origin/ and /subprotocol/. >> Not /uri/. The WebSocket API invokes this algorithm in accordance with >> section 11. Please make this text closer to what it is in -00. >> > > > I have tried to address this by essentially saying the algorithm can be > invoked with a URI when then the algorithms in section 3 are invoked to > break down that URI, or the algorithm can be invoked by passing in the > parameters specified in section 11. I think it results in the same net > effect and is somewhat cleaner. > > >> >> Actually the WebSocket API also has a /defer cookies/ flag. It seems >> this has not been incorporated into the spec, or has been dropped at >> some point. Please take in the defer cookies stuff from >> http://www.whatwg.org/specs/web-socket-protocol/ (the opening paragraph >> in section 5, step 46 and 47 in the algorithm, and the *apply the >> cookies* definition. >> > > > There are a few hooks that are not consistent, /defer cookies/ was one of > them. I need to sit down with Hixie as part of review and iron these > out. I > don't think reviving /defer cookies/ would be sufficient. > > > > > >> >> 1. The WebSocket URI and its components MUST be valid according to >>> Section 3.3. If any of the requirements are not met, the client >>> MUST fail the WebSocket connection and abort these steps. >>> >> >> Checking this is the responsibility of the API spec, by invoking "parse >> a WebSocket URI's components" defined in this specification. If it >> fails to parse, this algorithm is not invoked to begin with. >> > > The API spec is not necessarily the only thing that could use the > protocol. > I don't see harm in leaving this in. Ok, I guess the step doesn't apply if the algorithm is invoked with the other parameters instead of a URI. > >> >> 2. If the user agent already has a WebSocket connection to the >>> remote host (IP address) identified by /host/, even if known by >>> another name, the user agent MUST wait until that connection has >>> been established or for that connection to have failed. There >>> MUST be no more than one connection in a CONNECTING state. If >>> >> >> Regardless of host? So we serialize tabs as well? >> > > I'm not sure I understand what you mean by serializing tabs? The intent > was > that if a.com resolves to 1.2.3.4 and b.com also resolves to 1.2.3.4, a > connection to b.com should wait while a connection to a.com is > establishing. > > >> >> multiple connections to the same IP address are attempted >>> simultaneously, the user agent MUST serialize them so that there >>> is no more than one connection at a time running through the >>> following steps. >>> If the user agent cannot determine the IP address of the remote >>> host (for example because all communication is being done through >>> a proxy server that performs DNS queries itself), then the user >>> agent MUST assume for the purposes of this step that each host >>> name refers to a distinct remote host, but should instead limit >>> the total number of simultaneous connections that are not >>> established to a reasonably low number (e.g., in a Web browser, >>> to the number of tabs the user has open). >>> NOTE: This makes it harder for a script to perform a denial of >>> service attack by just opening a large number of WebSocket >>> connections to a remote host. A server can further reduce the >>> load on itself when attacked by making use of this by pausing >>> before closing the connection, as that will reduce the rate at >>> which the client reconnects. >>> NOTE: There is no limit to the number of established WebSocket >>> connections a user agent can have with a single remote host. >>> >> >> No upper limit? >> > > correct > > > >> >> Servers can refuse to connect users with an excessive number of >>> connections, or disconnect resource-hogging users when suffering >>> high load. >>> 3. _Proxy Usage_: If the user agent is configured to use a proxy >>> when using the WebSocket protocol to connect to host /host/ >>> and/or port /port/, then the user agent SHOULD connect to that >>> proxy and ask it to open a TCP connection to the host given by >>> /host/ and the port given by /port/. >>> EXAMPLE: For example, if the user agent uses an HTTP proxy for >>> all traffic, then if it was to try to connect to port 80 on >>> server example.com, it might send the following lines to the >>> proxy server: >>> CONNECT example.com:80 HTTP/1.1 >>> Host: example.com >>> If there was a password, the connection might look like: >>> CONNECT example.com:80 HTTP/1.1 >>> Host: example.com >>> Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= >>> If the user agent is not configured to use a proxy, then a direct >>> TCP connection SHOULD be opened to the host given by /host/ and >>> the port given by /port/. >>> NOTE: Implementations that do not expose explicit UI for >>> selecting a proxy for WebSocket connections separate from other >>> proxies are encouraged to use a SOCKS proxy for WebSocket >>> connections, if available, or failing that, to prefer the proxy >>> configured for HTTPS connections over the proxy configured for >>> HTTP connections. >>> For the purpose of proxy autoconfiguration scripts, the URI to >>> pass the function must be constructed from /host/, /port/, >>> /resource name/, and the /secure/ flag using the steps to >>> construct a WebSocket URI. >>> NOTE: The WebSocket protocol can be identified in proxy >>> autoconfiguration scripts from the scheme ("ws:" for unencrypted >>> connections and "wss:" for encrypted connections). >>> 4. If the connection could not be opened, either because a direct >>> connection failed or because any proxy used returned an error, >>> then the user agent MUST fail the WebSocket connection and abort >>> the connection attempt. >>> 5. If /secure/ is true, the user agent MUST perform a TLS handshake >>> over the connection. If this fails (e.g. the server's >>> certificate could not be verified), then the user agent MUST fail >>> >> >> What about popping open a dialogue if the cert is self signed? >> > > > I think that's up to the UA. The protocol doesn't specify how the > certificate is verified. If verifying it involves displaying a prompt to > the > user, that is IMO at the discretion of the UA.. > > >> >> the WebSocket connection and abort the connection. Otherwise, >>> all further communication on this channel MUST run through the >>> encrypted tunnel. [RFC2246] >>> User agents MUST use the Server Name Indication extension in the >>> TLS handshake. [RFC4366] >>> Once a connection to the server has been established (including a >>> connection via a proxy or over a TLS-encrypted tunnel), the client >>> MUST send a handshake to the server. The handshake consists of an >>> HTTP upgrade request, along with a list of required and optional >>> headers. The requirements for this handshake are as follows. >>> 1. The handshake must be a valid HTTP request as specified by >>> [RFC2616]. >>> 2. The Method of the request MUST be GET and the HTTP version MUST >>> be at least 1.1. >>> For example, if the WebSocket URI is "ws://example.com/chat", >>> The first line sent SHOULD be "GET /chat HTTP/1.1" >>> >> >> Please don't use SHOULD in an example, since examples are non-normative. >> > > made lower case > > >> >> 3. The request must contain a "Request-URI" as part of the GET >>> method. This MUST match the /resource name/ Section 3. >>> 4. The request MUST contain a "Host" header whose value is equal to >>> the authority component of the WebSocket URI. >>> >> >> Make it equal to /host/ since parsing a WebSocket URI's components will >> convert it to lowercase. >> > > done > > > >> >> 5. The request MUST contain an "Upgrade" header whose value is >>> equal to "websocket". >>> 6. The request MUST contain a "Connection" header whose value MUST >>> include the "Upgrade" token. >>> 7. The request MUST include a header with the name "Sec-WebSocket- >>> Key". The value of this header MUST be a nonce consisting of a >>> randomly selected 16-byte value that has been base64-encoded >>> [RFC3548]. The nonce MUST be randomly selected randomly for >>> each connection. >>> >> >> Double randomly. >> > > fixed ;-) > > > >> >> NOTE: As an example, if the randomly selected value was the >>> sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 >>> 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header >>> would be "AQIDBAUGBwgJCgsMDQ4PEC==" >>> 8. The request MUST include a header with the name "Sec-WebSocket- >>> Origin" if the request is coming from a browser client. If the >>> >> >> Maybe the conformance section should have different conformance classes >> for browesr clients and non-browser clients. >> > > > I'm not going to touch this one late in the game. How strongly do you > feel? Well the spec effectively has different conformance classes for browser clients and non-browser clients already, it just isn't up-front about it in the Conformance section. I'm not going to whine about it further, though. > >> >> connection is from a non-browser client, the request MAY include >>> this header if the semantics of that client match the use-case >>> described here for browser clients. The value of this header >>> MUST be the ASCII serialization of origin of the context in >>> which the code establishing the connection is running, and MUST >>> be lower-case. The value MUST NOT contain letters in the range >>> U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL >>> LETTER Z) [I-D.ietf-websec-origin]. >>> As an example, if code is running on www.example.com attempting >>> to establish a connection to ww2.example.com, the value of the >>> header would be "http://www.example.com". >>> 9. The request MUST include a header with the name "Sec-WebSocket- >>> Version". The value of this header must be 6. >>> 10. The request MAY include a header with the name "Sec-WebSocket- >>> Protocol". If present, this value indicates the subprotocol(s) >>> the client wishes to speak. The elements that comprise this >>> value MUST be non-empty strings with characters in the range >>> U+0021 to U+007E and MUST all be unique. The ABNF for the value >>> >> >> and MUST all be unique strings. (just to make sure you don't think the >> characters must be unique) >> > > done > > >> >> of this header is 1#(token | quoted-string), where the >>> definitions of constructs and rules are as given in [RFC2616]. >>> >> >> I'd like this to say that, at least for browser clients, if the >> algorithm was invoked with a non-empty list of /subprotocols/ then the >> header MUST be included, with the values of /subprotocols/ joined by a >> comma and a space, and otherwise MUST NOT be included. Otherwise a >> browser would be conforming for requesting subprotocols at random. >> > > It seems like that should be in the API requirement, not the protocol > requirement? I think it belongs in the protocol spec. But if you disagree then I'm fine with asking Hixie to add it to the API spec instead. > >> >> 11. The request MAY include a header with the name "Sec-WebSocket- >>> Extensions". If present, this value indicates the protocol- >>> level extension(s) the client wishes to speak. The >>> interpretation and format of this header is described in >>> Section 8.1. >>> 12. The request MAY include headers associated with sending cookies, >>> as defined by the appropriate specifications >>> [I-D.ietf-httpstate-cookie]. >>> >> >> Any cookies at random? I'd like, at least for browser clients, for this >> to be tighter, as it was in -00. >> > > again, i need to sync with hixie on the cross-spec hooks. > > > >> >> Once the client's opening handshake has been sent, the client MUST >>> wait for a response from the server before sending any further data. >>> The client MUST validate the server's response as follows: >>> o If the status code received from the server is not 101, the client >>> MUST fail the WebSocket connection. >>> o If the response lacks an Upgrade header or the Upgrade header >>> contains a value that is not an ASCII case-insensitive match for >>> the value "websocket", the client MUST fail the WebSocket >>> connection. >>> o If the response lacks a Connection header or the Connection header >>> contains a value that is not an ASCII case-insensitive match for >>> the value "Upgrade", the client MUST fail the WebSocket >>> connection. >>> o If the response lacks a Sec-WebSocket-Accept header or the Sec- >>> WebSocket-Accept contains a value other than the base64-encoded >>> SHA-1 of the concatenation of the Sec-WebSocket-Key (as a string, >>> not base64-decoded) with the string "258EAFA5-E914-47DA-95CA- >>> C5AB0DC85B11", the client MUST fail the WebSocket connection. >>> >> >> -00 had rules for failing the websocket connection if the response had >> certain other errors, like the wrong type of linebreaks. What's the >> deal now? I haven't reviewed the security implications, but there may >> be some if clients are tolerant in their parsing of the server's >> handshake. >> > > The group had a big push towards "it's HTTP and is HTTP compatibile" so > this > all got re-written... if it's valid HTTP then it's OK, if it's not then > not > -- that was my interpretation... The spec doesn't say what the client should do if the response is not valid HTTP. (The HTTP spec doesn't define error handling either.) > >> >> Where the algorithm above requires that a user agent fail the >>> WebSocket connection, the user agent may first read an arbitrary >>> number of further bytes from the connection (and then discard them) >>> before actually *failing the WebSocket connection*. Similarly, if a >>> user agent can show that the bytes read from the connection so far >>> are such that there is no subsequent sequence of bytes that the >>> server can send that would not result in the user agent being >>> required to *fail the WebSocket connection*, the user agent may >>> immediately *fail the WebSocket connection* without waiting for those >>> bytes. >>> NOTE: The previous paragraph is intended to make it conforming for >>> user agents to implement the algorithm in subtly different ways that >>> are equivalent in all ways except that they terminate the connection >>> at earlier or later points. For example, it enables an >>> implementation to buffer the entire handshake response before >>> checking it, or to verify each field as it is received rather than >>> collecting all the fields and then checking them as a block. >>> >> >> It seems these two paragraphs aren't needed anymore when you don't have >> a detailed algorithm but just some bullet points. >> >> 5.2. Server-side requirements >>> _This section only applies to servers._ >>> Servers may offload the management of the connection to other agents >>> on the network, for example load balancers and reverse proxies. In >>> such a situation, the server for the purposes of conformance is >>> considered to include all parts of the server-side infrastructure >>> from the first device to terminate the TCP connection all the way to >>> the server that processes requests and sends responses. >>> EXAMPLE: For example, a data center might have a server that responds >>> to WebSocket requests with an appropriate handshake, and then passes >>> the connection to another server to actually process the data frames. >>> For the purposes of this specification, the "server" is the >>> combination of both computers. >>> 5.2.1. Reading the client's opening handshake >>> When a client starts a WebSocket connection, it sends its part of the >>> opening handshake. The server must parse at least part of this >>> handshake in order to obtain the necessary information to generate >>> the server part of the handshake. >>> The client handshake consists of the following parts. If the server, >>> while reading the handshake, finds that the client did not send a >>> handshake that matches the description below, the server must abort >>> the WebSocket connection. >>> 1. An HTTP/1.1 or higher GET request, including a "Request-URI" >>> [RFC2616] that should be interpreted as a /resource name/ >>> Section 3. >>> 2. A "Host" header containing the server's authority. >>> 3. A "Sec-WebSocket-Key" header with a base64-encoded value that, >>> when decoded, is 16 bytes in length. >>> 4. A "Sec-WebSocket-Version" header, with a value of 6. >>> 5. Optionally, a "Sec-WebSocket-Origin" header. This header is sent >>> by all browser clients. A connection attempt lacking this header >>> SHOULD NOT be interpreted as coming from a browser client. >>> 6. Optionally, a "Sec-WebSocket-Protocol header, with a list of >>> values indicating which protocols the client would like to speak, >>> ordered by preference. >>> >> >> Missing quote. >> >> -00 was stricter about the Sec-WebSocket-Protocol header: if the >> algorithm >> was fed with an empty /subprotocols/ then the header must not be >> included, >> else the header must be included with the values of /subprotocols/. I >> prefer >> that over anything-goes "optinally". >> >> 7. Optionally, a "Sec-WebSocket-Extensions" header, with a list of >>> values indicating which extensions the client would like to >>> speak. The interpretation of this header is discussed in >>> Section 8.1. >>> 8. Optionally, other headers, such as those used to send cookies to >>> a server. Unknown headers MUST be ignored. >>> 5.2.2. Sending the server's opening handshake >>> When a client establishes a WebSocket connection to a server, the >>> server must complete the following steps to accept the connection and >>> send the server's opening handshake. >>> 1. If the server supports encryption, perform a TLS handshake over >>> the connection. If this fails (e.g. the client indicated a host >>> >> >> If the server supports encryption? A bit unclear... if can support >> encryption but the requested URL might be ws: >> > > > will chat with hixie on cross-protocol things, frankly I hold firm that > tls > with http:// is rather useless and i really don't worry about it for > ws... The spec seems to say that the server must perform a TLS handshake if it supports TLS, even if the client started a plain ws: connection. It seems to me that in that case, the server should not perform a TLS handshake. > > >> >> name in the extended client hello "server_name" extension that >>> the server does not host), then close the connection; otherwise, >>> all further communication for the connection (including the >>> server handshake) must run through the encrypted tunnel. >>> [RFC2246] >>> 2. Establish the following information: >>> /origin/ >>> The |Sec-WebSocket-Origin| header in the client's handshake >>> indicates the origin of the script establishing the >>> connection. The origin is serialized to ASCII and converted >>> to lowercase. The server MAY use this information as part of >>> a determination of whether to accept the incoming connection. >>> >> >> I'd like a warning here that if the server doesn't validate the origin, >> it means that it will accept connections from anywhere. Normally it's >> the browser's responsibility to enforce same-origin restrictions, but >> with websockets it's the server application developer's responsibility, >> and this needs to be pointed out explicitly IMHO. >> >> I see now that there's a paragraph discussing this in security >> considerations. I'd be happy with a pointer to security considerations >> here. >> > > done > > >> >> /key/ >>> The |Sec-WebSocket-Key| header in the client's handshake >>> includes a base64-encoded value that, if decoded, is 16 bytes >>> in length. This (encoded) value is used in the creation of >>> the server's handshake to indicate an acceptance of the >>> connection. It is not necessary for the server to base64- >>> decode the Sec-WebSocket-Key value. >>> /version/ >>> The |Sec-WebSocket-Version| header in the client's handshake >>> includes the version of the WebSocket protocol the client is >>> attempting to communicate with. If this version does not >>> match a version understood by the server, the server MUST >>> abort the WebSocket connection. The server MAY send a non-200 >>> response code with a |Sec-WebSocket-Version| header indicating >>> the version(s) the server is capable of understanding along >>> with this non-200 response code. >>> /resource name/ >>> An identifier for the service provided by the server. If the >>> server provides multiple services, then the value should be >>> derived from the resource name given in the client's handshake >>> from the Request-URI [RFC2616] of the GET method. >>> /subprotocol/ >>> A (possibly empty) list representing the subprotocol the >>> server is ready to use. If the server supports multiple >>> subprotocols, then the value should be derived from the >>> client's handshake, specifically by selecting one of the >>> values from the "Sec-WebSocket-Protocol" field. The absence >>> of such a field is equivalent to the null value. The empty >>> string is not the same as the null value for these purposes. >>> /extensions/ >>> A (possibly empty) list representing the protocol-level >>> extensions the server is ready to use. If the server supports >>> multiple extensions, then the value should be derived from the >>> client's handshake, specifically by selecting one or more of >>> the values from the "Sec-WebSocket-Extensions" field. The >>> absence of such a field is equivalent to the null value. The >>> empty string is not the same as the null value for these >>> purposes. Extensions not listed by the client MUST NOT be >>> listed. The method by which these values should be selected >>> and interpreted is discussed in Section 8.1. >>> 3. If the server chooses to accept the incoming connection, it must >>> reply with a valid HTTP response indicating the following. >>> 1. A 101 response code. Such a response could look like >>> "HTTP/1.1 101 Switching Protocols" >>> 2. A "Sec-WebSocket-Accept" header. The value of this header is >>> constructed by concatenating /key/, defined above in >>> Paragraph 2 of Section 5.2.2, with the string "258EAFA5-E914- >>> 47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this >>> concatenated value to obtain a 20-byte value, and base64- >>> encoding this 20-byte hash. >>> NOTE: As an example, if the value of the "Sec-WebSocket-Key" >>> header in the client's handshake were >>> "dGhlIHNhbXBsZSBub25jZQ==", the server would append the >>> string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the >>> string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- >>> C5AB0DC85B11". The server would then take the SHA-1 hash of >>> this string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 >>> 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe >>> 0xc4 0xea. This value is then base64-encoded, to give the >>> value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned >>> in the "Sec-WebSocket-Accept" header. >>> 3. Optionally, a "Sec-WebSocket-Protocol" header, with a value >>> /subprotocol/ as defined in Paragraph 2 of Section 5.2.2. >>> 4. Optionally, a "Sec-WebSocket-Extensions" header, with a value >>> /extensions/ as defined in Paragraph 2 of Section 5.2.2. >>> This completes the server's handshake. If the server finishes these >>> steps without aborting the WebSocket connection, and if the client >>> does not then fail the WebSocket connection, then the connection is >>> established and the server may begin sending and receiving data, as >>> described in the next section. >>> >> >> The next section doesn't describe sending and receiving data. >> > > > done > > > >> >> 6. Error Handling >>> 6.1. Handling errors in UTF-8 from the server >>> When a client is to interpret a byte stream as UTF-8 but finds that >>> the byte stream is not in fact a valid UTF-8 stream, then any bytes >>> or sequences of bytes that are not valid UTF-8 sequences must be >>> interpreted as a U+FFFD REPLACEMENT CHARACTER. >>> >> >> Maybe use the HTML spec's definition of UTF-8 with error handling: >> >> http://www.whatwg.org/specs/web-apps/current-work/complete/infrastructure.html#decoded-as-utf-8,-with-error-handling >> >> 6.2. Handling errors in UTF-8 from the client >>> When a server is to interpret a byte stream as UTF-8 but finds that >>> the byte stream is not in fact a valid UTF-8 stream, behavior is >>> undefined. A server could close the connection, convert invalid byte >>> sequences to U+FFFD REPLACEMENT CHARACTERs, store the data verbatim, >>> or perform application-specific processing. Subprotocols layered on >>> the WebSocket protocol might define specific behavior for servers. >>> 7. Closing the connection >>> 7.1. Definitions >>> 7.1.1. Close the WebSocket Connection >>> To _Close the WebSocket Connection_, an endpoint closes the >>> underlying TCP connection. An endpoint SHOULD use a method that >>> cleanly closes the TCP connection, discarding any trailing bytes that >>> may be received. And endpoint MAY close the connection via any means >>> >> >> s/And/An/ >> > > done > > >> >> available when necessary, such as when under attack. >>> As an example of how to obtain a clean closure in C using Berkeley >>> sockets, one would call shutdown() with SHUT_WR on the socket, call >>> recv() until obtaining a return value of 0 indicating that the peer >>> has also performed an orderly shutdown, and finally calling close() >>> on the socket. >>> >> >> Hmm, this example seems a bit out of place. >> >> 7.1.2. Start the WebSocket Closing Handshake >>> To _start the WebSocket closing handshake_, and endpoint MUST send a >>> >> >> s/and/an/ >> > > done > > >> >> Close control frame, as described in Section 4.5.1. Upon receiving a >>> Close control frame, the other party sends a Close control frame in >>> response. Once an endpoint has both sent and received a Close >>> control frame, that endpoint should _Close the WebSocket Connection_ >>> as defined in Section 7.1.1. >>> >> >> Again this repeats the same requirements from 4.5.1, but subtly >> different, such that it's not clear which to follow. Please only have >> the same requirement once. >> > > > I removed what I think is duplicative and what remains is about the > minimal > set. > > >> >> 7.1.3. The WebSocket Connection Is Closed >>> When the underlying TCP connection is closed, it is said that _the >>> WebSocket connection is closed_. If the tcp connection was closed >>> after the WebSocket closing handshake was completed, the WebSocket >>> connection is said to have been closed _cleanly_. >>> 7.1.4. Fail the WebSocket Connection >>> Certain algorithms and specifications require a user agent to _fail >>> the WebSocket connection_. To do so, the user agent must _Close the >>> WebSocket Connection_, and MAY report the problem to the user (which >>> would be especially useful for developers) in an appropriate manner. >>> Except as indicated above or as specified by the application layer >>> (e.g. a script using the WebSocket API), user agents SHOULD NOT close >>> the connection. >>> 7.2. Abnormal closures >>> 7.2.1. Client-initiated closure >>> Certain algorithms, namely during the initial handshake, require the >>> user agent to *fail the WebSocket connection*. To do so, the user >>> agent must _Close the WebSocket connection_ as previously defined, >>> and may report the problem to the user via an appropriate mechanism >>> (which would be especially useful for developers). >>> Except as indicated above or as specified by the application layer >>> (e.g. a script using the WebSocket API), user agents should not close >>> the connection. >>> 7.2.2. Server-initiated closure >>> Certain algorithms require or recommend that the server _abort the >>> WebSocket connection_ during the opening handshake. To do so, the >>> server must simply _close the WebSocket connection_ (Section 7.1.1). >>> 7.3. Normal closure of connections >>> Servers MAY close the WebSocket connection whenever desired. User >>> agents SHOULD NOT close the WebSocket connection arbitrarily. In >>> either case, an endpoint initiates a closure by following the >>> procedures to _start the WebSocket closing handshake_ >>> (Section 7.1.2). >>> 7.4. Status codes >>> When closing an established connection (e.g. when sending a Close >>> frame, after the handshake has completed), an endpoint MAY indicate a >>> reason for closure. The interpretation of this reason by an >>> endpoint, and the action an endpoint should take given this reason, >>> are left undefined by this specification. This specification defines >>> a set of pre-defined status codes, and specifies which ranges may be >>> used by extensions, frameworks, and end applications. The status >>> code and any associated textual message are optional components of a >>> Close frame. >>> 7.4.1. Defined Status Codes >>> Endpoints MAY use the following pre-defined status codes when sending >>> a Close frame. >>> 1000 >>> 1000 indicates a normal closure, meaning whatever purpose the >>> connection was established for has been fulfilled. >>> 1001 >>> 1001 indicates that an endpoint is "going away", such as a server >>> going down, or a browser having navigated away from a page. >>> 1002 >>> 1002 indicates that an endpoint is terminating the connection due >>> to a protocol error. >>> 1003 >>> 1003 indicates that an endpoint is terminating the connection >>> because it has received a type of data it cannot accept (e.g. an >>> endpoint that understands only text data may send this if it >>> receives a binary message.) >>> 1004 >>> 1004 indicates that an endpoint is terminating the connection >>> because it has received a message that is too large. >>> 7.4.2. Reserved status code ranges >>> 0-999 >>> Status codes in the range 0-999 are not used. >>> 1000-1999 >>> Status codes in the range 1000-1999 are reserved for definition by >>> this protocol. >>> 2000-2999 >>> Status codes in the range 2000-2999 are reserved for use by >>> extensions. >>> 3000-3999 >>> Status codes in the range 3000-3999 MAY be used by libraries and >>> frameworks. The interpretation of these codes is undefined by >>> this protocol. End applications MUST NOT use status codes in this >>> range. >>> 4000-4999 >>> Status codes in the range 4000-4999 MAY be used by application >>> code. The interpretaion of these codes is undefined by this >>> protocol. >>> 8. Extensions >>> WebSocket clients MAY request extensions to this specification, and >>> WebSocket servers MAY accept some or all extensions requested by the >>> client. A server MUST NOT respond with any extension not requested >>> by the client. If extension parameters are included in negotiations >>> between the client and the server, those parameters MUST be chosen in >>> accordance with the specification of the extension to which the >>> parameters apply. >>> 8.1. Negotiating extensions >>> A client requests extensions by including a "Sec-WebSocket- >>> Extensions" header, which follows the normal rules for HTTP headers >>> (see [RFC2616] section 4.2) and the value of the header is defined by >>> the following ABNF: >>> extension-list = 1#extension >>> extension = extension-token *( ";" extension-param ) >>> extension-token = registered-token | private-use-token >>> registered-token = token >>> private-use-token = "x-" token >>> extension-param = token [ "=" ( token | quoted-string ) ] >>> Note that like other HTTP headers, this header may be split or >>> combined across multiple lines. Ergo, the following are equivalent: >>> Sec-WebSocket-Extensions: foo >>> Sec-WebSocket-Extensions: bar; baz=2 >>> is exactly equivalent to >>> Sec-WebSocket-Extensions: foo, bar; baz=2 >>> Any extension-token used must either be a registered token >>> (registration TBD), or have a prefix of "x-" to indicate a private- >>> use token. The parameters supplied with any given extension MUST be >>> defined for that extension. Note that the client is only offering to >>> use any advertised extensions, and MUST NOT use them unless the >>> server accepts the extension. >>> Note that the order of extensions is significant. Any interactions >>> between multiple extensions MAY be defined in the documents defining >>> the extensions. In the absence of such definition, the >>> interpretation is that the headers listed by the client in its >>> request represent a preference of the headers it wishes to use, with >>> the first options listed being most preferable. The extensions >>> listed by the server in response represent the extensions actually in >>> use. Should the extensions modify the data and/or framing, the order >>> of operations on the data should be assumed to be the same as the >>> order in which the extensions are listed in the server's response in >>> the opening handshake. >>> For example, if there are two extensions "foo" and "bar", if the >>> header |Sec-WebSocket-Extensions| sent by the server has the value >>> "foo, bar" then operations on the data will be made as >>> bar(foo(data)), be those changes to the data itself (such as >>> compression) or changes to the framing thay may "stack". >>> Non-normative examples of acceptable extension headers: >>> Sec-WebSocket-Extensions: deflate-stream >>> Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, >>> deflate-stream >>> Sec-WebSocket-Extensions: x-private-extension >>> A server accepts one or more extensions by including a |Sec- >>> WebSocket-Extensions| header containing one or more extensions which >>> were requested by the client. The interpretation of any extension >>> parameters, and what constitutes a valid response by a server to a >>> requested set of parameters by a client, will be defined by each such >>> extension. >>> 8.2. Known extensions >>> Extensions provide a mechanism for implementations to opt-in to >>> additional protocol features. This section defines the meaning of >>> well-known extensions but implementations may use extensions defined >>> separately as well. >>> 8.2.1. Compression >>> The registered extension token for this compression extension is >>> "deflate-stream". >>> The extension does not have any per message extension data and it >>> does not define the use of any WebSocket reserved bits or op codes. >>> Senders using this extension MUST apply RFC 1951 encodings to all >>> bytes of the data stream following the handshake including both data >>> and control messages. The data stream MAY include multiple blocks of >>> both compressed and uncompressed types as defined by RFC 1951. >>> [RFC1951] >>> Senders MUST NOT delay the transmission of any portion of a WebSocket >>> message because the deflate encoding of the message does not end on a >>> byte boundary. The encodings for adjacent messages MAY appear in the >>> same byte if no delay in transmission is occurred by doing so. >>> 9. Security considerations >>> While this protocol is intended to be used by scripts in Web pages, >>> it can also be used directly by hosts. Such hosts are acting on >>> their own behalf, and can therefore send fake "Origin" fields, >>> misleading the server. Servers should therefore be careful about >>> assuming that they are talking directly to scripts from known >>> origins, and must consider that they might be accessed in unexpected >>> ways. In particular, a server should not trust that any input is >>> valid. >>> EXAMPLE: For example, if the server uses input as part of SQL >>> queries, all input text should be escaped before being passed to the >>> SQL server, lest the server be susceptible to SQL injection. >>> Servers that are not intended to process input from any Web page but >>> only for certain sites should verify the "Origin" field is an origin >>> they expect, and should only respond with the corresponding "Sec- >>> WebSocket-Origin" if it is an accepted origin. Servers that only >>> accept input from one origin can just send back that value in the >>> "Sec-WebSocket-Origin" field, without bothering to check the client's >>> value. >>> >>> If at any time a server is faced with data that it does not >>> understand, or that violates some criteria by which the server >>> determines safety of input, or when the server sees a handshake that >>> does not correspond to the values the server is expecting (e.g. >>> incorrect path or origin), the server should just disconnect. It is >>> always safe to disconnect. >>> The biggest security risk when sending text data using this protocol >>> is sending data using the wrong encoding. If an attacker can trick >>> the server into sending data encoded as ISO-8859-1 verbatim (for >>> instance), rather than encoded as UTF-8, then the attacker could >>> inject arbitrary frames into the data stream. >>> In addition to endpoints being the target of attacks via WebSockets, >>> other parts of web infrastructure, such as proxies, may be the >>> subject of an attack. In particular, an intermediary may interpret a >>> WebSocket message from a client as a request, and a message from the >>> server as a response to that request. For instance, an attacker >>> could get a browser to establish a connection to its server, get the >>> browser to send a message that looks to an intermediary like a GET >>> request for a common piece of JavaScript on another domain, and send >>> back a message that is interpreted as a cacheable response to that >>> request, thus poisioning the cache for other users. To prevent this >>> attack, messages sent from clients are masked on the wire with a 32- >>> bit value, to prevent an attacker from controlling the bits on the >>> wire and thus lessen the probability of an attacker being able to >>> construct a message that can be misinterpreted by a proxy as a non- >>> WebSocket request. >>> 10. IANA considerations >>> 10.1. Registration of ws: scheme >>> A |ws:| URI identifies a WebSocket server and resource name. >>> URI scheme name. >>> ws >>> Status. >>> Permanent. >>> URI scheme syntax. >>> In ABNF terms using the terminals from the URI specifications: >>> [RFC5234] [RFC3986] >>> "ws" ":" hier-part [ "?" query ] >>> The path and query components form the resource name sent to the >>> server to identify the kind of service desired. Other components >>> have the meanings described in RFC3986. >>> URI scheme semantics. >>> The only operation for this scheme is to open a connection using >>> the WebSocket protocol. >>> Encoding considerations. >>> Characters in the host component that are excluded by the syntax >>> defined above must be converted from Unicode to ASCII by applying >>> the IDNA ToASCII algorithm to the Unicode host name, with both the >>> AllowUnassigned and UseSTD3ASCIIRules flags set, and using the >>> result of this algorithm as the host in the URI. [RFC3490] >>> Characters in other components that are excluded by the syntax >>> defined above must be converted from Unicode to ASCII by first >>> encoding the characters as UTF-8 and then replacing the >>> corresponding bytes using their percent-encoded form as defined in >>> the URI and IRI specification. [RFC3986] [RFC3987] >>> Applications/protocols that use this URI scheme name. >>> WebSocket protocol. >>> Interoperability considerations. >>> None. >>> Security considerations. >>> See "Security considerations" section above. >>> Contact. >>> Ian Hickson >>> Author/Change controller. >>> Ian Hickson >>> References. >>> This document. >>> 10.2. Registration of wss: scheme >>> A |wss:| URI identifies a WebSocket server and resource name, and >>> indicates that traffic over that connection is to be encrypted. >>> URI scheme name. >>> wss >>> Status. >>> Permanent. >>> URI scheme syntax. >>> In ABNF terms using the terminals from the URI specifications: >>> [RFC5234] [RFC3986] >>> "wss" ":" hier-part [ "?" query ] >>> The path and query components form the resource name sent to the >>> server to identify the kind of service desired. Other components >>> have the meanings described in RFC3986. >>> URI scheme semantics. >>> The only operation for this scheme is to open a connection using >>> the WebSocket protocol, encrypted using TLS. >>> Encoding considerations. >>> Characters in the host component that are excluded by the syntax >>> defined above must be converted from Unicode to ASCII by applying >>> the IDNA ToASCII algorithm to the Unicode host name, with both the >>> AllowUnassigned and UseSTD3ASCIIRules flags set, and using the >>> result of this algorithm as the host in the URI. [RFC3490] >>> Characters in other components that are excluded by the syntax >>> defined above must be converted from Unicode to ASCII by first >>> encoding the characters as UTF-8 and then replacing the >>> corresponding bytes using their percent-encoded form as defined in >>> the URI and IRI specification. [RFC3986] [RFC3987] >>> Applications/protocols that use this URI scheme name. >>> WebSocket protocol over TLS. >>> Interoperability considerations. >>> None. >>> Security considerations. >>> See "Security considerations" section above. >>> Contact. >>> Ian Hickson >>> Author/Change controller. >>> Ian Hickson >>> References. >>> This document. >>> 10.3. Registration of the "WebSocket" HTTP Upgrade keyword >>> Name of token. >>> WebSocket >>> Author/Change controller. >>> Ian Hickson >>> Contact. >>> Ian Hickson >>> References. >>> This document. >>> 10.4. Sec-WebSocket-Key >>> This section describes a header field for registration in the >>> Permanent Message Header Field Registry. [RFC3864] >>> Header field name >>> Sec-WebSocket-Key >>> Applicable protocol >>> http >>> Status >>> reserved; do not use outside WebSocket handshake >>> Author/Change controller >>> IETF >>> Specification document(s) >>> This document is the relevant specification. >>> Related information >>> None. >>> The |Sec-WebSocket-Key| header is used in the WebSocket handshake. >>> It is sent from the client to the server to provide part of the >>> information used by the server to prove that it received a valid >>> WebSocket handshake. This helps ensure that the server does not >>> accept connections from non-WebSocket clients (e.g. HTTP clients) >>> that are being abused to send data to unsuspecting WebSocket servers. >>> 10.5. Sec-WebSocket-Extensions >>> This section describes a header field for registration in the >>> Permanent Message Header Field Registry. [RFC3864] >>> Header field name >>> Sec-WebSocket-Extensions >>> Applicable protocol >>> http >>> Status >>> reserved; do not use outside WebSocket handshake >>> Author/Change controller >>> IETF >>> Specification document(s) >>> This document is the relevant specification. >>> Related information >>> None. >>> The |Sec-WebSocket-Extensions| header is used in the WebSocket >>> handshake. It is initially sent from the client to the server, and >>> then subsequently sent from the servver to the client, to agree on a >>> set of protocol-level extensions to use during the connection. >>> 10.6. Sec-WebSocket-Accept >>> This section describes a header field for registration in the >>> Permanent Message Header Field Registry. [RFC3864] >>> Header field name >>> Sec-WebSocket-Accept >>> Applicable protocol >>> http >>> Status >>> reserved; do not use outside WebSocket handshake >>> Author/Change controller >>> IETF >>> Specification document(s) >>> This document is the relevant specification. >>> Related information >>> None. >>> The |Sec-WebSocket-Accept| header is used in the WebSocket handshake. >>> It is sent from the server to the client to confirm that the server >>> is willing to initiate the connection. >>> 10.7. Sec-WebSocket-Origin >>> This section describes a header field for registration in the >>> Permanent Message Header Field Registry. [RFC3864] >>> Header field name >>> Sec-WebSocket-Origin >>> Applicable protocol >>> http >>> Status >>> reserved; do not use outside WebSocket handshake >>> Author/Change controller >>> IETF >>> Specification document(s) >>> This document is the relevant specification. >>> Related information >>> None. >>> The |Sec-WebSocket-Origin| header is used in the WebSocket handshake. >>> It is sent from the server to the client to confirm the origin of the >>> script that opened the connection. This enables user agents to >>> verify that the server is willing to serve the script that opened the >>> connection. >>> 10.8. Sec-WebSocket-Protocol >>> This section describes a header field for registration in the >>> Permanent Message Header Field Registry. [RFC3864] >>> Header field name >>> Sec-WebSocket-Protocol >>> Applicable protocol >>> http >>> Status >>> reserved; do not use outside WebSocket handshake >>> Author/Change controller >>> IETF >>> Specification document(s) >>> This document is the relevant specification. >>> Related information >>> None. >>> The |Sec-WebSocket-Protocol| header is used in the WebSocket >>> handshake. It is sent from the client to the server and back from >>> the server to the client to confirm the subprotocol of the >>> connection. This enables scripts to both select a subprotocol and be >>> sure that the server agreed to serve that subprotocol. >>> 10.9. Sec-WebSocket-Version >>> This section describes a header field for registration in the >>> Permanent Message Header Field Registry. [RFC3864] >>> Header field name >>> Sec-WebSocket-Version >>> Applicable protocol >>> http >>> Status >>> reserved; do not use outside WebSocket handshake >>> Author/Change controller >>> IETF >>> Specification document(s) >>> This document is the relevant specification. >>> Related information >>> None. >>> The |Sec-WebSocket-Version| header is used in the WebSocket >>> handshake. It is sent from the client to the server to indicate the >>> protocol version of the connection. This enables servers to >>> correctly interpret the handshake and subsequent data being sent from >>> the data, and close the connection if the server cannot interpret >>> that data in a safe manner. >>> 11. Using the WebSocket protocol from other specifications >>> The WebSocket protocol is intended to be used by another >>> specification to provide a generic mechanism for dynamic author- >>> defined content, e.g. in a specification defining a scripted API. >>> Such a specification first needs to "establish a WebSocket >>> connection", providing that algorithm with: >>> o The destination, consisting of a /host/ and a /port/. >>> o A /resource name/, which allows for multiple services to be >>> identified at one host and port. >>> o A /secure/ flag, which is true if the connection is to be >>> encrypted, and false otherwise. >>> o An ASCII serialization of an origin that is being made responsible >>> for the connection. [I-D.ietf-websec-origin] >>> o Optionally a string identifying a protocol that is to be layered >>> over the WebSocket connection. >>> The /host/, /port/, /resource name/, and /secure/ flag are usually >>> obtained from a URI using the steps to parse a WebSocket URI's >>> components. These steps fail if the URI does not specify a >>> WebSocket. >>> If a connection can be established, then it is said that the >>> "WebSocket connection is established". >>> If at any time the connection is to be closed, then the specification >>> needs to use the "close the WebSocket connection" algorithm. >>> When the connection is closed, for any reason including failure to >>> establish the connection in the first place, it is said that the >>> "WebSocket connection is closed". >>> While a connection is open, the specification will need to handle the >>> cases when "a WebSocket message has been received" with text /data/. >>> To send some text /data/ to an open connection, the specification >>> needs to "send /data/ using the WebSocket". >>> >> >> -- >> Simon Pieters >> Opera Software >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> -- Simon Pieters Opera Software From Internet-Drafts@ietf.org Fri Apr 22 16:00:03 2011 Return-Path: X-Original-To: hybi@ietfc.amsl.com Delivered-To: hybi@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 46CB9E065F; Fri, 22 Apr 2011 16:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZCzXIHVGmwZ; Fri, 22 Apr 2011 16:00:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 95105E067B; Fri, 22 Apr 2011 16:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110422230002.3988.41816.idtracker@ietfc.amsl.com> Date: Fri, 22 Apr 2011 16:00:02 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-07.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 23:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. Title : The WebSocket protocol Author(s) : I. Fette Filename : draft-ietf-hybi-thewebsocketprotocol-07.txt Pages : 57 Date : 2011-04-22 The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or