Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: Upgrade Summary
To: dev@httpd.apache.org
References: 
 <CACsi250=dbRQKnsbE8JSdAZRm5x99gE0sgX3iQ-PHAx77euD1A@mail.gmail.com>
 <AB1691BE05AE7F4992697F2A0835627AC63BAB94@VOEXM10W.internal.vodafone.com>
 <F7B20D30-D34A-4805-A77D-F64F6428F6E3@greenbytes.de>
 <56660896.c74fc20a.15f56.0ebd@mx.google.com> <56660B43.2060507@gmail.com>
 <6B13DF2B-0586-42BB-B62F-59A7638B697D@greenbytes.de>
 <13FE9E7F-9620-4BF9-8EA4-57A6314D66BF@greenbytes.de>
 <9CCEFD7E-9ED3-4ED1-8F58-2134DD5310F9@gbiv.com>
 <CACsi252y7nX0kR9+JgSra7Q_5_LVqaR3z6ExPKg=Lhi8zhN4ew@mail.gmail.com>
From: Jacob Champion <champion.p@gmail.com>
Message-ID: <566887B5.2080705@gmail.com>
Date: Wed, 9 Dec 2015 11:57:41 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CACsi252y7nX0kR9+JgSra7Q_5_LVqaR3z6ExPKg=Lhi8zhN4ew@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/09/2015 09:17 AM, William A Rowe Jr wrote:
> On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding <fielding@gbiv.com
> <mailto:fielding@gbiv.com>> wrote:
>
>     > On Dec 8, 2015, at 2:07 AM, Stefan Eissing <stefan.eissing@greenbytes.de <mailto:stefan.eissing@greenbytes.de>>
>     wrote:
>     >
>     > Open:
>     > 1. Protocols like Websocket need to take over the 101 sending themselves in the "switch protocol" phase. (correct, Jacob?). Should we delegate the sending of the 101 to the protocol switch handler?
>
>     That seems unlikely.
>
>
> Agreed, anywhere we like we can send the 101 with headers, all that the
> websocket module needed to do was to set up output_headers or perhaps we
> add intermediate_output_headers in the request structure.  Easily fixed
> so this code is still common...

+1.

>     This should be easily handled by adding a filter that translates the
>     HTTP/1
>     incoming body (if any) to a single channel of the new protocol.
>     Just fake it.
>     There is no need to wait or set aside the bytes, unless that is
>     desired for
>     other reasons (e.g., denial of denial of service attacks).
>
> However, we must read the request body complete before the input handler
> is toggled to the h2c state, or before we switch to any bidirectional
> protocol, e.g. TLS or otherwise.

For my own clarification: this is a protocol-specific limitation, right? 
As in, you can't begin a TLS handshake without first draining the 
incoming request body off the connection.

>
>     > 3. When to do the upgrade dance:
>     >  a post_read_request: upgrade precedes authentication
>     >  b handler: upgrade only honored on authenticated and otherwise ok requests
>     >  c both: introduce separate hooks? have an additional parameter? more complexity
>
>     (a).  We do want to upgrade non-ok responses.  If the "new" protocol
>     wants to
>     send a canned HTTP/1.1 error, it can do so without our help.
>
>
> +1 in the case of h2c, TLS.  I understand that websocket upgrades are
> going to be conditional on authentication. As long as we give websocket
> the chance to upgrade in the fixups or similar phase, after auth, then
> websocket can ignore the Upgrade: websocket offer after inspecting authnz.

Sounds reasonable. Unfortunate in the sense that it's possible for a 
module implementing the Upgrade API to screw up and accidentally ignore 
authnz, but since most protocols we're talking about can safely upgrade 
first and respond with 401/3 on the new protocol, I don't see much of an 
alternative.

>     > 4. status code of protocol switch handler: if we move the task of 101 sending, the switch handler might not do it and keep the connection on the "old" protocol. Then a connection close is not necessary. So, we would do the close only when the switch handler returns APR_EOF.
>
>     Eh?
>
> I'm wondering the same, the new protocol loop can do all of the
> connection handling, no need for the protocol switch to do anything but
> continue, if the connection is ended in the protocol handler, it's gone.

Why leave it up to the protocol handler (to potentially get wrong)? Are 
there any cases where, after a successful upgrade, we would not want to 
close the connection upon returning from the protocol handler?

--Jacob