[hybi] Section 5.2.2 clarifications

Dirkjan Ochtman <dirkjan@ochtman.nl> Mon, 30 May 2011 12:13 UTC

Return-Path: <djc.ochtman@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D479FE0716 for <hybi@ietfa.amsl.com>; Mon, 30 May 2011 05:13:24 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDdi0Atj7Asu for <hybi@ietfa.amsl.com>; Mon, 30 May 2011 05:13:23 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD223E0651 for <hybi@ietf.org>; Mon, 30 May 2011 05:13:23 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2322917qwc.31 for <hybi@ietf.org>; Mon, 30 May 2011 05:13:23 -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=5Xl7rWNA1hjkZ5VNi5Nr6qVHW9UtbeWv06Y8IfJTboQ=; b=AFgx4bJC8suvxQAwscF+GZAhgwU+e0GeriM5ca4KnJS87xaQ5PXvSBe5t8V6tDrqjj 4QAihCloiLeTPFB8fz+P/zyoldESL10/m13PmCqCIBZM4gCySpQtuF35VfXMWz3ImRy9 eNLxBRyCqzhmVwKb443z5odsJsFwtjg01eCos=
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=otqlA+QSgY9x3cKlTiKYIMH5CUL80ia92q7FTne5NnlrZTZQcMrwjoqDO8Z/waoyX4 jXjULLUjRcsIhPclQkA/8PUHe2UST0EOV72+E71w81Mrc1nTIz2Xq29z+VeSoZSC20KX hJnMmKNAKnRtEQq37imUf7pnqwGPCK2palXGY=
Received: by 10.229.20.83 with SMTP id e19mr3466985qcb.288.1306757603085; Mon, 30 May 2011 05:13:23 -0700 (PDT)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.229.32.143 with HTTP; Mon, 30 May 2011 05:13:03 -0700 (PDT)
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Mon, 30 May 2011 14:13:03 +0200
X-Google-Sender-Auth: p9zX9FZxbRMRwiBgpH_1NBmz_CM
Message-ID: <BANLkTim69qg-BTStvF03gKXDGEgC5vRDng@mail.gmail.com>
To: hybi@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [hybi] Section 5.2.2 clarifications
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 30 May 2011 12:27:29 -0000

Hi all,

(I'm new here; I hope this is the correct venue for remarks like this.)

I just upgraded from Firefox 5 to Firefox 6 [1], which includes upgrading
from the -76 to the -07 version of the protocol. I found a small
Python server for -76 on the internet, which I've since adapted for
the environment at work, and tried to upgrade the script to -07 from
the spec (since there doesn't seem to be much code out there yet).
Most of the spec seems quite clear, which is great, but I had some
trouble with the server handshake (section 5.2.2).

In particular, it seems like the Upgrade and Connection headers (which
are shown in the example in non-normative section 1.2) should be
mentioned here, as well. Step 3 in this section only mentions the
Status line, the Sec-WebSocket-Accept header and the optional
-Protocol and -Extensions headers. Step 3 starts out to mention that a
"valid HTTP response" is required, and this clearly requires the
Upgrade header in this context (per RFC 2616), but from the RFC I
don't see why the Connection header would be mandatory here. In any
case, it would be nice to expand step 3 a little bit. Including an
example here would also be quite useful (similar to what section 1.2
has for the server part of the handshake). Finally, it might be
sensible to reference the HTTP Status-Line definition again in part 1
of step 3.

And one very minor nit: section 8.2.1 talks about "op codes", whereas
the rest of the document uses "opcode" and "opcodes".

Hope this is helpful,

Dirkjan

[1] I've also just filed
https://bugzilla.mozilla.org/show_bug.cgi?id=660613 against the
Mozilla implementation.