RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: vrijdag 11 december 2015 10:20 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > Regarding request bodies: > - websocket will never switch on request bodies &

Re: Upgrade Summary

On Fri, Dec 11, 2015 at 10:20 AM, Stefan Eissing wrote: > >> Am 11.12.2015 um 02:22 schrieb Yann Ylavic : >> >> On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing >> wrote: >>> Given all the input on this thread, I

Re: Upgrade Summary

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

Re: Upgrade Summary

On Fri, Dec 11, 2015 at 2:55 PM, Jacob Champion wrote: > On 12/11/2015 12:12 PM, William A Rowe Jr wrote: > >> On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion > > wrote: >> >> On 12/11/2015 02:36 AM, Bert Huijben

Re: Upgrade Summary

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

Re: Upgrade Summary

n 12/11/2015 02:24 PM, William A Rowe Jr wrote: On Fri, Dec 11, 2015 at 2:55 PM, Jacob Champion > wrote: That additional constraint doesn't conflict with any part of HTTP/1.1, as far as I can tell. Returning 4xx directly to an Upgrade

RE: Upgrade Summary

To: httpd-dev Subject: Re: Upgrade Summary On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > Given all the input on this thread, I arrive at the following pseudo code: Thanks for _compiling_ this thread, quite exhaustive :) I wonder if we could

RE: Upgrade Summary

from Mail for Windows 10 From: Yann Ylavic Sent: zaterdag 12 december 2015 01:46 To: Bert Huijben Subject: Re: Upgrade Summary On Sat, Dec 12, 2015 at 12:48 AM, Bert Huijben <b...@qqmail.nl> wrote: > If you request an upgrade to TLS on your initial request, upgrading with a > body migh

Re: Upgrade Summary

> Am 11.12.2015 um 02:22 schrieb Yann Ylavic : > > On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing > wrote: >> Given all the input on this thread, I arrive at the following pseudo code: > > Thanks for _compiling_ this thread, quite

Re: Upgrade Summary

On 12/11/2015 02:36 AM, Bert Huijben wrote: -Original Message- From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Protocol implementations should make up their minds in the "propose" phase, I think, because once a protocol gets selected, the upgrade *should* succeed unless the

Re: Upgrade Summary

On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion wrote: > On 12/11/2015 02:36 AM, Bert Huijben wrote: > >> -Original Message- >>> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >>> Protocol implementations should make up their minds in the "propose" >>>

Re: Upgrade Summary

Jacob, thanks for the code! I will let this and my pseudo code stew over the weekend and then probably next week start the changes to upgrade handling. //Stefan > Am 10.12.2015 um 23:18 schrieb Jacob Champion : > > Okay, I finally have actual code to share. This is the

Re: Upgrade Summary

On 12/11/2015 12:12 PM, William A Rowe Jr wrote: On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion > wrote: On 12/11/2015 02:36 AM, Bert Huijben wrote: Not upgrading is 100% better than failing. ...except for those protocols for

Re: Upgrade Summary

On 12/10/2015 02:45 AM, Bert Huijben wrote: Websockets are different… and in some ways not really an upgrade of the connection… more like a hostile takeover with a final operation to a target Ha! Yes -- although from the point of view of HTTP/1.1, all successful upgrades are hostile

Re: Upgrade Summary

Okay, I finally have actual code to share. This is the original experimental pre_protocol_switch hook that Stefan and I were talking about a while ago [1], rebased onto 2.4.18. The two patches are available at https://github.com/jchampio/httpd/commits/dev/websocket-protocols It is *not*

Re: Upgrade Summary

On Thu, Dec 10, 2015 at 11:46 AM, Stefan Eissing wrote: > Given all the input on this thread, I arrive at the following pseudo code: Thanks for _compiling_ this thread, quite exhaustive :) I wonder if we could let each Protocols module hook wherever appropriate in

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: donderdag 10 december 2015 11:47 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > > Given all the input on this thread, I arrive at the following pseudo code: >

RE: Upgrade Summary

