Re: [hybi] Websocket algorithmic specification

Ian Hickson <ian@hixie.ch> Tue, 02 February 2010 03:10 UTC

Return-Path: <ian@hixie.ch>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4173A6899 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 19:10:20 -0800 (PST)
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=0.179, 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 LHgsyQG05pNn for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 19:10:19 -0800 (PST)
Received: from looneymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id EC5833A635F for <hybi@ietf.org>; Mon, 1 Feb 2010 19:10:18 -0800 (PST)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a4.g.dreamhost.com (Postfix) with ESMTP id 48A7D83CF; Mon, 1 Feb 2010 19:10:55 -0800 (PST)
Date: Tue, 02 Feb 2010 03:10:54 +0000
From: Ian Hickson <ian@hixie.ch>
To: Greg Wilkins <gregw@webtide.com>
In-Reply-To: <4B675896.7050308@webtide.com>
Message-ID: <Pine.LNX.4.64.1002020300060.3846@ps20323.dreamhostps.com>
References: <4B675896.7050308@webtide.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: "hybi@ietf.org" <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:10:20 -0000

On Tue, 2 Feb 2010, Greg Wilkins wrote:
> 
> The client side sentinel framing algorithm includes the
> text in 4.2-2.-(second 2.):
> 
>     "If the client runs out of resources for buffering the
>      incoming data, or hits an artificial resource limit
>      intended to avoid resource starvation, then it must
>      fail the Web Socket connection and abort these steps."
> 
> Surely this text must either be copied to every data
> read (for length framing and for both server side framings)
> or (better) moved to a overall "If at any point during these
> steps ..." type statement.

Fixed in response to the earlier e-mail.


> The phrase
>    "If at any point during these steps a read is
>     attempted but fails because the Web Socket connection is
>     closed, then abort"
> 
> is repeated for both client side framing algorithms, but
> is not included in the server side algorithms.

Good point. Fixed.


> None of the framing algorithms specify how a timeout should be handled.

In what sense does this differ from the connection being closed?


> Error handling for low resources, closed connections and timeouts is 
> probably best specified once rather than repeated everywhere the 
> algorithms say read. But if it is to be specified in the algorithms, 
> then it needs to be thorough and consistent.

I think the spec is thorough now, though I agree it could be more 
consistent.


> 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?


> 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".


> The specification algorithms use the phrase "send the following bytes" 
> frequently.  For example 4.1-5 says:
> 
>  send the following bytes to the remote server
>  47 45 54 20
> 
> A literal reading of the spec would interpret that as meaning that the 
> bytes actually have to be sent, while any sane implementation is going 
> to append the bytes to a buffer to be sent/flushed sometime later.

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.


> 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.

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