httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: Upgrade Summary
Date Fri, 11 Dec 2015 23:41:10 GMT
Hi Jacob,

On Fri, Dec 11, 2015 at 11:47 PM, Jacob Champion <> 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).

That does not mean that Protocols handlers can't return "applicative"
errors in handshake (eg. Protocols' auth[nz] failures), but if it
accepts/handles the handshake it MUST respond in the Upgraded
protocol, not in HTTP/1.


View raw message