unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Support Websocket status code
@ 2019-07-26  6:06 Nala Ginrut
  2019-07-29  6:57 ` Nala Ginrut
  2019-08-07  6:52 ` Mark H Weaver
  0 siblings, 2 replies; 4+ messages in thread
From: Nala Ginrut @ 2019-07-26  6:06 UTC (permalink / raw)
  To: guile-devel

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

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.
This breaks Artanis Websocket handler to return 500, so that the client has
no way to detect the actual problem.

Is there any plan to support it?
Or maybe someone is just waiting for a patch? ;-)

Best regards.

[-- Attachment #2: Type: text/html, Size: 766 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Support Websocket status code
  2019-07-26  6:06 Support Websocket status code Nala Ginrut
@ 2019-07-29  6:57 ` Nala Ginrut
  2019-08-07  6:52 ` Mark H Weaver
  1 sibling, 0 replies; 4+ messages in thread
From: Nala Ginrut @ 2019-07-29  6:57 UTC (permalink / raw)
  To: guile-devel


[-- Attachment #1.1: Type: text/plain, Size: 812 bytes --]

Here is a patch to add necessary status code, and avoid checking failure
when building response.
Based on branch stable-2.2

Thanks!


On Fri, Jul 26, 2019 at 2:06 PM Nala Ginrut <nalaginrut@gmail.com> wrote:

> 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.
> This breaks Artanis Websocket handler to return 500, so that the client
> has no way to detect the actual problem.
>
> Is there any plan to support it?
> Or maybe someone is just waiting for a patch? ;-)
>
> Best regards.
>
>

[-- Attachment #1.2: Type: text/html, Size: 1304 bytes --]

[-- Attachment #2: 0001-Add-Websocket-status-code.patch --]
[-- Type: text/x-patch, Size: 1733 bytes --]

From 757bf959e364485f105a977c3f971b9252dfb4db Mon Sep 17 00:00:00 2001
From: Nala Ginrut <mulei@gnu.org>
Date: Mon, 29 Jul 2019 14:55:37 +0800
Subject: [PATCH] Add Websocket status code

---
 module/web/response.scm | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/module/web/response.scm b/module/web/response.scm
index 06e1c6dc1..77a856a48 100644
--- a/module/web/response.scm
+++ b/module/web/response.scm
@@ -118,7 +118,7 @@ the headers are each run through their respective validators."
               (non-negative-integer? (car version))
               (non-negative-integer? (cdr version))))
     (bad-response "Bad version: ~a" version))
-   ((not (and (non-negative-integer? code) (< code 600)))
+   ((not (and (non-negative-integer? code) (<= code 1015)))
     (bad-response "Bad code: ~a" code))
    ((and reason-phrase (not (string? reason-phrase)))
     (bad-response "Bad reason phrase" reason-phrase))
@@ -167,7 +167,20 @@ the headers are each run through their respective validators."
     (502 . "Bad Gateway")
     (503 . "Service Unavailable")
     (504 . "Gateway Timeout")
-    (505 . "HTTP Version Not Supported")))
+    (505 . "HTTP Version Not Supported")
+    (1000 . "Normal Closure")
+    (1001 . "Going Away")
+    (1002 . "Protocol error")
+    (1003 . "Unsupported Data")
+    (1004 . "Reserved")
+    (1005 . "No status received")
+    (1006 . "Abnormal Closure")
+    (1007 . "Invalid frame payload data")
+    (1008 . "Policy Violation")
+    (1009 . "Message Too Big")
+    (1010 . "Mandatory Ext.")
+    (1011 . "Internet Server Error")
+    (1015 . "TLS handshake")))
 
 (define (code->reason-phrase code)
   (or (assv-ref *reason-phrases* code)
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: Support Websocket status code
  2019-07-26  6:06 Support Websocket status code Nala Ginrut
  2019-07-29  6:57 ` Nala Ginrut
@ 2019-08-07  6:52 ` Mark H Weaver
  2019-08-07 11:39   ` Nala Ginrut
  1 sibling, 1 reply; 4+ messages in thread
From: Mark H Weaver @ 2019-08-07  6:52 UTC (permalink / raw)
  To: Nala Ginrut; +Cc: guile-devel

Hi,

Nala Ginrut <nalaginrut@gmail.com> 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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Support Websocket status code
  2019-08-07  6:52 ` Mark H Weaver
@ 2019-08-07 11:39   ` Nala Ginrut
  0 siblings, 0 replies; 4+ messages in thread
From: Nala Ginrut @ 2019-08-07 11:39 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guile-devel

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

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 <mhw@netris.org> wrote:

> Hi,
>
> Nala Ginrut <nalaginrut@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 2111 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-08-07 11:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-26  6:06 Support Websocket status code Nala Ginrut
2019-07-29  6:57 ` Nala Ginrut
2019-08-07  6:52 ` Mark H Weaver
2019-08-07 11:39   ` Nala Ginrut

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).