►
From YouTube: Envoy Community Meeting - 2018-06-05
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
B
While
we're
waiting
for
people
to
come
that
that
bug
the
the
one
where
there's
that
assert
Alyssa
on
the
on
the
message
begin,
headers
I
think
it's
a
bug,
actually
an
HTTP
parser
yeah.
Do
you
do
you
know
off
the
top
of
your
head,
whether
before
the
beginning
of
a
before
the
beginning
of
a
response
so
like
before
it
says
like
HTTP
one
one?
B
Are
you
allowed
to
have
CR
LF
in
there,
because
because
the
code
in
HTTP,
parser
in
certain
paths
makes
it
seem
like
you
can,
but
basically
what's
happening,
is
that
if
there's
a
carriage
return
or
line
feed
before
the
beginning
of
the
response,
it'll
fire,
the
on
message
begin
call
back
multiple
times.
So
there's
a
so
so
it's
it's.
Definitely
a
bug
in
the
parser
I'm,
just
not
sure,
if,
like
it
should
be
allowed
or
or
not,.
C
B
I
mean
I,
I,
I,
think
I'm
just
going
to
add
a
test
and
like
because
there's
three
different
cases
where
this
happens
and
in
two
of
the
other
cases
it
just
ignores
carriage
return
line
feed
in
this
one
case
because
of
the
bug
every
time
you
get
a
care
to
turn
or
line
feed
instead
of
just
skipping,
it
it'll
fire.
The
on
message
begin
callback.
So
that's
that's
why
it's
all
going
haywire
but
but
like
based
on
the
spec.
B
B
B
C
C
B
C
B
Yeah
I
mean
so
there's
the
there's.
The
fuzz
test,
failure
that
Harvey
found
so
iid
bug
that
I'm
not
sure
if
that's
the
same
issue
as
as
the
websocket
one
that
was
reported,
I
think
it
probably
is,
but
I
have
to
test
it,
but
like
because
I'm
guessing
that
the
WebSocket
thing
for
some
reason
is
like
sending
either
a
carriage
return
or
line
feed
before
the
actual
response.
That's
my
guess,
but
like
I
will
I
will
go
and
debug
it
all
right.
Let's
see
so.
B
We
have
a
couple
of
things
on
the
agenda.
I
guess
is,
is
Greg
on
the
call
oh
yeah
I'm
here,
okay,
cool,
so
I,
don't
know,
I
was
thinking.
We
could
do
the
like,
just
the
quick
items
first
and
then
we
could
talk
about
the
WebSocket
stuff.
Okay,
I
see
the
first
quick
one
is
it.
Is.
It
came
up
during
code
review
that,
historically
in
release
notes,
we
have
not
put
bug
fixes
I,
don't
really
have
a
strong
opinion.
I,
like
I,
think
some
projects
they'll
break
out,
they'll
they'll
break
out.
B
D
B
All
right
between
then
dinner
yeah,
that's
fine,
I
mean
yeah.
It
kind
of
it
seems
like
unnecessary
overhead
to
like
list
every
individual
bug-fix.
So
that's
fine
I
mean
why
don't
I
will
do
a
PR
to
the
PR
template
that
basically
says
roughly
that
that,
like
we
can
use
our
judgment
as
to
if
it's
a
pretty
severe
bug
fix
that
we
can,
we
can
add
it
any
anyone
have
any
objections
to
that.
B
E
So
so
I
continued
to
grind
through
the
file
descriptor,
you
know
socket
call
replacement
I've
just
about
got
the
PR
ready
to
do
an
intial
push
the
place
where
I'm
gonna
need
some
input
and
some
help
is
you
know
how
do
we?
How
do
you
want
us
to
to
take
the
you
know,
network
service
factory
and
hook
that
into
the
config
stuff?
That
was
kind
of
a
little
confusing
to
me
about
where
to
put
that
and
so
I
think
we
can
just
discussed
that
yeah.
E
Right
well,
I,
pretty
much
have
the
giant
PR
done,
which
I
think
is
is
is
certainly
worth
having
as
a
roadmap,
and
then
we
can
look
at
so
I'll
I'll
push
that
the
next
day
or
so
yep,
and
then
we
can.
You
know
we
can
roll
out
an
implementation
thing.
So
I
mean
some
of
the
minor
questions.
Are
you
know
there
are
some
socket
calls
in
the
OS
syscalls
class
singleton
class
and
you
know:
does
it
have
value
to
to
leave
those
around
I,
initially
ripped
them
out,
but
then
today
I
was
thinking.
C
D
E
E
That
was
really
that
thought.
I
had
last
night
when
I
was
once
winning
through.
Some
of
my
cleanup
was
when,
when
we
start
to
test
this
stuff,
whether
that
still
has
value
it
probably
does,
and
so
I'm
still
I
mean
there
are
still
a
bunch
of
places
and
well
I'll
push
something
sooner
rather
than
later.
E
At
this
point,
because
I
think
I've
got
enough
volume
to
generate
a
good
discussion,
but
there's
still
a
lot
of
places
even
with
that,
where
they're,
just
natives,
you
know
socket
calls
that
exist
around
the
codebase
that
ideally,
we
want
to
get
rid
of
those,
but
we
want
to
do
that
in
a
structured
fashion.
Yeah.
B
B
We're
gonna
end
up
eventually
porting
the
code
to
Windows
and
I
mean
it's
like
there's
just
there's
a
whole
bunch
of
different
reasons.
Why
they
like
being
super
useful,
so
I
mean
I.
Think
all
of
the
work
that
you're
doing
is
gonna
be
great
it
just
it
doesn't
have
to
be
I
guess
what
we're
saying
is.
It
doesn't
have
to
be
done
in
like
one
giant
drop
like
if
it
makes
sense
to
do
it.
Incrementally.
That's
probably
right.
Well,.
B
I
mean
let's
just
let's:
just
look
at
the
JMP
are
like
I
I,
actually
think.
For
the
most
part,
it's
going
to
be
fairly
mechanical
or
it
or
it
should
be
so
right.
Let's
just
see
it
and
then,
if
it
looks
like
there's
some
obvious
places
where
we
could
split
it
up,
you
know
we
can
do.
That
sounds
like
a
plan.
Great
ok,
WebSocket,
maybe
either
ELISA
or
our
Greg.
Could
you
catch
everyone
up
on
the
conversation
because
it's
it's
kind
of
complicated
sure.
C
So
essentially,
right
now,
for
those
of
you
not
terribly
familiar
with
WebSockets,
essentially
you
send
it
each.
He
had
her
saying
I'd
like
to
upgrade
to
WebSockets
and
then
everything
following
that
upgrade
the
and
they
there
was
a
response
that
are
saying:
yes,
your
upgrade
to
treated
or
no
and
then
from
then
on
kind
of
what
normally
would
have
been
aged
to
be
payload
is
WebSocket
data.
So
right
now
the
weights
implemented
an
envoy
for
each
to
be
one.
C
One
is
envoy,
intercepts
those
those
headers
says:
greatnesses
WebSocket
and
then
basically
detaches
the
rest
of
the
request
processing
to
the
TZ
proxy
session.
Saying
look.
This
is
no
longer
HTTP,
we're
just
gonna
proxy,
the
WebSocket
payload
upstream
and
be
done
with.
So
there
was
a
request
saying:
okay,
that's
all
well
and
good,
but
we'd
like
it.
If
the
WebSocket
request,
headers
went
through
the
normal
age
to
be
filter
chain,
because
the
the
upgrade
headers
are
headers,
so
that
would
be
nice.
C
Meanwhile,
there's
a
second
issue
that
about
how
to
handle
WebSocket
for
h2
and
there's
a
spec
in
progress
theoretically
should
be
ratified
in
the
next
week
or
so,
if
it
hasn't
already
saying
basically
for
each
to
be
to
where
you
can't
take
over
the
entire
upstream
connection,
you
would
use
connect
to
effectively
tunnel
this
WebSocket
data
on
one
h2
stream,
which
makes
a
lot
of
sense.
But
the
problem
is
at
that
point:
the
h2
WebSocket,
the
headers
and
all
the
data
would
go
through
your
headers
in
and
normally
to
be,
data
calls.
C
Meanwhile,
the
HTTP
paths
were
doing
it
with
this
weird
kind
of
hybrid
of
handling
each
to
be
headers
eventually
and
then,
and
then
tcp
proxied
handoff.
For
the
data
doing
it
differently
seems
like
it's
going
to
cause
a
lot
of
confusion
in
the
long
run,
especially
because,
if
you're
upstream
is
auto,
is
doing
each
to
me
or
HTTP
to
you.
B
Yeah
I
mean
my
my
idea,
which
would
be
a
bunch
of
work,
is
to
actually
make
make
new
filters
and
then
basically
have
parallel.
Filter
stack
so
like
and
I
think,
a
lot
of
the
filters
that
you
have
could
implement
both
interfaces,
but
that
would
basically
allow
you
to
specify
even
like
on
a
per
route
basis,
potentially
that
you
could
fork
off
or
maybe
even
knocked
her
route,
but
like
on
a
on
a
HTTP
connection
manager
level.
B
You
could
have
like
a
like
a
WebSocket
filter
stack
and
then
like
a
non
WebSocket
filter
stack
and
that
would
that
would
require
filters
to
opt
in
to
basically
being
WebSocket
aware.
Instead
of
suddenly
getting
into
a
situation
in
which
you
know,
you
have
filters
that
might
now
be
getting
WebSocket
data
and
then
like
some
of
the
calls
might
be
different.
So,
for
example,
like
you,
don't
need
a
hundred
continue
or
like
those
those
types
of
things.
So
that
was
one
idea
that
came
to
mind.
B
It
doesn't
I
mean
I,
guess
again
like
this
is
mostly
brainstorming.
It
doesn't
even
necessarily
mean
that
we
have
to
define
like
new
interfaces
in
code.
It
would
more
just
mean
that
you
would
have
to
as
a
user,
effectively
opt
in
say
that,
like
these
are
the
filters
that
run
if
it's
a
if
it's
a
WebSocket
connection
right.
B
So
right
so
like
it
would
be
more
of
a
config
thing
where
then,
what
the
so
right.
Now,
if
you
look
at
the
connection
manager
code,
we
end
up
instantiating.
The
filter
stack
like
right
when
the
stream
is
created,
but
there's
no
technical
reason
that
we
have
to
do
that
like
we
could
actually
wait
until
we
get
headers
complete.
B
like
TCP
proxy
stuff
so
like,
instead
of
the
TCP
proxy
being
bolted
into
the
HTTP
connection
manager,
you
would
allow
it
to
flow
through
and
then
at
the
end
of
the
WebSocket
chain
is
like
a
WebSocket,
router
and
again,
like
maybe
that's
mostly
the
same
code
as
the
current
router
like
maybe
it's
the
same
code.
I,
don't
I,
don't
really
know,
but
but
that
could
take
care
of
the
is
it
HTTP
1
1
like
maybe
do
the
TCP
proxy
thing
like?
B
C
C
B
Right
so
I'm
actually
suggesting
to
get
rid
of
like
the
the
way
that
we
do
today,
which
is
to
bolt
it
directly
into
the
connection
manager
I'm,
suggesting
that
we
basically
kill
that
ok
and
then,
but
but
we
still
need
some
thing
at
the
end
of
the
line.
Right
basically
knows
what
to
do
with
that
data,
so
right
because,
like
you're,
not
you're,
not
proxying,
like
a
full
connection.
At
that
point,
you
might
need
to
make
like
a
like
a
dedicated
upstream
connection
and
then
kind
of
switch
into
tcp
mode.
B
So
so,
like
I,
don't
I
mean
again
I
haven't
thought
about
this
enough,
but
it
doesn't
seem
like
you
could
just
rip
the
coat
out
of
HTTP
connection
manager
and
like
use
the
existing
router
like
it
just
it
wouldn't
work.
So
that's
kind
of
why
I'm
saying
is
that
you
could
have
the
existing
filters
like
an
alternate
WebSocket
filter
stack
where
you
could
do
header
manipulation,
and
maybe
even
data
manipulation
or
something
like
that
and
then
I'm.
C
Still
actually
confused,
why
why
you
think
we
need
something
different
at
the
end,
so
just
internally
we
treat
WebSockets
as
HP
one
one
data,
it's
just
by
dying.
That's
the
only
difference
we
literally
use
I
mean
are
when
you
do
the
upstream
connection.
You
have
the
past
headers
on
and
then
we
just
pass
headers
on
and
then
say
great
you're
streaming,
data
back
and
forth
from
then
on.
Yeah.
B
Maybe
maybe
it
would
work
I'm,
just
thinking
through
the
cases
where,
like
if
you
went
to
a
connection
pool
that
was
like
trying
to
reuse
the
connection
and
like
you
had
like
previously
sent
like
an
on
WebSocket
connection
there,
and
then
you
like
reuse
it
on
the
pool
I,
just
like
I
feel
like
there's
gonna
be
corner
cases
there
like
it's.
Not
it's
not
clear
to
me
that
in
the
current
code
it
will
work
with
all
edge
cases.
B
Out
of
the
box
like
I
feel,
like
you
could
get
into
a
situation
where
let's
say
that
I
have
an
upstream
that
supports
both
WebSocket
and
not
WebSocket
and
I'm,
doing
connection
pooling,
maybe
I've,
pipelined
or
sorry
I've.
Like
you
know,
I've
sent
some
requests
I've
gotten
some
responses
with
keepalive
can
I
then
switch
that
connection
over
to
WebSocket,
like
is
that?
Okay,
maybe
I,
don't
know.
C
B
D
C
Well,
if
it's
I
mean
large
depends
if
it's,
if
it's
just
a
separate
filter
config
for
you
know
for
WebSocket
pers
is
not
and
delay
the
filter
creation,
I
could
probably
I
could
probably
tackle
that
I
have
website
sorting
out
WebSockets
as
one
of
my
goals
at
this
quarter.
Okay,
so
that
sounds
like
it's
pretty
straightforward.
If
we,
if
we
and
but
this
is
where
I
was
trying
to
understand
like
do,
we
need
to
move
the
TC
bruxing
code,
or
do
we
just
mix
it
or
kind
of
what's
the
plan.
D
D
B
Right,
so
the
the
existing
router
code
should
work
fine
for
that,
it's
more
and
again.
This
is
just
because
I'm
not
super
familiar
with
WebSocket
I
feel
like.
Inevitably
the
at
least
the
router
filter
is
going
to
have
to.
If
we
use
the
router
in
both
cases,
the
router
filter
will
have
to
become
WebSocket,
aware
to
some
degree
like
I'm
guessing
it.
It
might
have
to
do
the
connect
or
like
it
might.
B
It
might
have
to
know
various
things
and
like
and
again,
I'm
also
not
sure
this
is
just
being
not
familiar
with
the
WebSocket
kind
of
spec
is.
Is
it
okay
that,
like
we
might
be
using
a
generic
HTTP,
1-1
connection
pool
like?
Could
we
have
used
those
connections
for
non
WebSocket
traffic
and
then
can
we
upgrade
it
to
a
to
a
WebSocket
connection,
like
is
that
okay,
I.
B
C
So
I
think
I
think
I'm
willing
to
take
on
having
a
configurable
filter
chain,
reusing
the
each
three
filters
because
we
think
their
API
compatible
and
you
know.
Buyer
beware:
I'll
comment
that
you
shouldn't
configure
non-wood
SEC
a
compatible
filters
on
the
WebSocket
I
mean
that
should
be
pretty
straightforward.
Yeah
I
mean
I,
write
and
I.
B
C
B
C
The
fact
that
we
have
to
do
the
upgrades
and
downgrades
somewhere-
oh
the
other
thing,
I'm
actually
really
uncomfortable
with
this,
is
this-
is
the
other
one.
I
wanted
to
bring
up
and
again
this
this
may
come
under,
like
hey,
you
shouldn't
use
this
filter
for
WebSocket
is.
If
we
we
have
to
do
the
upgrade
of
the
downgrade
at
the
last
possible
point,
because
we
don't
know
if
we're
speaking
hv1
own
or
h2
until
we
hit
the
router
filter.
But
the
thing
is
that
you're
actually
literally
changing
the
method.
C
So
if
you
have
some
like
the
course
filter,
which
is
blocking
via
method
like
what
should
the
method
be
pretty
much
everywhere
else
and
on
bluey,
we
say
everything
that
envoy
does
is
HTTP
2,
and
then
we
downgrade
hb1
one
style
headers
on
the
way
out,
I
feel
like
for
WebSocket.
It's
it
almost
should
be
the
other
way
where
we
should
treat
everything
as
like.
A
web
stuff
and
I
prayed
all
the
way
through
like
even
though
they
each
two
paths.
C
Let
me
get
it
say:
hey
this
is
this
is
logically
a
guess
with
an
upgrade
to
WebSocket
treated
as
WebSocket
all
the
way
through
and
then
at
the
last
moment,
downgraded
to
connection
I
wanted
to
get
people's
thoughts
on
that,
because
it's
doing
twice
the
work
for
one
of
the
paths,
but
it
assures
kind
of
consistency
when
you're
going
to
the
filter
chain.
Yeah.
B
C
D
C
D
D
B
The
only
thing
that
I
could
think
of
which
might
be
possible,
but
I'm
not
sure,
is
if
someone
had
set
the
WebSocket
true
thing
on
any
routes.
You
could
maybe
make
that
you
could
implicitly
make
a
WebSocket
filter
stack
with
only
the
router
filter
in
it
and
that
might
work,
but
that,
but
that
requires
more
thinking.
Yeah
I.
C
D
C
C
A
G
B
C
C
B
C
B
I
mean
there's,
there's
just
search
for
bots
in
the
existing
issues
and
there's
a
wishlist
of
bots
and
it's
like
you
know,
they've
been
doing
a
bunch
of
stuff
with
like
Probot
and
and
a
bunch
of
other
stuff.
So
it's
possible.
These
things
will
exist.
It
would
probably
better
to
even
do
it
as
part
of
the
probe.
You
know
project
and
get
up,
and
then
everyone
can
get
it,
but
that
would
be
awesome.
A
B
I,
don't
I,
don't
actually
think
and
github
you
can
assign
to
someone
that
is
not
in
in
the
org.
So
it's
like
people
have
to
get
added
to
the
org,
which
I
mean
to
be
honest,
like
there's,
no
I
just
add
people
to
the
org
who
I
have
like
shown
interest,
basically
like
it
doesn't
really
matter.
So
that's
fine.
F
Yeah
Michael
Payne
here
I've,
been
trying
to
compile
employee
on
arch,
64
or
arm
64
and
I
did
raise
an
issue,
but
just
a
super
short
update.
It's
a
it's
still,
not
working
so
I
basil
doesn't
support
at
64
properly.
The
rules
rules
go
for
basil,
doesn't
support
it
either
and
lifts
Pro
top
gen
ballad
I,
won't
compile
on
anything
is
not
Windows
or
or
Darwin
from
what
I
can
see,
so
that
the
struggle
continues.
So
I'll
I'll
keep
you
updated
fight.