the connection closes. Bert From: William A Rowe Jr [mailto:wr...@rowe-clan.net] Sent: donderdag 10 december 2015 07:40 To: httpd <dev@httpd.apache.org> Subject: Re: Upgrade Summary On Wed, Dec 9, 2015 at 9:22 PM, Jacob Champion <champio...@gmail.com <ma

Re: Upgrade Summary

Given all the input on this thread, I arrive at the following pseudo code: 1. Post Read Request Hook: if (Upgrade: request header present) { collect protocol proposals; ps = protocol with highest preference from proposals; if (ps && ps

Re: Upgrade Summary

On Fri, Dec 11, 2015 at 2:22 AM, Yann Ylavic wrote: > > Here I would use ap_add_output_filter(switch_protocol_filter, r); with > switch_protocol_filter() which would flush out the 101 response (or > not) based on r->need_upgrade and r->current_protocol, before any >

Re: Upgrade Summary

> Am 10.12.2015 um 14:57 schrieb Mike Rumph : > > Question below: > > On 12/10/2015 2:46 AM, Stefan Eissing wrote: >> int xxx_switch(conn_rec *c, request_rec *r, server_rec *s, >> const char *protocol, int phase) >> { >> apr_status_t

Re: Upgrade Summary

Question below: On 12/10/2015 2:46 AM, Stefan Eissing wrote: int xxx_switch(conn_rec *c, request_rec *r, server_rec *s, const char *protocol, int phase) { apr_status_t stats; if (strcmp(my_protocol, protocol)) { Do you mean "if

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding wrote: > > On Dec 8, 2015, at 2:07 AM, Stefan Eissing > wrote: > > > > Open: > > 1. Protocols like Websocket need to take over the 101 sending themselves > in the "switch protocol" phase. (correct,

Re: Upgrade Summary

On Wed, Dec 9, 2015 at 1:57 PM, Jacob Champion wrote: > On 12/09/2015 09:17 AM, William A Rowe Jr wrote: > >> On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding > > wrote: >> >> This should be easily handled by adding a filter

Re: Upgrade Summary

On Wed, Dec 9, 2015 at 6:50 PM, Jacob Champion wrote: > On 12/09/2015 03:19 PM, William A Rowe Jr wrote: > >> Because the request body is inbound already at some state of completion >> or incomplete transmission, it is competing with the TLS handshake, which >> is a

Re: Upgrade Summary

On 12/09/2015 03:19 PM, William A Rowe Jr wrote: Because the request body is inbound already at some state of completion or incomplete transmission, it is competing with the TLS handshake, which is a bidirectional engagement with the same socket between the user agent and server. Unlike h2c and

Re: Upgrade Summary

On Wed, Dec 9, 2015 at 9:22 PM, Jacob Champion wrote: > On 12/09/2015 05:19 PM, William A Rowe Jr wrote: > >> >> _If_ all the other protocols worked like WebSocket and required >> authnz before an upgrade could succeed, it wouldn't make sense for >> each upgrade

Re: Upgrade Summary

On 12/09/2015 05:19 PM, William A Rowe Jr wrote: The "handler phase" is simply the establishment of a bidirectional WebSocket connection. If the client did something pathological like sending a request body with their GET request, I think that needs to go into the bit bucket

Re: Upgrade Summary

On 12/09/2015 09:17 AM, William A Rowe Jr wrote: On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding > wrote: > On Dec 8, 2015, at 2:07 AM, Stefan Eissing > wrote: > >

Re: Upgrade Summary

Bert, why can't you use h2c in direct mode? I assume you could store server support for this in the checkout meta data somewhere. //Stefan > Am 08.12.2015 um 11:30 schrieb Bert Huijben : > >> -Original Message- >> From: Stefan Eissing

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 11:55 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > > > > Am 08.12.2015 um 11:44 schrieb Yann Ylavic <ylavic@gmail.com>:

Re: Upgrade Summary

> Am 08.12.2015 um 12:18 schrieb Yann Ylavic : > > On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing > wrote: >> >> Am 08.12.2015 um 11:44 schrieb Yann Ylavic : >>> >>> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing wrote: > > Am 08.12.2015 um 11:44 schrieb Yann Ylavic : >> >> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing >>> >>> PS. Re 5: with change 1+4, a TLS upgrade switcher could install an output >>>

RE: Upgrade Summary

> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 8 december 2015 12:41 > To: dev@httpd.apache.org > Subject: RE: Upgrade Summary > > I don't think we should require all auth to happen on HTTP/1.1. If you want to go for equiv

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 12:18 PM, Yann Ylavic wrote: > On Tue, Dec 8, 2015 at 11:54 AM, Stefan Eissing > wrote: >> >> Am 08.12.2015 um 11:44 schrieb Yann Ylavic : >>> >>> On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 13:22 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > > > > Am 08.12.2015 um 12:40 schrieb Bert Huijben <b...@qqmail.n

Re: Upgrade Summary

> Am 08.12.2015 um 14:08 schrieb Bert Huijben : > [...] > (I'm pretty sure we find new interesting proxy server scenarios :-( ) Not only that. Someone tested h2c against his server from various Tor exit nodes and got a failure rate > 10% because of network middle boxes... Fun

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing wrote: > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies are

Re: Upgrade Summary

> Am 08.12.2015 um 11:44 schrieb Yann Ylavic : > > On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing > wrote: >> [...] >> Open: >> 1. Protocols like Websocket need to take over the 101 sending themselves in >> the "switch protocol" phase.

Re: Upgrade Summary

> Am 08.12.2015 um 12:40 schrieb Bert Huijben <b...@qqmail.nl>: >> -Original Message- >> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >> Sent: dinsdag 8 december 2015 11:55 >> To: dev@httpd.apache.org >> Subject: Re: Upgrade Summary &g

Re: Upgrade Summary

ytes.de] >>> Sent: dinsdag 8 december 2015 13:22 >>> To: dev@httpd.apache.org >>> Subject: Re: Upgrade Summary >>> >>> >>>> Am 08.12.2015 um 12:40 schrieb Bert Huijben <b...@qqmail.nl>: >>>>> -Original Message- &

Re: Upgrade Summary

enbytes.de] >> Sent: dinsdag 8 december 2015 13:22 >> To: dev@httpd.apache.org >> Subject: Re: Upgrade Summary >> >> >>> Am 08.12.2015 um 12:40 schrieb Bert Huijben <b...@qqmail.nl>: >>>> -Original Message- >>>>

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 11:07 > To: dev@httpd.apache.org > Subject: Upgrade Summary > > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade

RE: Upgrade Summary

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: dinsdag 8 december 2015 13:54 > To: dev@httpd.apache.org > Subject: Re: Upgrade Summary > > I see. Delta-V goodies. > > My proposal therefore is: > - keep the upg

Re: Upgrade Summary

On 12/08/2015 02:07 AM, Stefan Eissing wrote: C. if a protocol supports upgrade on request bodies is up to the protocol implementation and needs to be checked in the "propose" phase Only if the module's intent is to simply ignore upgrade requests if they have bodies. Other modules might

Re: Upgrade Summary

On Tue, Dec 8, 2015 at 3:43 PM, Jacob Champion wrote: > On 12/08/2015 01:03 PM, Jacob Champion wrote: > >> - The module that won the proposal is given one last chance to check the >> incoming request and fail the upgrade with an immediate HTTP response. >> > > And to add to

Re: Upgrade Summary

> On Dec 8, 2015, at 2:07 AM, Stefan Eissing > wrote: > > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies

Re: Upgrade Summary

On 12/08/2015 01:03 PM, Jacob Champion wrote: - The module that won the proposal is given one last chance to check the incoming request and fail the upgrade with an immediate HTTP response. And to add to this, for completeness: mod_websocket also needs to add any required headers (e.g.

Re: Upgrade Summary

On 12/08/2015 02:30 AM, Bert Huijben wrote: The TLS and H2C upgrades both begin in one form and end in a different form. Websockets are kind of different in that they require a bad request response in a specific case. I'm not sure in which protocol this error needs to be send though. For