From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: Support Websocket status code Date: Wed, 7 Aug 2019 19:39:41 +0800 Message-ID: References: <87d0hhh3fz.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000043b8ff058f856661" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="269516"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Aug 07 13:40:06 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hvKIY-00182J-16 for guile-devel@m.gmane.org; Wed, 07 Aug 2019 13:40:06 +0200 Original-Received: from localhost ([::1]:40002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvKIW-000393-JF for guile-devel@m.gmane.org; Wed, 07 Aug 2019 07:40:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56634) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvKIN-00038e-4C for guile-devel@gnu.org; Wed, 07 Aug 2019 07:39:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvKIM-0005cb-0N for guile-devel@gnu.org; Wed, 07 Aug 2019 07:39:55 -0400 Original-Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]:46049) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvKIL-0005cD-SI for guile-devel@gnu.org; Wed, 07 Aug 2019 07:39:53 -0400 Original-Received: by mail-yb1-xb33.google.com with SMTP id s41so9986419ybe.12 for ; Wed, 07 Aug 2019 04:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DnXTvusIfayFJf0G4rsoIsdcFKYmHGl6aLWyboNd5VI=; b=W6a//am0+hxl0yVivR3Gkn6dMEXa+VqFICrky8sbmegiKjDQfC++lseeYWmgVTMzpx hCoDRdT1Xv1UndBaANLMPIEle3PcBQDcm0IenqNbzo6ralgD5ln/8JESWNK4cLJeo2AN ZL3Co/fJKFxKe8H5/7lyh7fRfDtYUmBXRb5Dd9qkScpoJSWZ/wPHHg4ZEnyxh79cgduT yG7CWfjKb1C5xvGD9/Wus5NpekKZ3qkfRUvc6kG3hh1sDi+8IpPnJhpm2Pf0r95fp9jg qLxFVTd7QZi+AbM0Bhm9cWw5FJbJU1Ir3mwTuT0cNfghUVZ1e5ejTFel2f2faNu99F5J 4tuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DnXTvusIfayFJf0G4rsoIsdcFKYmHGl6aLWyboNd5VI=; b=ehkSM/j5QbK5oz3JQFUFcksfOYaAjdNqnHu4DsKTcGoCIZhYRvTdL+D/mE70Z2GmZQ F6us7cpEE5ifZjCf3t5mz1zQFVjv/AXLtbaWWSEoIijO+pzIJKa28RWNaBb6saSBqK5l Aq/JLmSojLbdYntKX1uYWpi5NP03wKZeizMx1IYrsMrStd+irIK127GnLMT8awU9FgcB wm5TEmdz+W5h4dN1R765/hj6RPMTDT3k+E8AyRRLtm5GRFenV14SScLrcMupTtH3+xJO KoKx/MsHRRB/vKmNj0n/2dcpemFsVDxL6kuahS23/ggq6dcm2IUvY0VUBUNI8vR9JCKq ShTg== X-Gm-Message-State: APjAAAVUVmtMlg+yR7hMGG+kpZNODRNnzE3hxThJHbsUJmofKklcYKqM iclTEEWHIXhHFrQN4nTBJfZ2zrJfTGC7b5uBPFcW8JjWY3c= X-Google-Smtp-Source: APXvYqyT5iTs0C9SdVcwxubj9cypL3kGdpzN6eIircaTGHRjn2Px1bv6WH/atIptgbUw6HLHkjfizQjrrwX/WQPX55s= X-Received: by 2002:a25:eb04:: with SMTP id d4mr5763078ybs.409.1565177992688; Wed, 07 Aug 2019 04:39:52 -0700 (PDT) In-Reply-To: <87d0hhh3fz.fsf@netris.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::b33 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20035 Archived-At: --00000000000043b8ff058f856661 Content-Type: text/plain; charset="UTF-8" hi Mark! Yes you're right, the status code should be encoded in close-frame, not HTTP response. Sorry for the wrong patch. ;-) Best regards. On Wed, Aug 7, 2019 at 2:52 PM Mark H Weaver wrote: > Hi, > > Nala Ginrut writes: > > > Hi folks! > > The current response builder will reject status code less than 600: > > -------------------------------code------------------------- > > ((not (and (non-negative-integer? code) (< code 600))) > > (bad-response "Bad code: ~a" code)) > > --------------------------------------------------------------- > > > > However, Websocket specific status code is larger than 1000. > > Section 4.2.2 paragraph 5 of RFC 6455 (the WebSocket RFC) makes it clear > that the HTTP response should conform to RFC 2616, which specifies that > the status code is a 3-digit integer less than 600. > > If I understand correctly, the larger status codes defined in section > 7.4.1 of RFC 6455 are never used in HTTP response headers. Rather, they > are optionally used in WebSocket Close control frames to indicate the > reason for closure. See section 7.1.6 for more on that. > > The WebSocket protocol is quite distinct from the HTTP protocol. > Although HTTP is used initially, after the server returns the HTTP > response with status "101 Switching Protocols", a completely different > protocol is used henceforth. > > So, I don't see anything in the RFCs to justify using the larger status > codes in HTTP response status line. Am I misunderstanding something? > > Mark > --00000000000043b8ff058f856661 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi Mark!
Yes you're right, the status code should = be encoded in close-frame, not HTTP response.
Sorry for the wrong= patch. ;-)

Best regards.


On W= ed, Aug 7, 2019 at 2:52 PM Mark H Weaver <mhw@netris.org> wrote:
Hi,

Nala Ginrut <n= alaginrut@gmail.com> writes:

> Hi folks!
> The current response builder will reject status code less than 600: > -------------------------------code-------------------------
>=C2=A0 ((not (and (non-negative-integer? code) (< code 600)))
>=C2=A0 =C2=A0(bad-response "Bad code: ~a" code))
> ---------------------------------------------------------------
>
> However, Websocket specific status code is larger than 1000.

Section 4.2.2 paragraph 5 of RFC 6455 (the WebSocket RFC) makes it clear that the HTTP response should conform to RFC 2616, which specifies that
the status code is a 3-digit integer less than 600.

If I understand correctly, the larger status codes defined in section
7.4.1 of RFC 6455 are never used in HTTP response headers.=C2=A0 Rather, th= ey
are optionally used in WebSocket Close control frames to indicate the
reason for closure.=C2=A0 See section 7.1.6 for more on that.

The WebSocket protocol is quite distinct from the HTTP protocol.
Although HTTP is used initially, after the server returns the HTTP
response with status "101 Switching Protocols", a completely diff= erent
protocol is used henceforth.

So, I don't see anything in the RFCs to justify using the larger status=
codes in HTTP response status line.=C2=A0 Am I misunderstanding something?<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Mark
--00000000000043b8ff058f856661--