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: <06B0C8CC-8CE9-4617-A213-66D41BBFFF3D@c8h10n4o2.org.uk>
References: <56DD68E5.2040309@redhat.com>
	<3B39341D-5870-4182-B8F3-33A794D38343@jaguNET.com>
	<56DDDC53.1060103@redhat.com>
	<CACsi253rUFf7zY=F3EJrRGJTWUSckV590ypunAcUvkFLVMDmfQ@mail.gmail.com>
	<CAGBAQ47FRpVRV7ymht-weDRmPwNW0yA94cxQXFAOM_Ns=HteCg@mail.gmail.com>
	<CACsi2507SbFCA4zG-EJca81MGzBwOsL_gjA4_GeecEi+=n9GBQ@mail.gmail.com>
	<56DE8D43.40505@redhat.com>
	<CAKQ1sVMXnU0wkLeDWfdvcfTBNaZqw_SgJpgM9LiCN2iyzKv8hg@mail.gmail.com>
	<CAKQ1sVOaVLX=jg-V6vZ1A-8XFRt4xHse_+FbHyZ-eQ5SChQKfA@mail.gmail.com>
	<56DEACC7.3080007@redhat.com>
	<06B0C8CC-8CE9-4617-A213-66D41BBFFF3D@c8h10n4o2.org.uk>
Date: Tue, 8 Mar 2016 12:13:30 -0600
Message-ID: 
 <CACsi252aS8aH+3hC9R1QnE0CTgv4n5PfpeOPFRo42K+V7XMZjg@mail.gmail.com>
Subject: Re: [PATCH] Add "FreeListen" to support IP_FREEBIND
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a113fecfce86f19052d8d892e

--001a113fecfce86f19052d8d892e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 8, 2016 at 11:38 AM, Tim Bannister <isoma@c8h10n4o2.org.uk>
wrote:

> On 8 Mar 2016, at 10:43, Jan Kalu=C5=BEa <jkaluza@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.dev@gmail.com>
> wrote:
> >>> On Tue, Mar 8, 2016 at 9:28 AM, Jan Kalu=C5=BEa <jkaluza@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=3Dfreebind,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 protoco=
ls
> 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 t=
o
> specify options? Like this perhaps:
>
> Listen [2001:db8::a00:20ff:fea7:ccea]:1234 http/1.1,websocket
> options=3Dfreebind


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 resolv=
e
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 wil=
l
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.

--001a113fecfce86f19052d8d892e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 8, 2016 at 11:38 AM, Tim Bannister <span dir=3D"ltr">&lt;<a href=3D=
"mailto:isoma@c8h10n4o2.org.uk" target=3D"_blank">isoma@c8h10n4o2.org.uk</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 8=
 Mar 2016, at 10:43, Jan Kalu=C5=BEa &lt;<a href=3D"mailto:jkaluza@redhat.c=
om">jkaluza@redhat.com</a>&gt; wrote:<br>
&gt; On 03/08/2016 10:25 AM, Yann Ylavic wrote:<br>
&gt;&gt; On Tue, Mar 8, 2016 at 9:46 AM, Yann Ylavic &lt;<a href=3D"mailto:=
ylavic.dev@gmail.com">ylavic.dev@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; On Tue, Mar 8, 2016 at 9:28 AM, Jan Kalu=C5=BEa &lt;<a href=3D=
"mailto:jkaluza@redhat.com">jkaluza@redhat.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I have chosen FreeListen over the flags<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; FWIW, should be take the YAD path, I&#39;d prefer ListenFree (=
over<br>
&gt;&gt;&gt; FreeListen) to emphasize on the &quot;Listen directive family&=
quot; with a<br>
&gt;&gt;&gt; prefix...<br>
&gt;&gt;<br>
&gt;&gt; Thinking more about this, I think I second Jim on the wish to have=
 a<br>
&gt;&gt; single Listen directive with some parameter like<br>
&gt;&gt; &quot;options=3Dfreebind,backlog:4095,reuseport,...&quot;.<br>
&gt;<br>
&gt; Thinking about right syntax for options...<br>
&gt;<br>
&gt; I would personally like something like &quot;Listen [IP-address:]portn=
umber [protocol] [option1] [option2] ...&quot;. Do we have list of supporte=
d protocols by Listen directive, or we support whatever protocol is there?<=
br>
&gt;<br>
&gt; If we have explicit list of protocols, then the protocols itself could=
 become an options.<br>
&gt;<br>
&gt; If not, can it be acceptable, that you always have to define protocol =
when you wan to use options?<br>
<br>
</span>That sounds fine too.<br>
<br>
One proviso comes with the idea of a single socket that can serve several p=
rotocols. Think of WebSocket, because it is awkward: from an HTTP point-of-=
view, the protocol is initially HTTP and then upgrades to WebSocket; howeve=
r, from a WebSocket point of view, the protocol is WebSocket throughout wit=
h a preamble that also happens to resemble HTTP/1.1.<br>
<br>
Using the first model, only one protocol need be specified (but it&#39;s no=
t clear which upgrades are valid for this socket). Using the second model, =
the Listen directive needs a way for the admin to specify multiple protocol=
s. Maybe the answer is for that to be set in the Protocols directive only?<=
br></blockquote><div><br></div><div>Keep in mind, the protocol at this laye=
r is simply the &#39;first responder&#39; to react</div><div>to an incoming=
 connection, which in your case is the http (or h2?) protocol.</div><div>Th=
e truly critical aspect is what the kernel may do to defer the accept, whet=
her</div><div>that is looking for a complete http request (or h2c request, =
someday), or the</div><div>server must instigate the first response (no inc=
oming bytes from the client)</div><div>in the case of ftp and similar, or w=
hether this may be an ssl handshake.</div><div><br></div><div>In the case o=
f WebSocket, that module should be reacting to the headers,</div><div>the i=
nitial protocol state is still HTTP/1.1 from httpd&#39;s perspective.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
Listen [2001:db8::a00:20ff:fea7:ccea]:1234 http/1.1,websocket options=3Dfre=
ebind</blockquote><div><br></div><div>Keep in mind this becomes a nightmare=
 entanglement between optional,</div><div>loadable support modules and the =
server core.=C2=A0 The existing implementation</div><div>of listen was flex=
ible enough to provide new arbitrary protocols and resolve</div><div>these =
at runtime.=C2=A0 There is no reason to distinguish http/1.1, as we would</=
div><div>have already done so (e.g. http/1.0, http/0.9 etc).=C2=A0 It isn&#=
39;t necessary.</div><div><br></div><div>If a websocket implementation is p=
roperly stacked on top of the core, there</div><div>is no need for special-=
casing this interaction.=C2=A0 It will be able to speak over</div><div>http=
 or https, or conceivably even over a single h2, or h2c stream, and will</d=
iv><div>support httpready or freebind mechanics.</div><div><br></div><div>R=
e-implementing the handshake entirely in a WebSocket module seems</div><div=
>like overkill, much like re-implementing the h2c handshake would be.</div>=
<div><br></div><div>=C2=A0</div></div></div></div>

--001a113fecfce86f19052d8d892e--