On Sat, Dec 12, 2015 at 12:41 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > Hi Jacob, > > On Fri, Dec 11, 2015 at 11:47 PM, Jacob Champion <champio...@gmail.com> wrote: >> >> This is where we disagree, for the case of WebSocket and WebSocket alone. >> RFC 6455 4.2.1: >> >> The client's opening handshake consists of the following parts. If >> the server, while reading the handshake, finds that the client did >> not send a handshake that matches the description below (note that as >> per [RFC2616], the order of the header fields is not important), >> including but not limited to any violations of the ABNF grammar >> specified for the components of the handshake, the server MUST stop >> processing the client's handshake and return an HTTP response with an >> appropriate error code (such as 400 Bad Request). > > I guess the RFC is talking about a Websocket server that also > implements HTTP/1 for Websocket purpose only. > In httpd, the protocol parsing is done by the core http module before > any websocket module is called, so there can't (at least shouldn't) be > an invalid HTTP/1 grammar at that level (post_read_request[_header]), > HTTP/1 failures ought to be handled by the core (http module), > including ill/invalid body transfer encoding/length. > So the error could be an unacceptable handshake for the websocket > module, which should then let httpd handle the HTTP/1 request > (ignoring the handshake and probably websocket headers too).
Please note that httpd's default (HTTP/1) handler can always catch "http/1" not in Protocols and return "505 Not Supported" if the request reaches it. The administrator configures acceptable protocols, and httpd gives each one's module a chance, defaulting to HTTP/1 (or 505) if none accepts the handshake.
