Re: [hybi] Websocket algorithmic specification

Greg Wilkins <gregw@webtide.com> Tue, 02 February 2010 03:22 UTC

Return-Path: <gregw@webtide.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 59FB228C0E2 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 19:22:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 VYWeNCzZFSE5 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 19:22:31 -0800 (PST)
Received: from mail-qy0-f178.google.com (mail-qy0-f178.google.com [209.85.221.178]) by core3.amsl.com (Postfix) with ESMTP id 3AF333A635F for <hybi@ietf.org>; Mon, 1 Feb 2010 19:22:31 -0800 (PST)
Received: by qyk8 with SMTP id 8so2198162qyk.24 for <hybi@ietf.org>; Mon, 01 Feb 2010 19:23:04 -0800 (PST)
Received: by 10.224.15.130 with SMTP id k2mr2531897qaa.143.1265080984108; Mon, 01 Feb 2010 19:23:04 -0800 (PST)
Received: from ?10.10.1.11? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 7sm20007201qwb.2.2010.02.01.19.23.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 19:23:03 -0800 (PST)
Message-ID: <4B679A89.9080609@webtide.com>
Date: Tue, 02 Feb 2010 14:22:49 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <4B675896.7050308@webtide.com> <Pine.LNX.4.64.1002020300060.3846@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1002020300060.3846@ps20323.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Websocket algorithmic specification
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: Tue, 02 Feb 2010 03:22:32 -0000

Ian Hickson wrote:

> Fixed in response to the earlier e-mail.

great

> Good point. Fixed.

thanks


> 
>> None of the framing algorithms specify how a timeout should be handled.
> 
> In what sense does this differ from the connection being closed?

a closed connection is one that is no longer open.

a timeout is when you try to read from an open connection, but
nothing comes for a period of time.

I know you will say: "the server can close the connection at
any time".   But either the algorithms should specify all the
error handling or none.  Having a bit in the algorithms and
a bit in imperative style is confusing.


>> The length encoding currently allows for a length of 0x80 0x80 0x80 .... 
>> to be sent forever.  This is a nonsense length, but could be used for 
>> DOS attacks on servers.  I think the 0x80 value should be explicitly 
>> defined as an error if given as the first byte of a length.
> 
> How would this be different than sending 0x81 forever?

Sending 0x81 forever should also be caught, but by the
server detecting an overflow of the accumulating length byte.

Again, the point is - if the algorithm style is meant to
convey all the error handling, then it needs to be thorough.

If it's not specifying the error handling, then I'm not sure
what its giving use that the ABNF doesn't?


>> If the spec is to include error handling in it's algorithms, then it 
>> should state that the length loop can be terminated if the accumulated 
>> value exceeds some maximum.
> 
> The spec says "If the user agent is faced with content that is too large 
> to be handled appropriately, then it must fail the Web Socket connection".

Which is fine.   But if it also sometimes has explicit
error handling for resources in some algorithms, but not others,
then that is confusing.


> I've explicitly mentioned that "send" can be delayed, but this is 
> redundant with another statement in the spec which reads "Conformance 
> requirements phrased as algorithms or specific steps may be implemented in 
> any manner, so long as the end result is equivalent". 
> In particular, 
> there's no practical difference between buffering as you describe, and the 
> program simply not running for a short while before the "send" step.

The two approaches are not equivalent.  The result in entirely different
packets being sent over the wire.

But they are equivalent in terms of the ABNF definition of the framing,
which gives a precise definition, and can even be formally proved.

So still don't see any clarity from the algorithms.


>> Does this mean that ws server could validly reject a handshake as non 
>> compliant if these bytes arrived in the same packet as the subsequent 
>> bytes?
> 
> Servers can reject a handshake for any reason whatsoever.

Well that certainly makes for a very simple implementation of a
minimally compliant server!


regards