On Tue, Mar 8, 2016 at 11:38 AM, Tim Bannister <is...@c8h10n4o2.org.uk> wrote:
> On 8 Mar 2016, at 10:43, Jan Kaluža <jkal...@redhat.com> wrote: > > On 03/08/2016 10:25 AM, Yann Ylavic wrote: > >> On Tue, Mar 8, 2016 at 9:46 AM, Yann Ylavic <ylavic....@gmail.com> > wrote: > >>> On Tue, Mar 8, 2016 at 9:28 AM, Jan Kaluža <jkal...@redhat.com> wrote: > >>>> > >>>> I have chosen FreeListen over the flags > >>> > >>> FWIW, should be take the YAD path, I'd prefer ListenFree (over > >>> FreeListen) to emphasize on the "Listen directive family" with a > >>> prefix... > >> > >> Thinking more about this, I think I second Jim on the wish to have a > >> single Listen directive with some parameter like > >> "options=freebind,backlog:4095,reuseport,...". > > > > Thinking about right syntax for options... > > > > I would personally like something like "Listen [IP-address:]portnumber > [protocol] [option1] [option2] ...". Do we have list of supported protocols > by Listen directive, or we support whatever protocol is there? > > > > If we have explicit list of protocols, then the protocols itself could > become an options. > > > > If not, can it be acceptable, that you always have to define protocol > when you wan to use options? > > That sounds fine too. > > One proviso comes with the idea of a single socket that can serve several > protocols. Think of WebSocket, because it is awkward: from an HTTP > point-of-view, the protocol is initially HTTP and then upgrades to > WebSocket; however, from a WebSocket point of view, the protocol is > WebSocket throughout with a preamble that also happens to resemble HTTP/1.1. > > Using the first model, only one protocol need be specified (but it's not > clear which upgrades are valid for this socket). Using the second model, > the Listen directive needs a way for the admin to specify multiple > protocols. Maybe the answer is for that to be set in the Protocols > directive only? > Keep in mind, the protocol at this layer is simply the 'first responder' to react to an incoming connection, which in your case is the http (or h2?) protocol. The truly critical aspect is what the kernel may do to defer the accept, whether that is looking for a complete http request (or h2c request, someday), or the server must instigate the first response (no incoming bytes from the client) in the case of ftp and similar, or whether this may be an ssl handshake. In the case of WebSocket, that module should be reacting to the headers, the initial protocol state is still HTTP/1.1 from httpd's perspective. > What should the Listen directive look like, ideally, for a > freebind-enabled socket that can be either HTTP or WebSocket, and needs to > specify options? Like this perhaps: > > Listen [2001:db8::a00:20ff:fea7:ccea]:1234 http/1.1,websocket > options=freebind Keep in mind this becomes a nightmare entanglement between optional, loadable support modules and the server core. The existing implementation of listen was flexible enough to provide new arbitrary protocols and resolve these at runtime. There is no reason to distinguish http/1.1, as we would have already done so (e.g. http/1.0, http/0.9 etc). It isn't necessary. If a websocket implementation is properly stacked on top of the core, there is no need for special-casing this interaction. It will be able to speak over http or https, or conceivably even over a single h2, or h2c stream, and will support httpready or freebind mechanics. Re-implementing the handshake entirely in a WebSocket module seems like overkill, much like re-implementing the h2c handshake would be.
