Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKQ1sVNd1jyisC44xjVQswvK-Zq3zEhqRGUu6PLAQWWHY-+duQ@mail.gmail.com>
References: 
 <CACsi250=dbRQKnsbE8JSdAZRm5x99gE0sgX3iQ-PHAx77euD1A@mail.gmail.com>
	<13FE9E7F-9620-4BF9-8EA4-57A6314D66BF@greenbytes.de>
	<9CCEFD7E-9ED3-4ED1-8F58-2134DD5310F9@gbiv.com>
	<CACsi252y7nX0kR9+JgSra7Q_5_LVqaR3z6ExPKg=Lhi8zhN4ew@mail.gmail.com>
	<566887B5.2080705@gmail.com>
	<CACsi253sTRbX2dnuq0yRP1sHb8vOos_9QaoYmA3TtYmnNx-Erg@mail.gmail.com>
	<5668CC4F.109@gmail.com>
	<CACsi253q+GanuRzOqBjaOe-h1w8uOcH6uFAcdres=+ig5q6+VA@mail.gmail.com>
	<5668EFDB.1050900@gmail.com>
	<CACsi252HOz3_BO6hJtRTfM=M6oB0ZUXpSvkPmKs8LWP3LCz8xA@mail.gmail.com>
	<EC8AA057-325B-4176-88A8-D9E5073C7F32@greenbytes.de>
	<CAKQ1sVO0pade3_QMnftz38NajZ6v17+9CUz8PW_j3Zj2OvysZA@mail.gmail.com>
	<482349A8-86D1-42EF-A436-C907BDF9DF7D@greenbytes.de>
	<d3ce01d133ff$c50fa930$4f2efb90$@qqmail.nl>
	<566B2071.4080108@gmail.com>
	<CACsi251r2KxQ3dOgXOVfV9nOh-fmyVG0C0g2dS=h2qTMvrjqfw@mail.gmail.com>
	<566B383D.9010306@gmail.com>
	<CACsi251jRbJgEo4aP7AFe0Wfz4KWv8Zcbo6LMUAAkQDDqiJp9g@mail.gmail.com>
	<566B5293.2080803@gmail.com>
	<CAKQ1sVNd1jyisC44xjVQswvK-Zq3zEhqRGUu6PLAQWWHY-+duQ@mail.gmail.com>
Date: Sat, 12 Dec 2015 00:59:54 +0100
Message-ID: 
 <CAKQ1sVMCDhkbEeSFVudX6UHxZeSUJ=TYufnZMPwEKS+aT-TCKw@mail.gmail.com>
Subject: Re: Upgrade Summary
From: Yann Ylavic <ylavic.dev@gmail.com>
To: httpd-dev <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8

On Sat, Dec 12, 2015 at 12:41 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> Hi Jacob,
>
> On Fri, Dec 11, 2015 at 11:47 PM, Jacob Champion <champion.p@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.