Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015
Jason Duell <jduell.mcbugs@gmail.com> Thu, 24 May 2012 20:19 UTC
Return-Path: <jduell.mcbugs@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 1600611E809D for <hybi@ietfa.amsl.com>; Thu, 24 May 2012 13:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daz5+wMwItr3 for <hybi@ietfa.amsl.com>; Thu, 24 May 2012 13:19:09 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C46C11E8097 for <hybi@ietf.org>; Thu, 24 May 2012 13:19:09 -0700 (PDT)
Received: from [10.0.0.174] (108-224-128-249.uvs.rlghnc.sbcglobal.net [108.224.128.249]) (Authenticated sender: jduell@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 854F2F2454; Thu, 24 May 2012 13:19:08 -0700 (PDT)
Message-ID: <4FBE97BB.4090609@gmail.com>
Date: Thu, 24 May 2012 16:19:07 -0400
From: Jason Duell <jduell.mcbugs@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Takashi Toyoshima <toyoshim@chromium.org>
References: <CAH9hSJbQ7dcu4N=Yf7TyFzJ0FhfVRehEMtnFx3Qvv_W0T5Cs+A@mail.gmail.com> <4FAACC40.6040308@isode.com> <CAH9hSJY5RPiAfwgBkbK08sY09dDkOO6JtCWqM2dYUko2ZV5MZw@mail.gmail.com> <CAFWCB1kuuMNSEmcgcHdMyOHRJyp=VKSm-YNceCPDZat3+1=zJw@mail.gmail.com> <CAM6mnz+fy2D_91UL=nnOmrL=4LOqrQ97CQW8DfFkQhHDHwn6FQ@mail.gmail.com> <CAH9hSJYUmPsMpjoo9f4SpK_0jW3XcbTGE-Bksi8x+62LD6NoeA@mail.gmail.com> <CAFWCB1kmfn-wsnTptDjDsXUVGLdwMMG49eTNz7YutC9ZsE07yw@mail.gmail.com>
In-Reply-To: <CAFWCB1kmfn-wsnTptDjDsXUVGLdwMMG49eTNz7YutC9ZsE07yw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015
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: Thu, 24 May 2012 20:19:10 -0000
> >>> On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima >>> <toyoshim@chromium.org> wrote: >>>> I'll fix WebKit implementation of receiving 1005, 1006, 1015, and >>>> length=1 of close frames. >>>> These frames will fire CloseEvent with code=1006 and wasClean=false. >>> What, if anything, do you plan to reply to the endpoint with, if the >>> 1005/1006/1015 is received before your client has sent its own close >>> frame? Will you be replying with 1002, but delivering 1006 to >>> onclose? I can see the logic there, though it's a little confusing. >> Yes. It's a bit confusing but well defined behavior. For any other protocol >> violation, the endpoint received a broken frame SHOULD send 1002 and MUST >> invoke onclose with 1006. >> >> http://tools.ietf.org/html/rfc6455#section-7.1.7 > On Wed, May 23, 2012 at 1:38 PM, Jason Duell <jduell.mcbugs@gmail.com> > wrote: So all protocol errors must deliver 1006 to JS instead of 1002? This is counter-intuitive to me, and I think it will confuse both users and developers. > As 7.1.5 of the spechttp://tools.ietf.org/html/rfc6455#section-7.1.5 explains, > now it's meaning is finalized as "the status code contained in the first > Close control frame received". OK--so if I follow you, the justification here to deliver 1006 to the application when the client encounters a protocol error is because we always set the close code to the error the *server* sends us, or 1006, (i.e a protocol error means no close frame, so 1006). I can see this reading of the spec. But the exact language for 1002 is "1002 indicates that an endpoint is terminating the connection due to a protocol error." Note that it says "an" endpoint, not "the remote endpoint." This makes me think we can deliver 1002 to JS for a protocol error we detect from the server. I suggest that we handle malformed close frames (with close code 1005/1006/1015) as a protocol error, and deliver 1002 to both the remote end and JS, and reserve 1006 for the case where the connection is simply closed, w/o any protocol error (i.e. no malformed frames received). I agree that in either case we should Fail the WS connection, so deliver onerror. Thoughts? Jason Duell Mozilla
- [hybi] RFC6455 clarification: when received close… Takeshi Yoshino
- Re: [hybi] RFC6455 clarification: when received c… Arman Djusupov
- Re: [hybi] RFC6455 clarification: when received c… Alexey Melnikov
- Re: [hybi] RFC6455 clarification: when received c… Takeshi Yoshino
- Re: [hybi] RFC6455 clarification: when received c… Takashi Toyoshima
- Re: [hybi] RFC6455 clarification: when received c… Jason Duell
- Re: [hybi] RFC6455 clarification: when received c… Takeshi Yoshino
- Re: [hybi] RFC6455 clarification: when received c… Takashi Toyoshima
- Re: [hybi] RFC6455 clarification: when received c… Jason Duell
- Re: [hybi] RFC6455 clarification: when received c… Takeshi Yoshino