> On 8 Mar 2016, at 18:13, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> 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?
Either mental model might be valid, and I wouldn't presume to say which we should be using. Maybe it's not even feasible to have a single abstraction for how httpd works (because things like HTTP/2, TLS, WebSocket confuse matters by each using their own interpretation). … > 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. I agree, but: Protocols vs. Protocol is already awkward to document and use. I hope we don't accidentally make anything worse. > 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. I chose WebSocket precisely because it's a pain and will illustrate awkward cases. WebSocket over HTTP/2 sounds like a red herring, as normal WebSocket runs over a stream transport (TCP). In RFC 6455 it's an upgrade, and once that upgrade has happened then HTTP is not part of the stack any more. WebSocket Secure runs over TLS but, again, discards HTTP after the upgrade. > Re-implementing the handshake entirely in a WebSocket module seems like > overkill, much like re-implementing the h2c handshake would be. No worries there – sounds like you're more in favour of the first of the two models then? In that case the Listen directive simplifies to one of: Listen [2001:db8::a00:20ff:fea7:ccea]:1234 http options=freebind or: Listen [2001:db8::a00:20ff:fea7:ccea]:1234 options=protocol:http,freebind I'm mindful that there is already an overlap between Listen, Protocol, and Protocols. Making the Listen directive more complex makes sense to me; the added complexity makes it more important to try get it right. My aim here is that we agree on a new definition of Listen that's implementable, understandable, and has a way to specify use of IP_FREEBIND. It's nice to have it extensible but that is not as strong a consideration as the other details. Which choice do people like best? -- Tim Bannister – is...@c8h10n4o2.org.uk
