►
From YouTube: GraphQL-over-HTTP Working Group - 2022-07-21
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
B
D
A
D
E
D
C
I
think
I
may
have
made
a
mistake.
I
thought
that
gabriel
had
thumbs
up
the
change
of
meeting
time,
but
it
doesn't
seem
that
he
did.
C
Does
he
have
that
to
the
schedule?
Can
you
drop
him
just
a
link
to
the
schedule?
I
think
hey
there.
You
are.
C
We
are
hoping
another
couple
will
join,
but
in
the
meantime
I
guess
I
can
kick
us
off.
Let
me
load
up
the
agenda.
C
Okay
cool
so,
as
we
all
know,
we've
all
agreed
to
the
spec
membership
agreement.
The
participation
contribution
guidelines
and
the
code
of
conduct
links
to
which
are
in
the
meeting
notes
in
the
agenda
take
a
moment
to
introduce
ourselves.
So
I
think
we
maybe
all
know
each
other
here,
but
let's
introduce
ourselves
anyway.
I'll
start.
If
we
go
in
the
order
in
the
agenda,
I'm
benji
I'm
from
graphile.
A
B
Hi,
I'm
david.
I
I
work
at
apollo
and
do
a
bunch
of
things
there,
but
mostly
I
am
maintainer
of
apollo
server,
which
wraps
graphical
js.
My
first
time
here
I
may
have
to
leave
a
little
early
and
I
may
need
to
eat
during
this.
I
apologize
for
both
of
those.
C
Things
david,
if
you
can
send
a
pull
request
to
the
agenda,
to
add
yourself.
That
would
be
great.
Thank
you.
Okay
again,
it
would
be
ideal
to
have
someone
taking
notes.
I
did
just
update
the
link
to
the
notes
in
the
agenda
just
now,
because
I
accidentally
linked
to
the
june
one
previously,
so
please
do
contribute
notes
there.
If
you
can,
that
would
be
ideal
so
for
the
agenda.
C
Today,
we've
got
looking
at
the
previous
meetings
action
items
which
has
been
allocated
five
minutes,
but
I
suspect
we're
going
to
spend
more
like
10
to
15
on
it.
Then
there
is
looking
at
the
remaining
steps
for
advancing
the
spec
and
then
benedict
is
going
to
talk
about
the
plan
for
the
test
suite.
Is
there
anything
else
that
people
think
should
be
on
the
agenda.
D
One
thing
is
that
I'm
a
little
short
on
time
towards
the
end
of
the
meeting,
so
if
we
could
pull
my
point
forwards,
that
would
be
great.
C
F
C
Okay
cool,
so
let's
quickly
go
over
the
action
items.
I
think
all
of
them
are
ready
to
be
closed.
So
if
you
have
a
look
at
the
ready
for
review
action
items,
I'm
gonna
go
through
them
in
numerical
order,
so
one
of
them
is
number
11
which
is
ancient
how
to
tell
if
the
server
implements
the
spec
lee
suggested
that
there
should
be
a
way
to
tell
that
a
server
implements
the
spec
and
that
maybe
that
could
be
via
the
options
http
verb.
C
I
think
this
is
a
good
idea,
but
I'm
not
sure
that
we
need
it
for
version
one.
I
think
just
having
support
for
this
new
media
type,
that
we've
defined
should
be
sufficient
and
that
most
clients
and
servers
should
move
towards
using
that.
So
if
that
is
used,
then
you
know
it
implements
the
spec.
I
I
think
that
would
be
sufficient
for
now.
How
does
the
rest
of
you
feel.
E
The
the
problem
is,
if
we
don't
have
an
indicator,
how
to
that,
the
spec
is
implemented.
C
Yeah
you
send
it
with
with
an
accept
that
includes
the
the
new
media
type
and
if
your
response
includes
it,
then
you
know
it's.
E
I
good
find,
but
the
problem
is:
if
we,
if
we
go
down
the
road
of
this
options
request,
there
are
other
things
that
need
to
be
considered
then
like
do
we
send
down
a
version
of
this
back
and
things
like
that
and
yeah?
I
see
the
problem.
C
Yeah,
that's
why
I
figured
we
should
avoid
avoid
specking
the
options
for
now,
because
there's
just
there's
so
much
that
we
might
wanted
to
do,
and
I
don't
think
we
need
any
of
that
for
version
one.
I
think
all
we
need
to
know
is:
do
you
support
this
effectively?
The
new
media
type?
That's
the
main
thing,
and
we
can
do
that
just
with
the
accept
header.
So
I
don't
think
we
need
to
do
anything
specific.
C
I'm
going
to
close
this
one
for
now
and
we'll
probably
want
to
come
back
to
it
in
future
for
the
options
request,
but
for
now
I'm
going
to
close
it
next
action
item
was
number
31
talking
about
opening
this
as
a
as
an
official
media
type
actually
submitting
it.
C
We
found
that
we
don't
really
need
to
do
that
we
can
in
the
future,
but
for
now
I
suggest
that
we
don't
worry
about
it,
in
which
case
I
think
this
action
item
that
was
raised
three
years
ago
is
complete
in
in
as
much
as
it
is
an
action
item.
We
could
reopen
it
as
just
a
regular
issue,
but
action
item
wise.
I
think
it's
done
any
descent.
A
C
Incorporate
david's
feedback
into
the
spec.
Well,
I
have
done
so.
You
happy
with
it
david
yep,
excellent!
I'm
going
to
go
ahead.
Yeah.
C
C
Check
the
spec
md
is
working,
I've
hooked
up,
spec
md,
it
is
now
working
and
there
is
a
spec
url
that
you
can
use.
So
I'm
going
to
close
that
and
gabriel
unfortunately
isn't
here,
but
he
did
go
through
all
of
the
issues
and
close
the
ones
that
he
didn't
feel
were
relevant.
C
I've
reviewed
those
as
well
and
I'm
broadly
in
agreement.
So
I
think
that
is
fine.
That
action
is
complete
195
the
issue
labels
have
been
copied
over.
Hence
why
these
issues
now
have
the
action
item
and
ready
for
review
tags.
So
I
think
that
is
all
good
and
done.
Thank
you,
gabriel.
Again.
C
And
here
is
the
meeting
that
we've
scheduled.
We
are
in
it,
so
that
one
is
done
as
well.
All
right,
that's
all
the
action
items
before
we
move
on.
There
is
also
two
pending
pull
requests.
Gabriel,
has
reviewed
and
approved
these.
I
think
you
benedict
have
also
you've
reviewed
them.
I'm
not
sure
if
you
approve
them,
but
I
think
that
we
should
merge
those.
C
C
Okay,
so
splitting
the
example
into
three
different
examples,
I
think,
is
the
more
simple
pull
request.
So
how
do
people
feel
about
that?
I
know
benedict
has
suggested
that
we
add
an
additional
note,
but
I
think
we
can
merge
it
and
then
add
the
note
afterwards.
C
Yeah
cool:
let's
do
that
squash
and
merge
great
and
then
the
other
one
was
a
little
bit
more
subtle
because
it's
actually
adding
all
of
the
notes.
So
if
anyone
wants
to
say
I'll
review
this
after
the
call,
that's
fine.
Otherwise,
if
everyone's
happy,
we
can
merge
it
now.
E
C
Cool,
I
think
that's
it
for
the
action
item.
So
let's
move
on
I've
lost
my
link
to
the
agenda,
so
here
we
go
again.
F
D
Some
have
suggested
it
should
be
something
like
graphql
playground
that
you
can
run
in
the
browser
and
use
it
to
point
towards
the
server
and
just
check
manually.
If
it
implements
the
spec,
I
tend
to
towards
preferring
a
cli
based
tool
that
can
be
run
automatically.
D
D
So,
and
I
don't
think
we
need
to
solve
every
issue
at
once,
so
both
options
are
fine,
but
to
start
off
what
option
do
you
think
would
be
best
or
most
important.
C
The
browser-based
solution
won't
be
capable
of
testing
every
possible
thing
that
you
might
want
to
test
because
browsers
are
limited,
and
then
you
have
issues
you
know
cause
and
various
other
things.
So,
though,
I
think
everything
that
you
might
positively
want
to
test
is
testable
through
a
browser
client,
because
you
know
the
whole
point
is
to
be
compatible
with
browsers
the
negative
tests,
I
think,
would
be
more
challenging
to
do
so.
D
Yeah
makes
sense
to
me:
I
mean,
if
it's
possible,
to
have
a
common
core
that
works
both
in
browsers
and
somewhere
else.
That's
that's
great,
but
I
don't
think
it's
necessary
for
the
first
implementation.
E
Yeah
also,
I
mean
I
mean
the
the
test.
Suite
could
also
be
something
like
working
programs.
We
can
always
add
things
like
it
really
doesn't
have
to
cover
all
the
cases,
and
this
should
not
be
a
blocker.
C
I
think
this
certainly
is
not
a
blocker
to
us.
Releasing
the
spec,
the
graphql
spec
itself
doesn't
have
a
test
suite
the
reference
implementation
does,
of
course,
but
that's
fine,
so
yeah.
I
think
we
can
go
ahead
and
release
the
spec
without
it,
though
it
would
be
a
very
nice
companion.
D
I'm
just
I'm
just
looking
for
the
issue
where
well,
we
discussed
it
in
the
first
place.
D
Yes-
and
we
do,
we
also
had
an
issue
open
about
it
right
found
it.
D
So
in
the
past
I've
researched
a
little
bit
about
which
library
or
which
text
stack
would
be
appropriate.
I
figured
it's
probably
best
to
write
it
in
javascript
since
that,
but
that's
what
the
referendum
reference
implementation
uses
and
that
also
enables
to
us
to
move
towards
browser
at
a
later
point
in
terms
of
libraries
or
tools.
One
might
use
we
have
just
has
been
thrown
around
as
a
as
a
basic
test.
D
Runner,
not
sure
if
it's
actually
appropriate,
though
to
do
this
kind
of
extra
testing
of
external
code
and
also
do
you
possibly
have
some
suggestions
for
a
good
library
that
we
can
use
to
make
the
http
requests
something
that
there's
here
to
watch.
There
is.
E
There
is
apollo
did
a
small
test
tutorial
federation
stuff.
I
just
remember
that,
because
we
implemented
it
and
then
we
were
able
just
to
do
a
pull
request
with
the
project
in
a
certain
structure,
and
then
they
run
the
test
against.
That
might
be
worth
looking
at
that
because
it
was
quite
nice
to
have
that.
In
that
point,.
D
Is
that
in
a
repository
somewhere.
E
It's
in
the
apollo
I
can.
I
can
so
something
david.
E
There's
yes,
exactly.
C
I
think,
if
possible,
it
would
be
ideal
if
this
could
be
done
without
using
any
libraries
effectively.
It's
just
doing.
Http
requests
right
and
it's
just
effectively
looping
over
a
bunch
of
tests,
so
I
think
node
itself
is
capable
of
doing
all
that
stuff
without
a
huge
amount
of
additional
boilerplate.
C
If
we
can
achieve
it
with
just
effectively
one
javascript
file
and
you
can
just
have
a
javascript
file
and
the
node.js
runtime
or
similar,
then
it
will
make
it
a
lot
easier
for
people
to
to
run
that
test
against
you
know
the
java
or
net
or
c
or
whatever
else
swift.
You
know
that
we've
got
going
on
so
that
would
be.
My
vote
is
to
use
as
few
dependencies
as
possible.
Obviously
we
can
bundle
up
whatever
we
use
anyway,
but
I
would
I
would
try
and
keep
it
really
really
lean
if
possible.
E
But
if
you
look
at
it,
it's
quite
nice,
they
have
like
now
federation,
one
federation,
two
and
then
each
of
the
implementations,
and
you
can
see
how
far
each
implementation
is
along
in
implementing
that
all
right.
D
Just
remembered
yeah,
I
have
implemented
this
one.
E
Yeah,
and
was
it
was
quite
like
from
from
from
an
implementation
standpoint
that
was
pretty
easy
to
do.
D
How
would
offering
the
test
suit
work,
so
I
guess
it
could
be
part
of
the
repository
graphql
over
http,
but
would
we
want
to
have
something
like
where
the
implementers
add
pull
requests
to
the
repository
and
then
have
test
run
against
the
things
all
the
time?
C
I
think,
for
the
same
reason
that
the
graphql
reference
implementation
and
the
graphql
spec
are
in
separate
repositories.
The
spec
and
the
test
tool
should
be
in
separate
repositories
mostly
because
I
don't
think
it
needs
to
necessarily
be
the
same
set
of
people.
Maintaining
both
the
spec
text
can
be
ahead
of
the
test
suite,
and
that
is
fine
and
the
test
suite
people
can
be.
You
know
doing
very
easy
merges
to.
B
Yeah
I
just
wanted.
Maybe
this
is
not
here
there,
I'm
saying
I'm
really
specifically
excited
about
this
testing
existing
specifically
for
once
some
incremental
delivery
gets
into
the
spec
as
non-rfc,
because
you
know
I
feel
like
by
2022.
B
People
probably
mostly
have
implemented
like
the
very
basic
stuff
that
we
have
expect
now
correctly,
but
I
suspect
that,
like
being
able
to
have
a
nice
test
suite
for
incremental
delivery
is
gonna
actually
help
a
lot
of
people
like
you
know,
oops,
you
forgot
to
actually
do
content
in
coding
chunks
or
you
know
something
like
that.
C
Very
good
point
benedict:
do
you
think
you
have
enough
information
now
to
proceed
with
anything
that
you
need
to
do.
D
Yeah
sure
so
I
think
we
we
said
that
after
we
discussed
this,
we
can.
We
could
close
the
issue
about
the
test.
Suite
okay,.
D
I
would
probably
do
it
so
that
so
for
some
things
we
would
need
to
have
a
schema
in
order
to
test
certain
kinds
of
errors,
but
for
other
things
we
could
just
use
introspection.
D
E
B
Theory,
you
could
defer
part
of
it
of
an
introspection,
query
itself,
although
who
knows
if
that
would
actually
get
deferred
in
practice,.
E
Yeah,
but
a
good
optimized
server
could
skip.
The
differ
would
be
allowed
to
say,
okay,
because
that
is
the
sync
result.
We
don't
defer.
I
just
give
you
the
site.
D
Agreed
yes,
yeah
running
the
test,
suite
could
be
parameterized
and
you
could
specify
to
which
extent
you
would
like
testing
to
happen
and
if
you,
and
if
you
just
test
the
cell,
that
only
has
introspection
available,
then
you
just
run
a
part
of
the
test.
Suite.
B
One
note
is
speaking
of
being
fully
compatible.
Is
I
hope
that
the
test
suite
is
able
to
differentiate
between
the
the
musts
and
the
shoulds
like?
I
think
you
should
test
everything
in
the
spec,
but
you
should
be
able
to
say,
like
you
know,
we
are
100
compatible
because
we
implement
all
the
musts
or
we
are
even
more
compatible.
If
we
also
do
all
the
shoulds.
E
E
C
Okay,
great,
should
we
move
on
to
the
the
rest
of
the
topic,
which
is
basically
getting
the
this
schema
ready
for
the
sorry,
the
spec
ready
for
release
excellent.
So
here
we
are
ideally
drawing
up
a
plan.
C
Last
year
last
time
we
released
the
graphql
spec,
it
was
in
october
and
the
aim
is
to
do
it
annually.
So,
hopefully
we'll
be
cutting
a
new
release
of
the
graphql
spec
in
october.
It
would
be
ideal
to
try
and
tie
the
release
of
the
grav
kill
over
http
spec
into
that
same
release
cycle.
In
order
to
do
so,
there
is
some
legal
work
that
needs
to
be
done.
We
need
to
track
down
all
of
the
contributors
and
make
sure
that
the
clas
have
been
signed
and
all
that
kind
of
stuff.
C
That
is
one
of
the
reasons
why
getting
the
previous
version
of
the
graphql
spec
released
took
so
long
just
took
a
long
time
to
track
all
those
people
down,
but
that
is
not
something
that
we
will
be
doing
at
the
working
group.
That's
something
that
the
the
graphql
foundation
or
the
tsc
and
so
on
will
be
taken
care
of,
I
believe,
which
at
least
takes
off
with
three
of
our
plates.
C
So
what
we
need
to
think
about
is
what
actually
do
we
need
to
present
to
the
graphql
working
group
in
order
to
advance
this?
At
the
moment,
we
have
a
roadmap,
and
the
roadmap
says
that
we
are
in
stage
zero,
which
is
like
the
I
forget
what
they
called
it
like:
crew,
not
pre-release,.
C
Preliminary,
so
it's
currently
called
preliminary
and
then
state
one
would
be
proposal
stage
two
would
be
draft
so
stage.
Two
is
basically
like
it's
basically
good
to
go.
We
just
need
someone
to
put
that
final
rubber
stamp
on
it
stage.
One
is,
we
think
it's
pretty
good,
but
you
know
there
might
be
a
few
more
changes
that
need
to
be
made.
C
I
think
we
are
pretty
much
in
the
position
where
we
should
be
able
to
advance
it
to
stage
one,
and
I
think
we
can
do
that
under
our
own
steam
when
it
comes
to
stage
two,
I'm
not
100
sure
whether
it
should
be
us
advancing
that
to
stage
two
or
whether
it
should
be
the
graphql
spec
working
group
proper,
I
suspect
the
latter.
C
So
what
I
would
like
is
to
be
able
to
present
a
version
of
this
to
the
graphql,
spec
working
group
and
say:
hey:
can
you
put
the
the
stage
2
draft
stamp
on
this?
So
my
questions
are:
what
do
you
think
we
need
to
do
to
get
it
to
stage
one,
and
what
do
you
think
we
need
to
do
to
get
it
to
be
ready
to
present
to
the
graphql
working
group
in
order
for
them
to
push
it
to
step
stage
two.
C
E
Think
I
I
think
we
need
to
have
implementations
for
that,
so
we
need
to
try
it
out
at
these
two
implementations.
One
non-javascript
one
javascript
is
the
same
process
that
we
do
in
the
proper
graphql
spec
group
like
testing
that
it
works
out.
So
we
should
get
two
implementations
there
and
the
second
thing
we
all
should
read
it
again.
E
D
So
by
an
implementation,
what
exactly
do
you
mean
so
because
we
have
graphql
servers
right
now
serving
graphql
over
http?
Does
that
mean
like
we
check
some
implementations
and
then
we
basically.
E
A
E
C
So
my
my
hope
is
that
the,
for
example,
express
graphql
should
already
implement
the
the
basics,
the
musts
of
this
spec
in
its
current
form.
We
need
to
go
through
and
validate
that
for
sure.
But
are
you
suggesting
that
we
should
have
these
implementations
that
implement
all
of
the
shoulds
as
well.
E
B
Do
does
it
express
graphql
implemented,
yet
that's
kind
of
the
like.
You
know
minimalist
implementation
right.
C
E
B
Apollo
server
doesn't
do
the
new
media
type,
yet
we're
a
little
busy
with
as4,
but
we'll
you
know.
I
definitely
have
to
do
it.
We
will
not
be
implementing
some
of
the
shows
like
we're
not
going
to
change
application
json
like
parse
and
validate
errors
to
be
200s
just
for
that.
B
A
I'd
be
happy
to
happy
to
tackle
the
javascript
typescript
implementation
of
http
server,
so
I
actually
acquired
a
cool
name
which
is
actually
graphql
http,
which
is
perfect
for
the
graphql
over
http
group
and
since
it
doesn't
exist.
I
can
just
follow
on
the
newest
and
the
latest
from
the
protocol
and
have
a
brand
new
implementation
supports
all
the
shoots
and
all
the
musts.
C
A
B
Yeah,
I
do
think
there
is
power
to
having
the
you
know
the
the
implementations
that
you
get
to
say:
hey
this
exists.
Therefore,
it's
a
real
spec,
be,
like
you
know,
real
implementations
with
users,
so
I
do
feel
like
express
care.
Well
I
mean
my
understanding
is
express
react
field,
basically,
in
the
same
way
that
graphical
js
is
kind
of
like
the
reference
implementation
of
graphical
execution.
That
expressed
graphical
is
roughly
the
like.
B
You
know,
graphical.org
foundations,
you
know
reference
implementation
for
being
a
web
doing
web
stuff,
so
it
would
seem
like
that
would
and
that
it
actually
has
users.
So
it
seems
like
that
might
be
more
valuable
than
building
anything
from
scratch
to
one
of
users,
not
to
say
that
it
isn't
fun
to
build
new
things.
A
And
also
one
thing
that
I'd
like
to
add,
since,
if
I
were
to
tackle
this
implementation,
it
would
of
course,
of
course,
have
to
have
a
test
suit,
which
is
something
that
could
be
somehow
plugged
out
and
be
used
further
on
for
having
a
cli
or
hopefully,
a
browser
environment
that
can
do
at
least
the
basic
tests.
That
browsers
should
support.
D
I
was
thinking
the
same
thing
because
that,
especially
when
you
are
just
looking
at
validating
effects
and
existing
implementation
already
implements
spec
now
at
that
point,
you're
doing
maybe
you're
doing
some
http
request
for
hand.
At
that
point,
you
might
just
as
well
write
the
test
tip
for
it.
A
D
Yeah,
I
might
do
this
validation
for
graphql
php,
which
it
can
be
used
as
a
standalone,
graphql
library,
but
also
has
something
called
standard
server,
and
I
think
a
standard
server
should
implement
the
spec.
C
Yeah,
that
would
be
amazing.
Okay,
great
so
implementations
is
one
thing
that
we
should
do.
Are
we
gonna
suggest
that
we
should
have
these
implementations
in
place
before
we
present
it
to
the
working
group,
because
I
figure
we'll
present
it
to
the
working
group
and
then
they're
gonna
have
to
spend
some
time
reading
it.
I
did
suggest
that
people
have
a
read
of
it
at
the
last
working
group,
but
I'm
not
sure
if
anyone
will
have
done
so
because
I
did
also
say
we're
still
putting
in
some
of
the
final
edits.
C
E
E
It's
a
different
thing
that
we
should
have
validated
before
that,
but
that
doesn't
prevent
us
from
presenting
it
to
the
to
the
overall
group,
because
we
could
say:
okay,
that's
a
milestone.
We
are
implementing
that
now
and
validating
the
implementations,
but
we
are
inviting
now
everybody
to
take
part
in
that
and
give
feedback,
because
there
could
still
be
a
couple
of
things
where
lee
doesn't
think
it's
it's
good
or
somebody
else
thinks
it's
not
good
and
which
could
introduce
theoretically
a
major
change.
I
don't
think
so,
but
it
could
be
so.
C
E
A
C
Cool,
so
some
of
you
are
going
to
be
building
the
implementations.
I
will
see
if
I
can
get
in
touch
with
the
van
and
see
if
a
van
is
willing
to
make
some
changes
to
express
graphql.
Otherwise,
hopefully
someone
else
will
we
will
present
the
current
form,
hopefully
with
the
notes
and
any
other
like.
C
I
know,
benedict
wanted
to
follow
up
with
another
note
as
well
any
of
those
merged
if
we
can
aim
to
get
those
all
merged
well
before
the
next
graphql
spec
working
group
like
not
literally
hours
before,
ideally,
then
I
I
would
be
happy
to
present
it
there
again
is
there
do
we
think
there
is
any
major
emissions
or
major
issues
in
the
spec,
as
we
see
at
the
moment,
that
would
prevent
it
from
being
released
in
october.
B
B
Okay,
I
would
like
us
to
think
pretty
seriously
about
whether
or
not
we
can
make
the
spec
require
at
least
strongly
encourage
things
that
protect
users
from
csrf,
because
that
is
a
pretty
serious
problem
we
ran
into,
and
especially
especially
around
basically
requiring
a
content
type
too
fast,
instead
of
just
sort
of
recommending
it.
B
We
have
basically
found
that
that
is
the
most
useful
way
to
ensure
that
you
know
people
can't
just
run
mutations
with
your
cookies
from
random
websites.
B
Essentially,
finding
a
way
to
prevent
at
least
mutations
from
executing
via
http,
like
via,
like
cores,
simple
requests,
the
kind
of
requests
that
can
be
sent
by
a
random
website
without
any
without
a
preflight
like
basically
any
web.
Any
server
that
allows.
B
No,
so
a
poster
yeah.
So
almost
that's
the
problem.
The
thing
the
difference
between
pre-flight
and
not
is
not
get
verse
post,
but
it's
whether
or
not
roughly
it's
whether
or
not
like
interesting
headers
are
set.
So
the
thing
that
saves
you
from
csrf
problems
over
post
is
not
the
fact
that
it
is
post,
but
the
fact
that
you
probably
had
to
pass
content
type
application,
json
and
yeah.
So
I
mean
I
can
go.
B
We
can
just
add
a
better
time,
maybe
maybe
next
meeting
I
can
like
do
a
presentation
on
this
or
something
or
we
can
bring
it
up
on
an
issue
or
something
but
yeah.
We
we
we
in
apollo
server,
are
very
very
strongly
requiring
that
you
should
not
execute
any
operations
via
anything
that
could
have
come
via
a
essentially
a
a
a
non-preflighted
request,
especially
not
mutations
and
as.
B
And
as
part
of
that,
by
the
way
we
have
found
that
that,
as
that,
the
graphical
upload
specification,
as
written
without
any
extra
guards,
is
basically
incredibly
insecure
and
should
never
be
used
without
extra
guards
in
place.
E
But
there
is
like
a
must,
or
there
is
a
must.
A
server
must
support
post
request
encoded
with
the
application,
js
media
type,
as
indicated
with
the
content
type
right,
but
it.
B
Well,
it's
several
things,
but
mostly
if
a
client
does
not
supply
a
content,
type
header
with
the
post
request,
the
server
should
reject
it
and
that
not
being
a
must
is
actually
a
big
problem,
because
there's
actually
browsers
treat
we'll
treat
a
an
operation,
a
request
without
a
content
type
and
a
request
with
a
content
type
that
is
application
json
or,
like
anything
other
than
text,
plain
multi-part
mix
and
one
other
like
very
differently
securely
wise,
and
so
by
requiring
there
to
be
a
content,
type
application
json.
B
B
Yeah
but
then
two
times
later,
you
say
that
if
it
doesn't,
it
should
reject
it,
not
that
it
must
reject
it
unless,
unless,
unless,
unless
the
next
line,
it
should
be
interpreted
as
the
server
must
reject
it
and
should
re
reject
it
with
a
4xx.
C
So
if
you
have
a
curl
script
that
doesn't
set
its
content
type
or
I
think
content
type
is
required
now
but
doesn't
set
an
accept
header,
then
that's
fine
and
the
server
should
still
be
able
to
deal
with
that.
A
B
E
We
also
reject
that.
So
if
there's
no
content
type,
we
reject
the
request,
no
implementation,
but
that
I
also
think
that
is
a
must.
I
mean
I
I
commented
also
on
the
content
type,
but
as
I
read
it
is
a
must,
but
we
can.
We
should
make
a
strong
statement
that
if
there
is
no
content
type
at
all,
then
we
then
it
must
be
an
error.
B
This
might
actually
just
be
a
clarity
of
text
thing,
and
maybe
it's
like
it
possibly
just
needs
to
be
reworded,
as
if
it
does
not
supply
it.
The
server
must
reject
the
request
and
should
use
the
appropriate
forex
x
code
was.
Maybe
is
that
maybe
what
it's
something
to
say
and
I
was
misinterpreting
it
due
to
slight
ambiguity.
C
I
yeah,
I
wrote
it
so
no
you're
not
misinterpreting
it.
It
was
intended
to
be
assured,
but
I
certainly
understand
your
argument
for
a
for
a
must.
I'm
trying
to
weigh
it
up
with
the
the
intention
for
the
should,
because
we
have
to
keep
in
mind
that
it's
not
just
web
clients
that
use
http.
It's
also
mobile
clients.
C
It's
also
command
line,
apps,
it's
a
whole
bunch
of
stuff
other
servers,
and
what
I
don't
want
to
do
is
make
it
so
that
you
have
to
do
this
behavior
in
order
to
be
spec
compliant,
but
by
being
spec
compliant.
You
now
have
broken
all
of
your
existing
clients.
E
A
E
E
B
Is
it
this
is
probably
outgoing
outside
the
time
that
we
have
today,
but
maybe
we
can
talk
about
this
in
a
future
when
I
actually
have
to
run,
but
I
think
it
is
worth
having
a
real
discussion
about
this
before
the
final
spec
publication.
C
But
I
think
it's
probably
okay
to
change
this,
to
a
must,
because,
honestly,
if
you
send
a
blob
of
data
to
the
server
via
post-
and
you
don't
say
what
type
of
thing
it
is,
I
think
the
server
should
reject
it
anyway
and
I
don't
think
that
should
ever
have
been
allowed.
So
I'm
okay
with
changing
this
to
a
must.
E
F
C
E
F
The
issue,
I
believe,
wasn't
that
it
must
contain
a
content
type
it's
what
the
server
should
do
if
it's
not
there,
and
it's
only
a
should
there.
So
those
two
are
just
out
of
sync.
E
F
E
Okay,
okay,
I
see
I
see
yeah,
I
I
override
I,
I
interpreted
it
yeah.
We
should
align
that
yeah,
but
david
will
make
an
issue
on
that.
C
Yeah
that
well
well
expressed
there
gabriel
that's
exactly
the
intent
but
yeah.
I
think
we
should
be
changing
it
to
a
must,
gabriel,
I'm
so
sorry
about
the
the
scheduling
I
I
counted
the
number
of
thumbs
up
and
assumed
it
included
you
and
forgot
that
it
included
me
so,
but.
F
C
Okay,
that's
fortunate,
so
just
to
catch
you
up
real
quickly.
We've
closed
all
the
action
items.
Thank
you
for
your
work.
On
those
we
have
merged
a
few
pull
requests
there's
another
one
going
in
we've
just
agreed
to
advance
the
spec
to
stage
one
and
we
are
planning
to
present
it
to
the
working
group.
The
next
working
group
we
have
agreed
to
implement-
or
for
there
to
be
two
implementations
of
this
spec.
C
Ideally
we'd
like
to
present
this
version
to
the
working
group,
that's
coming
up
in
august
and
then,
hopefully,
the
month
after.
If
we've
got
those
implementations
in
place
by
then
we
can
then
say
we
would
like
to
stamp
the
the
stage
two
stamp
on
it.
Please
and
get
the
graphql
spec
working
groups.
Okay
to
do
so,
and
that
should
put
us
very
much
in
alignment
for
heading
towards
an
october
release.
If
we
can,
that
would
be
ideal.
C
So
what
we're
talking
about
at
the
moment
is
what
is
left
to
do?
What
do
we
need
to
cover
in
here
david's
just
left,
but
david
is
very
much
of
the
opinion
that
we
should
put
some
more
strong
stuff
in
there
with
regard
to.
I
think
it
was
cross-site
request,
forgery
that
he
had
in
mind.
So
we
discussed
one
of
the
issues
there,
which
was
around
the
content
type,
which
you
came
in
on
the
end
of
that
conversation.
C
If
you're,
aware
of
anything
that
currently,
you
know,
is
missing
or
is
badly
specified
in
the
spec
it'll
be
good
to
know
about
that,
so
we
can
deal
with
it
asap,
preferably
before
we
present
it.
At
the
august,
spec
working
group.
F
Let
me
look
back
over
and
remind
myself
of
it,
because
I've
been
in
the
wilderness.
C
That
would
be
amazing
yeah.
I
actually
think
that
we're
we're
pretty
much
done
with
the
discussion
now.
It
seems
like
we're
in
a
pretty
good
place.
I
know
at
least
michael's
going
to
be
reviewing
the
the
notes.
Pull
request.
C
Benedict
who's
just
had
to
leave
is
going
to
hopefully
raise
a
note
in
a
pull
request.
Hopefully,
david
is
also
going
to
change
one
of
the
shoulds
to
a
must
and
add
a
note
in
a
pull
request.
If
we
can
get
all
of
those
merged
in
the
next
week
or
so
that
would
be
ideal
and
then
yeah,
it
should
be
good
to
start
presenting
it
to
the
the
working
group
proper.
F
F
Yeah
I've
been
really
happy
that
benji.
Thank
you
so
much
for
you
know
bringing
bringing
life
back
into
this
group
and
and
pushing
the
the
spec
forward.
I'm
looking
forward
to
this
getting
in
for
for
official
status,.
C
Cool
well,
in
which
case
it's
been
lovely,
to
see
you
all
again,
and
I
guess
if
we
aim
to
organize
another
working
group
for
around
this
time
next
month.
That
would
be
great,
and
hopefully
it
will
just
be
a
case
of
reporting
on
the
the
implementation
status
and
things
like
that.
F
Oh
yeah,
that
would
be
so
awesome.
You
said
you
were
hoping
for
two
implementations,
I'm
assuming
apollo
and
what
else.
C
So
hopefully
it's
graphql
express
because
it
should
already
be
compliant
with
the
musts.
I
think
so.
It's
just
a
case
of
adding
support
for
the
shoulds
dennis
has
said
that
he
would
like
to
build
a
graphql-http
module
in
javascript
and
that
would
be
purely
implemented
based
on
the
spec.
So
one
of
the
great
things
about
that
is,
it
would
mean
a
pure.
C
C
Go
ahead,
benji
he'll
spot
any
of
the
like
emissions
in
the
spec.
You
know
things
that
we
haven't
said
about,
and
things
like
that
so
that'd
be
great.
Also,
I
think
michael's
gonna
be
implementing
it
in
hot
chocolate,
benedictine
graphql
php.
Hopefully
did
I
miss
one.
C
That's
it
that
we've
agreed,
so
if
we
can
get
two,
if
we
get
two
of
those,
then
by
a
what
a
month
and
a
half's
time,
that
would
be
amazing
would
be
in
a
really
good
state.
Then.
F
I
really
think,
dennis
you
know
not
to
put
any
pressure
on
you
for
the
time
or
anything,
but
I
really
like
the
idea
of
having
a
reference
implementation.
That's
official
that
goes.
You
know,
along
with
graphql
js
that
could
be
part
of
the
working
group,
is
working
groups
kind
of
like
a
package
to
further
make
this
official
for
lack
of
a
better
word
to
have
the
spec
and
a
reference
implementation,
I
think,
is
always
good.
A
Yeah,
I
think
so
too,
and
yeah
I'll
put
myself
into
gear
and
hopefully
really
sit
by
in
time.
Action
and
also
the
idea
that
I
had
behind
it
is
that
it
will
be
a
both
client
and
server
side
implementation,
so
it
will
be
server,
that's
completely
in
line
with
the
spec
and
also
clients
using
it
so
yeah
thumbs
up.
For
that
I
mean
fingers
crossed
for
that.
Yeah.
F
Well,
both
both
yeah
and
if,
if
you
need
help,
feel
free
to
reach
out
to
me
lovely,
thank
you.
C
Excellent
well,
thank
you
all.
If
there's
nothing
else,
then
I
guess
we
can
draw
this
meeting
to
a
close.