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 <m...@netris.org> wrote: > Hi, > > Nala Ginrut <nalagin...@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 >
