IETF Logo Mail Archive

[hybi] Indicator in frame whether it is masked (was Masked framing VS mask in frame)

Bruce Atherton <bruce@callenish.com> Sat, 26 February 2011 02:18 UTC

Return-Path: <bruce@callenish.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 DD5003A6A57 for <hybi@core3.amsl.com>; Fri, 25 Feb 2011 18:18:45 -0800 (PST)
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 Yzf-lNomYnxk for <hybi@core3.amsl.com>; Fri, 25 Feb 2011 18:18:42 -0800 (PST)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 9A5F73A6AC1 for <hybi@ietf.org>; Fri, 25 Feb 2011 18:18:42 -0800 (PST)
Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from <bruce@callenish.com>) id 1Pt9kf-0001b2-I6 for hybi@ietf.org; Fri, 25 Feb 2011 18:19:21 -0800
Message-ID: <4D68633A.1070902@callenish.com>
Date: Fri, 25 Feb 2011 18:19:38 -0800
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Hybi <hybi@ietf.org>
References: <AANLkTindH-Eu8GvsdtG7dgr+8MpQaaeRA7KTEBGz0sh-@mail.gmail.com> <AANLkTi=65LMo=kUv5uKNM5DeUNKFtnY6xks2UgsFEEWq@mail.gmail.com> <AANLkTi=2fUyryrRGDcS5Bqb-C2YPhRqJuKwUUkZnCBOu@mail.gmail.com>
In-Reply-To: <AANLkTi=2fUyryrRGDcS5Bqb-C2YPhRqJuKwUUkZnCBOu@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; 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] Indicator in frame whether it is masked (was Masked framing VS mask in frame)
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: Sat, 26 Feb 2011 02:18:46 -0000

Right now there is no way to tell whether a particular Websocket frame 
is travelling from client to server or server to client without knowing 
which end sent the packet and whether that end is acting as the client 
or the server. This complicates decoding as, just given the packet data, 
you can't tell whether a frame key is present and demasking needs to be 
done. Even with human intervention this can get a little confusing given 
that a server can act both as a client and a server on different 
connections.

If the framing is not masked then one solution would be to use one of 
the reserved bits to indicate whether the frame originated at a client 
or not. Would your objection to using a reserved bit to indicate a mask 
in the extension data extend to this use as well? I realize that the 
reserved bits are very limited, but masking and its omission does seem 
rather fundamental to the protocol as it affects the parsing of the 
frame (ie. read 4 extra bytes at the beginnning, or don't).

On 25/02/2011 6:41 AM, John Tamplin wrote:
>   - I would not support use of any reserved bits to indicate the mask
> is in the extension data
>     portion of the frame - instead, it should simply be defined to be
> the first 4 bytes if masking is
>     present (ie, client->server frames)
>   - it will complicate how mux and other extensions are defined, but I
> think we can deal with that
>     when we define those extensions
>

v2.23.0 | Report a Bug | By Email