Re: [hybi] Revised WebSocket Feedback
Fumitoshi Ukai (鵜飼文敏) <ukai@chromium.org> Thu, 18 March 2010 10:17 UTC
Return-Path: <ukai@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456BD3A6B64 for <hybi@core3.amsl.com>; Thu, 18 Mar 2010 03:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.346
X-Spam-Level:
X-Spam-Status: No, score=-101.346 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 azJi8DiG+nyD for <hybi@core3.amsl.com>; Thu, 18 Mar 2010 03:17:10 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 544E13A6870 for <hybi@ietf.org>; Thu, 18 Mar 2010 03:16:59 -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 o2IAHA3u012294 for <hybi@ietf.org>; Thu, 18 Mar 2010 03:17:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1268907430; bh=BF5RN3za0rWvmoayni1zGW6o6jA=; h=MIME-Version:Sender:In-Reply-To:References:From:Date:Message-ID: Subject:To:Cc:Content-Type; b=BywFtTcBg9+MzV/7lwiKAjAV6rD49fzLo52Bks2SgNuEUcZl18i8bRouX0fl+g0bq UP7u5lgSYFTnGI73cBAnw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:sender:in-reply-to:references:from:date: x-google-sender-auth:message-id:subject:to:cc:content-type:x-system-of-record; b=CnttzpPwwKLsnkmtSw4QKhdZXiJi2/ftfIvP7P1RgBvQ9cVFAbGFhGSl/95GgNuWA xaP0WniAllwRyq3m74NyQ==
Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by wpaz37.hot.corp.google.com with ESMTP id o2IAH8n7013819 for <hybi@ietf.org>; Thu, 18 Mar 2010 03:17:08 -0700
Received: by gxk2 with SMTP id 2so927614gxk.10 for <hybi@ietf.org>; Thu, 18 Mar 2010 03:17:08 -0700 (PDT)
MIME-Version: 1.0
Sender: ukai@google.com
Received: by 10.150.120.25 with SMTP id s25mr1760092ybc.27.1268907428318; Thu, 18 Mar 2010 03:17:08 -0700 (PDT)
In-Reply-To: <3d5f2a811003150230sdeb4f78hbdece96e5c742cfc@mail.gmail.com>
References: <B578CFED7FE85644A170F4F7C9D52692019544C5@ESESSCMS0361.eemea.ericsson.se> <3d5f2a811003150230sdeb4f78hbdece96e5c742cfc@mail.gmail.com>
From: "Fumitoshi Ukai (鵜飼文敏)" <ukai@chromium.org>
Date: Thu, 18 Mar 2010 19:16:48 +0900
X-Google-Sender-Auth: 383e91409b4dc957
Message-ID: <de17d48e1003180316w3dda1a3fo7db8b357925ec3f8@mail.gmail.com>
To: Takeshi Yoshino <tyoshino@google.com>
Content-Type: multipart/alternative; boundary="000e0cd70d90848fdd04821088b9"
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Revised WebSocket Feedback
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2010 10:17:12 -0000
On Mon, Mar 15, 2010 at 18:30, Takeshi Yoshino <tyoshino@google.com> wrote: > Hi, > > 2010/3/9 Vladimir Katardjiev <vladimir.katardjiev@ericsson.com> > >> Heya, >> >> So, after some implementation work it's time to channel some responses. >> >> First, a copy/paste error. Page 31 seems to be missing Sec-WebSocket-Key2. >> >> Same page, you probably meant | instead of " in >> >> (such as |Cookie") >> >> Also, this might be just my reading comprehension, but the following >> paragraph caused a double-take >> >> if a server assumes that its clients are authorized >> on the basis that they can connect [...] then the server >> should also verify that the client's handshake includes the >> invariant "Upgrade" and "Connection" parts of the handshake, and >> should send the server's handshake before changing any user data. >> >> Checking Upgrade and Connection is redundant if Sec-WebSocket-* are >> present from a browser PoV;that was the point of them, no? Furthermore, it >> is not evident that by /sending/ a reply you're preventing cross-protocol >> attacks. I guess you meant by reading the client's handshake (which just >> happens to be a part of the "sending reply" section). >> >> Right, time to graduate from reading comprehension into actual questions. >> The big addition obviously Sec-WebSocket-Key1/2. Are there any fundamental >> limitations on where spaces can and should occur in the header? According to >> my interpretation as it stands, the following string is a perfectly valid >> key: " 4abcd". Is this intended? And, if so, can the leading (or >> trailing, if so inclined) spaces cause issues when parsing by >> proxies/existing stacks? >> >> > E.g. when /number_1/ is set to 0, /key_1/ will be "0" regardless of > /spaces_1/. Then, in step 21, we have to insert /spaces_1/ spaces into this > string with a length of 1. This is problematic since the only possible > positions for the first insertion are the head and tail of the target > string. > > I agree that we should avoid putting spaces on the tail or the head (at > least putting a space for this algorithm on the head must be prohibited). > How about swapping step 21 and 22? > or how about requiring /key_1/ string at step 20 should have 10 (or at least some number of ) digits with leading zero, so we can insert random position even if /product_1/ is single digit number ? -- ukai > > >> Also, I must've missed the big discussion, but what's the rationale of >> having two key headers. One I can buy, but since it should already be >> impossible to create a Sec-* header from a browser, AND it is impossible to >> add spaces to the header value, AND it is a GET with a body, it's already >> triple impossible (impossibler? impossiblest?) for XHR/CORS to forge. If >> someone has a handy link to where this suggestion was born it'd be >> appreciated, because this seems like quite a bit of computation involved. >> >> The junk characters in the handshake also seem redundant. If you already >> need to verify the correct number of spaces this means you are checking for >> spaces already. As for the garbage characters, all they made me do was >> replace("[^0-9]", '') instead of replace(' ', '') so I'd say they didn't >> alter the functionality of my code other than take up more CPU cycles. >> >> The closing handshake is also interesting. Maybe state in 5.3. that the >> server shouldn't disconnect on 0xFF (instead of may; it still may, but is >> discouraged from doing so since it may cause data loss. If the target >> audience really is the kind of programmer you need to verify their code by >> actually ensuring they read the spaces, then make the default level of the >> protocol ensure data integrity, because that's what they'll see in the lab >> network). >> >> Finally, and probably my smallest serious gripe, but what's up with the >> mix of references to ASCII and UTF-8 as characters. It is all technically >> correct, to nobody's surprise, but it's distracting to read. I hope it's >> just a transitional thing and it'll eventually be UTF-8 throughout but it >> was just too boring to do it all at once. >> >> Cheers, >> Vladimir >> >> PS, some notes that border on the psychopathic crazy programmer in a dark >> dungeon mindset. These can be safely ignored. >> >> Page 20: EXAMPLE: For example >> >> Acknowledgement: OK! >> >> Page 22: -> If the byte is 0x3A (ASCII :) >> >> The internet has damaged me so badly this was a smiley face. >> _______________________________________________ >> 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 > >
- [hybi] Revised WebSocket Feedback Vladimir Katardjiev
- Re: [hybi] Revised WebSocket Feedback Takeshi Yoshino
- Re: [hybi] Revised WebSocket Feedback Fumitoshi Ukai (鵜飼文敏)
- Re: [hybi] Revised WebSocket Feedback Takeshi Yoshino
- [hybi] WebSockets feedback Ian Hickson
- Re: [hybi] WebSockets feedback Pieter Hintjens
- Re: [hybi] WebSockets feedback Greg Wilkins
- [hybi] email granularity, was: WebSockets feedback Julian Reschke
- Re: [hybi] email granularity, was: WebSockets fee… Pieter Hintjens
- Re: [hybi] email granularity, was: WebSockets fee… Anne van Kesteren
- Re: [hybi] email granularity, was: WebSockets fee… Ian Hickson
- Re: [hybi] email granularity, was: WebSockets fee… Julian Reschke
- Re: [hybi] email granularity, was: WebSockets fee… Michael Carter
- Re: [hybi] email granularity, was: WebSockets fee… Justin Erenkrantz
- Re: [hybi] email granularity, was: WebSockets fee… Greg Wilkins
- Re: [hybi] email granularity, was: WebSockets fee… Julian Reschke
- Re: [hybi] email granularity, was: WebSockets fee… SM
- Re: [hybi] email granularity, was: WebSockets fee… Greg Wilkins
- Re: [hybi] email granularity, was: WebSockets fee… Tim Bray
- Re: [hybi] email granularity, was: WebSockets fee… Pieter Hintjens
- Re: [hybi] email granularity, was: WebSockets fee… SM
- Re: [hybi] email granularity, was: WebSockets fee… Ian Hickson
- Re: [hybi] email granularity, was: WebSockets fee… Maciej Stachowiak
- Re: [hybi] email granularity, was: WebSockets fee… Pieter Hintjens
- Re: [hybi] email granularity, was: WebSockets fee… Greg Wilkins
- Re: [hybi] email granularity, was: WebSockets fee… L.Wood