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:59:54 GMT
On Sat, Dec 12, 2015 at 12:41 AM, Yann Ylavic <> wrote:
> 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).

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.

View raw message