►
From YouTube: IETF104-HTTPBIS-20190325-1610
Description
HTTPBIS meeting session at IETF104
2019/03/25 1610
https://datatracker.ietf.org/meeting/104/proceedings/
B
B
C
B
E
D
D
D
F
B
A
G
H
H
H
Alright,
so
we
know
well,
blue
sheets
are
going
around
right
now.
Please
make
sure
you
do
sign
one
of
those
and
we'll
need
a
minute
taker
and
jabber
scribe.
Do
we
have
anyone
for
that?
Yet
don't
think
so.
Could
we
get
someone
to
volunteer
to
do
minutes
in
the
ether
pad
and
so
by
the
way
we
will
be
doing
the
core
document
issues
today.
So
if
that
feels
like
something
you
want
to
take
notes
on,
please
volunteer.
I
J
H
All
right
and
anyone
in
jabber
yep
great,
thank
you
one
other
announcement
that
we
do
have
is
that
we
are
going
to
have
a
change
of
responsible
aid
for
the
group,
so
Alexi
has
been
doing
a
fantastic
job
of
aiding
us
so
far.
So
thank
you
for
your
service
as
ad,
and
we
will
be
switching
over
to
have
Barry
as
our
ad
starting
on
Wednesday
I.
Think
so.
H
G
G
N
N
Some
will
be
rejected
during
this
session,
I
hope
by
Aleksey,
so
I'm
I'm
keeping
track
of
the
HTTP
errata
and
map
them
to
github
issues,
and
so
that
we
always
have
a
complete
picture
of
where
we
are
with
the
errata
there's
a
summary
page
linked
from
that
slide.
But
it's
also
on
the
front
page
on
github
x1.
N
N
C
G
G
See
if
we
have
time
for
other
issues,
so
the
first
one
here
is
issue
203
expect
should
be
a
list
header.
We
noticed
in
the
discussion
of
another
issue
which
we
might
touch
later
on,
that
in
the
HTTP.
Excuse
me
this
effort
way
back
ten
years
ago.
I
guess
we
made
a
decision
to
lock
down
the
expect
header
to
just
one
value
of
100
continue.
We
said
this
mechanism
is
not
useful
for
new
extensions.
We
don't
intend
for
new
extensions
to
be
identified
or
defined,
and
so
we're
gonna
lock.
G
The
the
syntax
of
this
expect
header
to
just
one
value.
The
problem
with
that
is
that
it
was
originally
a
list
header
and
it
is
now
no
longer
a
list
header
which
creates
some
interesting
problems
in
error
handling
and
in
how
the
headers
defined,
because
we've
changed
it's
a
V&F
retrospectively,
and
so
we
discussed
this
briefly.
G
We
have
netters
meeting
just
before
the
meeting
here
and
we
discussed
returning
it's
a
B
and
F
to
to
be
a
list
header
so
that
it
behaves
in
reasonable
ways
when,
when
more
than
one
value
is
encountered,
that
will
probably
entail
defining
some
error.
Handling
for
a
couple
of
different
situations,
and-
and
we
we
almost
thought
that
it
was
an
editorial
issue,
but
we
wanted
to
flatten
for
the
working
group
to
see
if
anybody
had
any
concerns
about
doing
that.
G
You
know
we
went
in
HK
Phoebus.
We
talked
a
little
more
precisely
about
how
some
requests
methods
syntactically
can
have
a
request
body,
because
we
really
want
to
keep
message.
Parsing
generic.
We
don't
want
to
have
to
have
a
message.
Parser
understand
the
specific
semantics
of
an
HTTP
method
to
be
able
to
par
as
a
message,
because
it's
not
reliant
upon
the
method,
and
so
we
tightened
up
language
about
that
to
make
it
clear
that
you
know
get
and
delete.
Syntactically
can't
have
a
body,
it's
just.
G
G
We
didn't
clarify
who's
allowed
to
make
the
decision
of
when
a
body
is
defined,
for
a
method
can,
if
we
don't
define
semantics
of
a
body.
Forget,
for
example,
can
someone
come
along
and
say
well
for
my
resources?
Yes
yet
has
meaning
I
get
body
has
meaning,
and
so
we
discussed
this
before
and
and
the
conclusion
that
Roy
and
Julian
I
came
to
which
we
wanted
to
bring
to
the
group
and
start
a
discussion
here
was.
G
G
If
you
try
and
put
a
message
button
again
and
and
then
the
other
thing
we
discussed
was
for
delete,
some
folks
have
use
cases
for
putting
message
buddies
on
delete
to
to
modify
the
semantics
of
that
delete.
I.
Think
Julian
was
saying
that
some
people
want
to
do
things
like
say
that
when
you
delete
this
still
keep
it
in
version
control,
for
example,
or
so
keep
it
a
history
of
some
sort
or
or
if
you
have
other
features
around
what
is
effectively
a
file
system
there.
G
You
might
want
to
modify
those
semantics,
and
the
question
there
is
you
know
is:
is
a
message
body
the
right
way
to
convey
those
semantics,
or
should
they
be
message
editors?
And
what
advice
do
we
want
to
give
us
a
working
group
in
those
situations,
and
it
seemed
to
us
that
that
we
need
to
have
a
conversation
as
a
working
group
about
what
best
practice
is
there
before
we
can
come
to
a
decision
about
whether
or
not
we
want
to
make
recommendations
about
bodies
on
delete?
G
Got
a
thumbs
up
from
Victor,
hey
and
from
Allan.
Okay,
we're
now
gonna
go
to
a
thumbs
up
base
communication
protocol:
okay:
we
have
multiple
thumbs
up,
go
alright,
I
think
the
practical
implication
here
is
that
we'll
go
ahead
and
do
that
forget
and
we'll
probably
open
a
new
issue
to
start
discussing
what
buddies
on
deletes
might
mean
and
whether
that's
actually
a
good
idea
or
not,
and
that
might
be
a
much
more
involved
discussion.
Patrick.
Are
you
going
to
talk
at
the
mic?
Oh
well,
you
there's
a
mic
right
here,
man,
it's
all
good.
I
I
There
we're
prepped
for
everyone
else,
yeah
I
was
gonna,
say
I
think
the
same
reasons
that
bias
get
it
which
are
essentially,
you
know
you're,
not
gonna,
get
end
and
interrupt
right.
If
you
just
a
little
closer
I,
think
the
same
reasons
that
bias
the
decision
you've
talked
about
forget,
which
is
you're
not
going
to
get
sort
of
end
n
Interop
around
that
message.
Body
getting
through
apply
just
as
strongly
to
delete
so
I
would
encourage
the
authors
to
sort
of
start
from
that
position
on
delete
as
well.
Instead
of
with
a
blank
slate.
G
J
N
Julian
Koshka,
so
when
we
talked
about
it
earlier
today,
I
made
the
point
that
we
probably
shouldn't
have
too
many
categories
of
payloads
ignored,
payload,
discourage,
payloads,
embraced
and
so
on
and
I
think
delete
is
very
similar
to
options
not
very
similar
to
get
and
that
I.
That's.
Why
I
think
that
the
answer
for
the
lead
is
different,
then
forget
it.
G
That's
a
good
point
actually,
so
the
the
other
model
we
were
looking
at.
If
you
look
at
the
language
around
options,
if
I
can
get
it
up
here
in
readable
form,
is.
G
For
folks,
let's
see
where
is
it
a
client
that
generates
an
options
request
containing
a
payload
body
must
send
a
valid
content,
content
type
header
field
describing
the
representation
media
type.
Although
this
specification
does
not
define
any
use
for
such
payload
future
extensions
HTTP
might
use
the
options
body
to
make
more
detailed
queries
about
the
target
resource
responses
to
the
options
method
or
on
cashable.
You
know
really
I
think
we
might
even
want
to
modify
the
language
of
there
a
little
bit
because
there's
an
implication
there
that
only
extensions
to
HTTP.
G
G
And
and
I
was
I
was
concerned
that
that
we
still
might
be
in
the
same
situation
where
we
have
application,
firewalls
and
other
folks
wouldn't
take
a
payload
on
on
a
delete,
potentially
and
and
Julian
did
point
out
that
most
web
application
firewalls
don't
like
delete
.,
so
III
think
that's
it's
it's
reasonable
to
think
about
using
this
kind
of
language
for
delete
personally,
but
I'd
like
to
get
a
little
more
data.
First.
G
G
G
G
You
know
before
they're
put
into
the
cache
or
forwarded,
but
we
don't
actually
specify
that
really
clearly
anywhere
and
then
we
noted
that
other
browsers
amid
other
headers,
such
as
content
dash
star
next
WebKit
dash
star
headers
Apache,
has
a
whitelist
of
headers
that
it
uses
when
it's
updating,
there's
a
bug.
I
raise
them
to
pat
you
awhile
back
for
that
I
think
that's
one!
It's
with
them
and
intermediaries
are
also
reluctant
to
update
headers
for
performance
reasons,
because
you
have
to
rewrite
an
on
disk
and
and
because
headers
are
potentially
unbounded
in
size.
G
G
G
It
does
some
interesting
stuff
here.
If
you
start
with
a
lot
of
green
and
then
we
quickly
have
implementations
that
don't
do
any
header
updating
for
performance
reasons,
and
then
we
have
implementations
that
make
some
decisions
so
like
the
assertions
that
all
browsers
act,
the
same
didn't
turn
out
to
be
true.
So
content
food,
for
example,
is
updated
in
two
browsers,
but
not
to
other
browsers,
an
X
content,
foo
and
so
forth
and
so
on.
G
But
then
the
browser's
all
do
the
same
thing
for
this
block
of
headers
here
for
content,
location,
content,
md5
and
content
type,
and
then
we
go
back
to
to
varied
behaviors
for
other
things
like
X
frame
options
and
X
X
X,
X,
X,
X,
SS
protection,
who
came
up
with
that
and
then
there's
some
weirdness
around
cache
control
and
public
key
pins
and
a
few
other
things.
Then
we
get
a
cookies
which
cookies
are
special
in
so
many
ways.
So
we
gathered
some
data
and
then
I
believe
Geoffrey
did.
Oh,
no
Geoffrey
did
a
PR.
G
Even
if
it's
not
the
connection
header,
though
still
prune
it
for
things
like
transfer,
coding
and
stuff
like
that
in
connection
and
header
fields,
listed
the
no
cache
response
directive
in
the
cache
control
header
field,
which
is
according
to
my
testing,
so
hopeful,
but
but
anyway,
that's
a
separate
issue.
I'm
actually
think
we
have
an
open
issue
open
for
that
and
then
a
list
of
header
fields
here
and
to
do
that.
G
The
above
list
is
not
final
and
then
there's
another
section,
that's
added,
which
is
header
fields
that
aren't
freshened
up
on
a
304,
so
ones
that
or
actually
I
think
ahead
as
well.
Correct
that
when
you
fresh
and
headers
on
disk
or
in
memory
that
you
don't
include
these
headers
and
that's
common
coding,
content,
length,
content,
location
content,
md5
range
type,
e
tag,
proxy
auth,
te
frame,
options,
exit
press
protection
and
the
X
content,
WebKit,
headers
and
so
I'd
like
to
have
a
discussion
about
I.
G
Think
this
general
personally
I
think
this
general
approach
is
is
about
the
right
one
with
some
tweaks
I.
Think
the
big
question
is
what
are
the
right
headers
to
put
on
this
list
and
I
think
I
said
in
the
ticket.
Some
of
these
are
our
slam.
Dunks,
you
know
connection
keep
alive
proxy
off
stuff,
like
that,
where
it
is
obviously
tied
to
connection
context.
That
makes
no
sense
to
persist
this
stuff.
G
Set-Cookie
set-cookie
are
interesting
because
in
my
testing,
people
do
actually
store
those
on
disk,
whereas
that
one,
that's
under
other
I,
think
so
yeah
they
store
cookies,
except
for
a
couple
of
exceptions,
which
is
you
know,
always
gonna
be
the
case.
So
I
want
to
understand
more
why
those
are
being
put
there
and
and
of
course,
things
like
public
key
pins
in
SDS.
G
So
I'd
really
like
to
understand
why
some
of
these
headers
are
on
this
list
and
in
the
browser,
header
fields
that
aren't
fresh
and
once
again
like
I,
can
kind
of
understand
why
content
length
is
there
and
content
md5,
there's
not
even
a
there,
but
for
some
caches
content
type.
If
you
have
a
content
provider
and
they
put
the
wrong
content
type
on
a
response
and
then
they
correct
it,
you
know
or
other
metadata.
They
correct
it.
G
In
their
server
configuration
and
the
the
CDN
or
the
reverse
proxy,
wherever
else
is
a
downstream
cache,
doesn't
do
that
update.
Then
that's
gets
stuck
in
their
cache
and
that's
not
a
great
situation.
So
I'd
like
to
understand
what
the
reason
is
behind
some
of
those
as
well
as
well
as
the
X
content
and
X
WebKit,
which
is
we
saw,
are
not
consistently
implemented
across
browsers.
Q
Mike
Bishop
Akamai,
but
speaking
from
my
experience
making
this
list
at
Microsoft
yeah,
we
made
the
decision
to
exclude
basically
anything
that
dealt
with
content
interpretation
on
the
logic
that
you
are
caching
you're
pulling
from
cache
because
it
hasn't
changed
and
if
it
hasn't
changed.
That
means
that
nothing
about
how
you
interpret
that
content
should
be
different.
M
G
I
wen
overall
concern
here
is,
is
that
we
have
different
components
that
are
behaving
in
different
ways,
pretty
radically.
If
you
combine
the
Apache
bug
with
the
fact
that
some
CD
ends
don't
and
reverse
proxies,
don't
update
headers
on
disk
and
the
browser
behaviors
were
they
omit
some
headers
as
if
I'm,
a
Content
person
and
I
update
something
on
my
origin
server
and
it
doesn't
change
in
all
these
caches
for
a
variety
of
reasons.
That
doesn't
seem
like
a
great
experience
for
anybody,
so
we
should.
We
should
do
better.
R
But
that's
my
overriding
concern
here,
yeah,
so
so
Martin
Thompson,
if
you
are
a
Content
person
and
you
change
some
of
these
things-
and
you
know
that
they're
not
going
to
change
as
a
result
of
if
you're,
just
sending
a
three
or
four
response,
then
don't
send
a
three
or
four
response.
But
you
do
need
to
know
and
I
agree
that
it's
worth
having
some
rules
written
down
here,
I'd
like
to
understand
what
the
principles
are
behind
the
selection
here.
R
R
Is
it
possible
to
produce
another
retag
that
that
is
valid
for
the
same
content
and
I?
Don't
know
how
to
reason
about
that?
One
yeah,
and
so
is
this
stuff
about
the
resource,
or
is
it
stuff
about
the
request
or
what
have
you?
And
so,
if
you
go
back
to
the
previous
list,
these
are
these.
Are
things
that
don't
hit
the
disk?
Those
all
appear
to
be?
R
These
are
things
about
the
connection
or
things
about
the
request,
context
that
don't
really
relate
to
the
to
the
the
actual
representation
that
we're
talking
about
or
anything
that
might
want
to
be
persisted.
If
you
took
talk
about
that
being
your
principal,
then
I
think
we
could
probably
get
behind
something
along
those
lines,
but
I
don't
know
what
do
you
do
for
some
of
these
other
things,
I
mean.
G
I
mean
in
the
case
of
things
like
cookie.
It's
that
cookie,
you
know
the.
What
I
have
always
understood
is.
Is
that
if
you
don't
want
your
cookie
cached,
you
don't
make
the
response
cacheable
and
if
you
do
want
your
cookie,
cache
and
replayed
other
people
or
you
know,
reuse,
then
you
do
and,
and
the
weird
thing
is
that's
what
everybody's
implemented
right
so
but
but
there's
a
common
conception.
A
lot
of
people
have
the
cookies,
aren't
cached
automatically,
and
that
turns
out
not
to
be
true.
That's
not
true
and
the
web
still
works.
R
That
merely
suggested
they
might
be.
The
cookie
might
still
be
on
this
list,
but
you
say
that
some
of
the
things
on
this
list
might
still
be
cached
by
by
intermediaries
and
therefore,
if
you
don't
want
to
be
it
persisted
on
disk,
you
need
to
use,
know
the
cache
control
of
the
appropriate
sort.
What
and.
G
I
can
kind
of
see
that
for
set
cookie,
because
it's
so
intrinsically
in
the
the
architecture
of
what
we're
doing.
What
concerns
me
on
this
list
more
is
something
like
clear
site
data
which
is
very
new
and-
and
we
may
have
another
new
one
like
that
in
two
or
three
months
or
you
know,
I
mean
my
quest-
produces
a
lot
of
these
specs.
So
do
we
add
more
stuff
to
that
list
over
time?
Or
do
we
just
tell
people
if
you
put
clear
dead,
any
response,
don't
make
it
cacheable?
R
That
speaks
to
a
different
approach
entirely
then,
which
is
to
say
that
those
things
that
are
on
this
list
don't
necessarily
get
the
special
treatment,
but
instead
that,
if
you
are
providing
one
of
these
things,
that's
on
this
list
expected
to
be
cashed.
If
you
don't
want
it
to
be
cashed,
therefore,
do
the
do
the
following.
G
G
O
G
The
early,
2000s
and
I
think
patrick
said
that
the
actual
history
was
lost
in
the
sands
of
subversion
somewhere
and
that
it
taken
an
enormous
effort,
actually
dig
it
out,
but-
and
it
looks
like
other
implementations-
have,
to
a
large
degree
cargo
cult.
It
from
that
and
I
think
I
strongly
suspect
that
the
original
reason
that
a
lot
of
these
were
put
in
was
because
of
a
miss
reading
of
the
language
in
2616
around
entities
that
we
eventually
identity,
headers
that
we
eventually
removed
because
we
realized
it
didn't
make
any
sense.
G
But
of
course
that
was
done
before
we
did
2020
77230,
so
these
3
20
20
to
30
so
yeah.
If
people,
if
we
can
come
up
with
a
and
I
like
what
you
said
before,
if
we
can
come
up
with
reasonable
principles
for
why
things
are
on
this
list,
that's
great,
but
I
don't
want
to
just
put
them
on
the
list,
because
we're
not
sure
why
they
shouldn't
be
on
the
list.
You
know.
M
This
is
Jeffrey
asking
again.
This
second
list
is
all
things
that
the
the
cache
may
fail
to
cache.
It's
not
a
requirement
not
to
cache,
and
so
I
was
super
inclusive
here,
if
I,
if
I
knew
of
a
client
that
didn't
catch
them
and
this
this
list
may
just
be
a
copy
of
what
Chrome
doesn't
in
in
practice.
Doesn't
cache
I
included
it
there?
There
was
no
thought
behind
it.
M
G
Inclined
to
take
the
ones
where
all
the
proxy
s
are
all
the
caches
or
sorry
all
the
browsers
act,
the
same
way
a
lot
more
seriously,
but
the
assertion
that
you
know
if
you
cache
this
header,
if
you
don't
do
that,
it'll
break
something
it
doesn't
really
wash
with
me.
If
there
are
a
couple
of
browsers
out
there
working
fine
in
their
cache.
Yes,.
M
G
O
R
G
R
Whatever
decision
you
make
has
to
be
pretty
firmly
grounded
in
something
and
I,
don't
know
what
this
list
is
granted
and
I.
Think
I
can
see
where
some
of
the
formalist
get
is
grounded,
but
this
one
is
a
little
hairier
and
I.
Think
I
prefer
to
simply
have
well
clients.
I,
don't
want
to
exclusively
limit
this
to
browsers.
But
clients
agree
on
on
what
it
is
that
they're,
not
kind
of
update.
G
G
There
we
go
that
was
status,
codes
and
caching.
Next
up
is
a
fun
one.
It's
head
of
terminology,
a
number
111,
and
we
said
that
last
time
we
didn't
want
to
bike
shed
this
in
a
big
room
with
a
lot
of
people,
because
that
would
be
a
complete
waste
of
time,
so
he
bike
shed
it
in
a
much
smaller
room.
Did
me?
G
G
G
G
O
O
N
O
The
purpose
of
having
this
loosey-goosey
syntax
anyways-
and
we
can't
really
do
this
through
what
what
working
group
doesn't
say.
Okay,
you
for
developers
are
going
to
all
agree,
that's
a
gay
sorry!
We've
got
5,000
developers
and
none
of
them
agree
on
anything,
so
so
I
mean
what
we
have
in
the
draft
right
now
is.
O
This
is
what
the
recommended
serialization
is
that
recommend
the
the
noah
base
before
the
colon
in
a
single
space
after
the
colon
and
as
far
as
I
know,
every
single
producer
produces
that
unless
they're
trying
to
deliberately
attack
a
service,
it
seems
to
be
enough.
So
I
don't
see
any
further
purpose.
I
know.
G
Now
what
I
was
I
was
thinking
there's
another
issue
we
have,
which
is
about
the
comma
and
I,
have
different
feelings
about,
but
I
think
I
agree
with
you
here.
I
just
don't
see
enough
of
an
issue
here
to
bother
I
mean
I,
guess
the
only
other
thing
is.
Is
it
he's
not
asking
for
us
to
add
a
lot
of
text
but
I'm
not
seeing
a
particularly
large
amount
of
value,
and
anybody
else
have
any
thoughts
about
him.
H
G
G
G
G
And
so
the
question
at
hand,
then
I
don't
know
how
to
give
her
this
window
now.
Is
you
know
it's
not
interoperable?
Should
we
change
the
spec
to
reflect
that
and
I
noted
later
on
in
HDTV
Biss?
Where
is
my
cursor
there?
It
is
we
I
thought
we
decided
to
make
this
should
not
generate,
must
accept.
We
actually
did
something.
G
A
little
more
subtle,
I
think
we
made
it
should
not
generate
to
accept
was
that
where
we
have
them
up
Julian,
and
so
the
question
is,
should
we
changed
the
requirement
levels
here
and
we
discuss
this
as
the
editors
earlier
on
and
we
didn't
come
to
any
conclusion
at
least
not
until
I
went
out
to
get
some
water?
Did
you
come
to
any
conclusion
after
I
went
to
get
some
water
No,
so
the
actual
spec
text
heater
is
already
a
little
bit
confusing.
Oh.
P
G
So
we
we
first
say
here:
they
have
an
optional
argument
that
can
be
used
both
token
and
quoted
string
syntax
for
the
directives
defined
below
that
define
arguments.
Recipients
ought
to
accept
both
forms.
Rfc,
6119
I
believe
even
if
one
is
documented,
to
be
preferred
for
any
directive
not
defined
this
specification
recipient
must
accept
both
forms
and
then
for
max
age.
G
We
say
this
directive
uses
the
token
from
the
Arman
syntax
see
eg
max
age
equals
5,
not
max
age
was
quoted.
5
a
sender
should
not
generate
the
quoted
string
form
so
I
guess.
The
question
is
considering
the
incredibly
low
level
of
interoperability
for
quoted
string
forms
here
is:
should
not
adequate.
Can
we
communicate
this
any
clearer
or
not
I.
G
O
N
N
N
And
to
continue
on
that,
that's
exactly
the
thing
that
we're
investigating,
if
what
we
are
trying
to
understand,
is,
are
there
powers
that
are
written
in
the
same
way
that
still
do
not
accept
that.
So
is
this
a
conscious
decision
by
a
programmer
to
reject
that
value
and
if,
if
so,
why
or
is
this
something
else,
that's
what
we
need
to
find
out.
O
G
G
You
know
for
me,
it's
it's
just
if
we
can
give
the
clearest
possible
guidance
to
people
using
the
web
from
an
interoperability
standpoint
and
I
feel
like
we
fail
well,
sometimes
what
we
provide
is
so
abstract
or
so
nuanced
that
it
goes
over
people's
heads
as
we
saw
with
the
get
body
discussion
elsewhere.
I
just
want
to
try
to
clarify
that.
That's
that's
that's!
Why
I'm
raising
this
kind
of
issue.
G
G
And
we
decided
to
tie
the
cache
ability
of
a
response
to
understanding
its
cache
to
its
status
code
so
that
we
didn't
have
to
go
and
figure
it
out
for
each
individual
status
code.
I,
guess
that's
what
it
says
here
and
and
as
I
say
here,
you
know.
The
problem
is:
is
that
if
I
want
to
deploy
a
new
status
code,
then
caches
have
to
be
updated
to
understand
that
status
code
before
they
can
cache?
G
It
I
can't
just
say:
okay,
here's
that
is
code
for
49
or
whatever
and
it'll
work
automatically,
with
the
reverse,
proxies
and
ctn's,
and
browser
caches
and
be
stored
properly,
which
seems
like
a
nice
property.
If
we
plan
on
introducing
new
status
codes,
ROI
notes,
I,
think
that
that
we
don't
you
know
he
doesn't
have
a
problem,
discouraging
the
definition
of
new
status
codes.
It
is
a
constrained
space.
G
So
maybe
it's
okay,
that
rolling
out
new
status
codes
is
a
little
bit
slower
because
they
don't
initially
get
cached,
and
so
we
talked
about
this
in
Bangkok
and
then
I've
remembered
that
there
was
another
part
of
72
34
that
says
no
to
all
status
codes.
Can
be
cached
if
the
response
and
current
has
explicit
freshness
information,
so
we
actually
conflict
with
ourselves
now,
which
is
not
great,
and
then
I
talked
a
little
bit
more
about
what
I
just
said,
which
is
introducing
new
status
codes.
I
think
Roy.
G
O
I
O
O
I,
don't
think
any
of
that's
likely,
but
yeah
that's
a
technical
distinction.
My
concern
about
the
change
here
really
is
more
of
what
are
we
trying
to
fix
in
the
sense
that
all
we
are
we
actually,
what
condition
is
so
important
that
the
cash
be
able
to
cash
a
status
code
that
it's
never
seen
before
I
mean
caches?
Are
there
for
a
reason,
they're,
typically
to
improve
performance?
Why
do
we
need
improve
to
improve
performance
for
this
specific
type
of
response,
given
that
we've
never
seen
it
before
so.
G
To
the
first
point
about
SX
I
sketched
out
here
that
you
could
define
new
extensions
to
allow
special
status
codes
to
be
defined
and
be
exempted.
So
that's
you
know
it's
it's
it's
ugly,
but
it's
possible
so
that
I
don't
think
that
takes
it
off
the
table.
In
terms
of
why
do
you
need
to
cache
it?
I,
don't
know
I'm
a
caching
guy
I
like
caching,
you
know
my
company
caches
I,
let
play
with
browser
caches
if
we
introduce
a
new
status
code,
I'm
really
impatient
to
get
the
freaking
thing
cache.
O
F
O
Yet
been
updated
to
understand
the
code
now
you
understand
the
desire
to
have
it
be
cached
by
caches
that
understand
what
the
code
means,
but
I
don't
see
the
performance
desire
to
have
it
automatically
cached,
even
though
the
cache
does
not
understand
what
it
means,
but
it
just
doesn't
seem
to
be
a
problem.
We
need
to
solve.
G
O
But
even
I
mean
most
at
most
caches
operate
on
the
presumption
that
they're
only
caching
a
limited
amounts
of
resource
responses
because
they
have
space
controls
wouldn't
well.
You
know,
typically
caches,
don't
try
to
catch
the
entire
web.
You
know
they
have
some
limitations
per
cache.
I!
Think
it's
fine!
You
know,
I
mean
what
I'm
saying
is
that
it
seems
very
odd
to
be
I
to
to
be
going
down
into
this
level
of
detail
for
a
performance
improvement
that
we
is
very
mystical.
G
Think,
especially
for
cases
like
when
people
are
doing,
caching
of
api's
for
HTTP
API,
for
example,
and
they're
more
likely
to
use
some
more
esoteric
status,
codes
and
I
I
would
like
them
to
be
able
to
use
the
full
capability
of
the
cache,
not
just
what's
in
the
normal
web
footprint.
And
then
you
know,
if
you
look
at
the
status
codes
that
we've
introduced
over
time,
you
know
6585
the
additional
HIV
status
codes
which
you
and
me
and
yeah,
just
you
and
me
worked
on.
G
All
of
these
you
know
have
potential
caching
cement
that
could
get
some
value
from
from
caching,
or
at
least
some
of
them.
You
know
killing
your
requests,
for
example,
in
certain
circumstances,
and
certainly
for
five
one,
which
was
other
big
one,
that
we
added
a
little
while
back
and
yes,
that
you
know
you
have
to
be
careful
to
make
sure
that
when
you
catch
them,
they
are
served
again
in
in
the
right
circumstances.
But
we
have
the
mechanisms
to
do
that
now.
So.
O
O
G
Can
you
give
alright,
can
I
give
you
a
test?
Can
you
give
me
feedback
on
that
straw
man
mechanism
and
see
how
much
it
makes
you
puke
sure
and
and
then
we'll
go
from
there
sure
if
that's
something
that
you
see
is
halfway
viable,
then
I
can
I
can
flash
it
out.
S
G
Okay,
okay,
you're
busy
man,
it's
okay,
so
here's
the
fun
one
111
that
was
so
impatient
to
get
to
before.
So
we,
a
number
of
us
have
noticed
that
the
terminology
around
HTTP
headers
is
fuzzy
and
an
awkward
and
and
misunderstood
a
lot.
Even
we
need
more
precision
when
we
talk
about
these
things,
especially
now
that
we
have
not
only
HD
1
but
HB
2
and
coming
htv-3
and
their
different
ways
of
actually
carrying
these
things
in
the
wire
and
so
I
think
in
Bangkok
or
there
abouts.
G
We
decided
that
we
didn't
want
a
bike
shed.
This
is
an
entire
group,
so
Julian
and
Roy
and
I
bike
should
have
this
for
actually
a
surprisingly
short
amount
of
time
earlier
today,
and
we
came
up
with
a
proposal
that
we
wanted
to
walk
people
through
and
see
what
how
much
people
like
this
or
disliked
it,
and
so
what
we
thought
we'd
do
is
introduce
a
number
of
new
terms
in
the
semantics
document.
G
So
generic
to
any
version
of
HTTP
a
list
based
field
refers
to
a
field
that
uses
the
the
list
rule
or
similar
construct,
in
other
words,
comma,
separated,
multiple
value,
header
field.
A
singleton
field
refers
to
the
opposite
of
that
a
field
that
does
not
use
that
kind
of
rule.
It
only
is
this
supposed
to
have
one
value
now:
they're
gonna
be
circumstances
where,
due
to
an
attack
or
a
bug
or
whatever
else,
a
singleton
field
has
more
than
one
value
in
their
comma-separated,
and
we
need
to
describe
how
to
handle
that
sort
of
situation.
G
G
Have
another
open
issue
to
talk
about
that
for
our
existing
headers?
A
field
item
refers
to
a
single
value
in
a
list
based
field,
so
a
list
based
field
is
composed
of
field
items
and
a
combined
value
or
a
combined
field.
Value
refers
to
all
instances
of
a
list
based
header
after
combining
with
commas.
So
that's
the
end
result
of
the
common
algorithm.
G
We
have
of
I
need
to
understand
the
value
of
this
header
field,
but
it
might
be
split
across
multiple
instances,
and
so
here
we
are,
and
that's
actually
a
term-
that's
already
used
in
fetch.
So
that's
a
nice
harmony
that
we
have
there
and
then
in
messaging.
We
use
field
instance
to
refer
to
a
received
on
the
wire
field,
name
value
pair,
so
the
one
lying
as
it
were.
Maybe
we
should
call
it
a
field
line,
but
I
think
instance
is
probably
okay.
G
G
U
G
O
I
That's
not
why
I
have
the
mic,
so
when
a
other
specification
that
perhaps
not
part
of
the
core
specifications
makes
the
reference
to
a
response,
header
maybe
knew
the
value
where
they
were
particularly
response
header
and
it
receives
a
it,
receives
a
nit
during
last,
call
that
that's
not
actually
defined
term.
What
is
the
suggestion
here
for
the
replacement
for
the
colloquial
response?
I.
O
F
I
G
G
R
G
G
G
M
Jef
Raskin
Martin's
comment
made
me
realize
that
you
should
have
an
example
of
referring
to
the
combined
value
of
a
field
so
that
people
have
a
thing
to
copy
when
you
wind
up
with
spec
wording.
Examples.
G
G
M
This
is
Jeffrey
askin.
If
you
scroll
down
to
my
later
comment,
I'd
believe
I
still
agree
with
it.
So
the
my
original
complaint
was
incorrect.
I
suggested
some
changes
to
the
wording
that
would
have
prevented
me
from
getting
confused
enough
to
file
the
initial
complaint
and
it
they
might
be
editorial,
but
I,
don't
know.
Okay,
I'm.
G
Q
F
Q
G
I
think
to
me
the
heart
of
this
issue,
or
at
least
this
confusion
in
the
editorial
sense,
is
that
we
use
the
word
cacheable
in
a
couple
of
different
ways
and
if
we
can
find
it
a
better
term,
that
would
be
great
and
then
we
need
to
find
a
way
to
back
port
that
to
7540
so
that
it's
the
linkage
is
preserved
issues.
You
rightfully
point
out
I'm
happy
to
try
and
do
that
editorially,
and
if
people
have
a
problem
with
how
I
do
it,
then
we
can
talk
over
it.
Then
I
can't
do
it.
O
G
G
G
G
That's
not
helping.
Is
it
so
basically
we're
we're
changing
this
text.
We
already
talked
about
mime
sniffing
kind
of
indirectly,
I
think
and
this
just
hones
that
a
little
bit
to
link
it
into
they
establish
work
on
an
online
sniffing
that
the
what
working
group
is
doing
and
referenced
that
and
give
us
some
advice
about
how
to
do
that,
encourage
implementers
to
provide
that
means
to
turn
off,
and
so
we
referenced
the
I'm
sniffing
speck.
G
We
had
a
point
where
we
also
referenced
the
X
content,
type
options,
header
field
as
a
way
to
turn
it
off
from
the
server
and
in
discussion
we
removed
that
because
it
was
basically
pulling
in
a
reference
to
the
entire
effect
specification.
Even
though
this
is
like
basically
three
lines
on
the
fence
back
and
we
opened
a
bug
on
the
mime
sniffing
spec
to
ask
them
why
they
didn't
even
mention
an
X
Content
ID
option
seems
it
seems
like
it's
relevant
there.
G
G
G
Number
30
is
field,
name
syntax,
which
one
is
this.
Yes,
we
talked
about
this
before
so
header
field
names
are
defined
as
tokens.
O
G
So
what
do
people
think
about
this?
I
I'm
I
still
believe
that
it
would
be
good
for
the
web
overall,
if
we
didn't
have
header
field
names
with
exclamation
points
or
dollar
signs
or
other
fun
characters
in
them.
Call
me
crazy,
especially
considering
the
the
places
that
they
get
exposed
in,
and
it
seems
like
some
implementations
are
already
limiting
this
set
and
not
experiencing
horrible
consequences.
In
doing
so.
G
W
So
anecdotal
experience
about
things
that
are
already
forbidden
in
either
field
names
or
fields,
values
is
that
I
saw
a
lot
of
I
saw
some
people
break
their
services
when
they
moved
from
HTTP
one
where
it's
forbidden
but
tolerated
2h2,
where
it's
forbidden,
but
actually
it
breaks.
The
connection
so
I
think
getting
some
telemetry
would
be
good
and
I
suspect
that
telemetry
to
be
nonzero,
even
though
H
do
currently
helps
in
bringing
everyone
into
the
fold
when
it
comes
to
the
current
restrictions.
I.
G
R
N
U
Allen
findell
just
commenting
on
header
problems
that
happen
between
h1
and
h2.
We
actually
experienced
the
opposite
problem
because
HVAC,
you
can
have
all
kinds
of
characters,
get
decoded
out
of
your
HVAC
decoder,
which
are
not
valid
necessarily
for
HT
semantics.
So
sometimes
we
see
weird
stuff
come
get
h2
new
lines
and
things
like
that.
G
Yeah,
thank
you
and
also
I
think
we
can
probably
examine
some
implementations
to
see
what
they
allow
and
disallow,
and
that
might
be
very
interesting
in
the
forming.
This
kind
of
decision
and
I
can
also
probably
put
some
tests,
at
least
for
intermediaries,
to
look
at
what
some
of
them
do
so
I
guess
this
is
an
we
can
flag.
This
needs
data,
and-
and
maybe
we
can
make
some
progress
that
way.
G
If
we,
let
me
ask
if
we
find
data
that
shows
that
you
know
a
number
of
implementations
already
clamp
this
down
to
to
a
subset
of
what's
allowed
by
the
spec,
and
we
have
data
that
that
you
know
the
use
of
these
characters
is
an
out
layer.
Is
there
a
will
in
the
group
to
try
and
change
this
back?
Does
that
help?
O
S
Branko
moana
is
there
in
any
case
anyone
knows
of
where
these
characters
are
used
in
headers,
for
real
reasons
it
have.
Is
there
any
obviously
we're
only
a
few
of
the
hundreds
of
thousands
of
people
who
do
things
with
HTTP,
but
if
we
don't
have
a
single
case
where
it
is
useful
and
then
cutting
it
out
makes
sense
to
me
right,
I.
I
I
But
that
should,
in
my
view,
really
be
the
bar
and
I
will
remind
the
authors.
This
is
a
you
know,
a
business
document
essentially
right,
and
so,
if
we
are
documenting
the
fact
that
many
implementations
currently
restrict
this
set
right
and
so
for
inter
operation,
you
should
work
within
those
constraints
and
we've
got
some
comments
from
like
H,
a
proxy
and
I
think
nginx
in
this
list.
That
suggests
that
might
be
the
case
and
I
think
this
makes
a
lot
of
sense
for
core.
I
G
My
sense
is:
is
that
this
first
proposal
that
I
made
to
cut
it
down
really
substantially
might
be
too
ambitious,
and
then
maybe
we
just
need
to
look
at
you
know
there
are
a
few
problematic
characters
that
a
lot
of
implementations
have
already
blacklisted
anyway.
So
let's
just
recognize
that,
let's
see
where
we
go.
G
G
G
If
there's
anybody
in
the
room,
we've
had
some
participation
from
folks
in
the
room,
but
it
seems
like
the
folks
who
really
care
about
this
or
folks
like
Willie
and
Brad
fits
and
because
of
how
were
you
is
there
he
is
was
this?
Is
this
one
of
the
issues
that
you
were
really
interested
in?
If
remember?
No,
not
really!
Oh
well,
you
live
in
hope,
so
does.
Does
anybody
want
to
volunteer
to
try
and
collect
some
data
about
this,
because
otherwise
I
don't
see
a
way
to
move
it
forward?.
S
Q
Q
G
Think
another
part
of
the
problem
is:
is
that
if
I
characterize
the
folks
coming
forward
and
asking
for
this,
it's
it
sure
would
be
nice.
It's
kind
of
the
approach
they're
taking
and
it
doesn't
seem
like
a
lot
of
other
people
care,
and
so
there's
not
a
lot
of
energy
and
when
you're
talking
about
potentially
breaking
things,
that's
not
enough
to
get
across
the
bar
Allen.
U
L
Q
Now,
when
I
worked
on
issue
visas,
we
found
a
couple
of
clients
where
I
as
had
that
behavior
it
broke
them.
We
had
to
help
them
river
it
now
they
are
rare,
it's
like
an
old
version
of.net
and
it's
something
in
Java
from
IBM
that
we
don't
have
no
more
detail
about
and
I
think
the
list
has
know
through
the
issue.
A
few
others
may
have
been
mentioned.
I
think.
Q
Clients
that
are
clients
to
half-closed
and
we're
trying
to
the
request
is:
can
we
give
guidance
to
servers
that
it's
okay
to
make
this
assumption,
or
that
you
must
not
make
this
assumption,
because
right
now
isn't
Anton
find
surfers,
have
gone
both
ways
and
if
client
and
server
pick
different
directions
that
the
connection
fails.
At
the
end
of
the
request.
I
So
I
mean
I
think
the
only
thing
I
would
wowthat's
waked
up.
The
only
thing
I
would
add
to
that
would
be
that
the
servers
generally
interpret
or
when
they
do
interpret
the
half-closed,
as
essentially
a
full
abandonment
of
the
session.
They
are
right
for
some
approximation
of
several
nines
worth
of
being
right
and
there
are
some
scaling
properties
in
true
associated
with
not
doing
that
right.
So
sometimes
you
have
clients
that
just
plain
go
away
and
black
hole,
they
send
a
fin
and
they
disappear
off
the
network
and
that.
I
I
More
often
than
not,
and
so
if
I
were
to
to
clarify
the
rule,
I
would,
in
my
view,
say
that
that's
an
important
scaling
property
of
HTTP
and
and
we
we
should
be
biased
in
favor
of
that,
instead
of
really
old
clients
that
are
kind
of
hard
to
identify,
while
still
acknowledging,
perhaps
in
the
document
that
you
might
create
some
very
old
legacy.
Breakage
Mike.
Q
T
T
Martin
Duke
I
just
wanted
made
a
good
point,
which
is
that
for
clients
there
is
a
signal
if
they
no
honor
to
get
anything,
that's
called
TCU
reset
and
they
should
use
that
if
they
don't
want
the
data
and
it's
perfectly
reasonable
to
shut
down
the
sin
side
of
a
connection
and
wait
to
receive
the
rest.
I.
H
Can
imagine
it
being
very
reasonable
to
say
clients
should
not
send
a
half
closed,
but
servers
have
to
accept
it.
Just
that's
I
think
that's
the
most
conservative
approach,
so
I
guess
do
we
want
to
figure
out?
Do
we
want
to
do
any
text
here
like
do
we
first
want
to
say
like?
Should
we
clarify
this?
Do
we
agree
that
this
is
an
area
that
has
lack
of
clarity?
So
do
you
want
him
on
that?
D
O
Bro
again,
I
I,
think
somewhere
in
that
in
the
in
the
issue,
I
volunteered
to
look
into
it
when
we
get
to
that
part
of
rewriting
the
messaging
spec,
because
right
now
we
haven't
delved
into
how
do
we
pull
all
the
semantics
out
of
the
messaging
and
we
are
set
to
do
that
very
soon.
In
theory
at
least
so
I,
you
know
I'm
still
on
the
hook
for
doing
that.
I
still
agree
that
needs
to
be
done,
but
I
don't
know
what
shape
or
form
it
will
be.
At
this
point.
H
U
H
D
D
H
G
H
T
G
O
Specifically
for
this
report,
Brad
wanted
it
as
an
indication
that
the
client
is
no
longer
interested
in
the
content
and
that
receiving
a
half-closed
was
treated
as
equivalent
to
receiving
a
reset,
and
the
the
problem
with
that
being
is
that
it's
never
really
had.
That
interpretation
asked
there's
always
been
acts
around
trying
to
you
for
other
reasons.
O
Q
Mike
Bishop
again
I,
honestly,
I
think.
The
first
thing
we
need
to
put
in
there
is
client
should
not
do
this
and
then
between
whether
the
server
should
ignore
that
the
vin
arrived
or
must
ignore
that
the
Fen
arrived
nee
must
is
probably
less
breakage,
because
otherwise
you
have
to
shoulds
that
can
overlap
and
break,
and
that's
where
we
are
today.
It.
H
U
U
M
You
had
a
question
yeah.
This
is
Jeffrey
askin,
I'm
sympathetic
to
Brad's
comment
in
the
that's
on
the
screen
that
it
is
difficult
for
them
in
a
in
a
portable
way
to
distinguish
in
from
reset
I.
Don't
have
any
personal
experience
with
this
and
Brad
isn't
here
to
give
his
argument
so
taking
taking
the
proposal,
which
would
say
no
you're
wrong
seems
it
seems
strong.
T
I
Yeah
I'm,
not
clarifying
I,
guess
I'm
advocating
so
what
you
know:
Tommy
Tommy
consider
the
Holmes
but
I
I
think
the
server
must
not
reset
might
be
overstepping
giving
some
existing
server
behavior.
That
I
think
actually
is
in
the
interest
of
HTTP
and
the
internet.
Although
I
mean
I
I
appreciate
the
technical
consideration
of
the
long
tail
of
the
1995
CGI
client,
but
I'm
not
sure
like
that's
actually
the.
I
Q
I
X
V
H
I
mean
I
I
can
see
that
there's
probably
some
room
for
the
editors
to
massage
the
text
on
it.
You
know,
even
if
we
go
in
kind
of
with
mention
of
saying
you
know,
you
must
not
just
use
this
fin
to
reset
your
connection.
There's
gonna
be
some
wiggle
room
I.
Imagine
of
saying
you
know,
but
maybe
you
can
put
it
on
a
list
idle
out
quickly
because
it's
you
know
you
do
something
else,
but
don't
use
that
alone
as
a
signal.
H
H
G
S
G
G
If
we
can
do
that,
could
you
put
up
your
hand
if
you
support
this
proposal?
Mike
wish
the
bishop
proposal?
Yes,
it
will
be
remembered
in
history
as
the
vision
proposal
and
if
you
do
not
support
the
proposal.
Okay,
we
have.
We
have
three
ish.
Do
nots,
I,
think
good,
sound
and
anybody
interested
in
explaining
why
they
think
this
is
a
bad
thing.
You.
G
G
Okay,
number
seven:
this
is
Julian's.
Oh
yes,
so
Julian
made
the
comment
that
we
should
probably
discuss
what
it's
appropriate
to
do,
something
like
defining
the
the
syntax
of
a
header
as
an
alternation
of
two
different
things
like
either
a
star
or
a
list
of
things,
and
whether
that's
a
good
thing
or
not
and
and
and
error
handling
around
that,
because
it's
an
awkward
construct
in
a
lot
of
cases
and
I'm
made
the
content
comment
that
I'd
prefer
to
document
this
as
an
anti-pattern
and
he
agreed.
R
E
R
O
O
Validation
scheme
or
whatever
so
I
mean
if
you
have
a
start,
comma
whatever
it
has
the
same
effect
as
just
star
there
in
all
those
cases.
So
it's
never
really
been
a
concern.
In
the
past,
I
mean
I
agree
that
from
a
cleanliness
perspective,
it's
it's
kind
of
been
pooped
on,
but
that's
it's
not
the
only
thing
that
we
have
that's
weird
in
a
CP,
so
I
don't
think
at
this
point.
I
don't
see
any
way
to
fix
it.
N
Julian
just
to
clarify
this
is
not
about
changing
the
spec
in
some
way.
It's
I
guess
guidance
about
for
people
defining
new
head
of
yes
and
I.
Think,
while
the
choices
to
either
have
it
explicitly
as
an
odd
service
or
to
just
make
it
a
list
and
put
the
constraints
into
the
pros,
and
we
have
the
related
issues
that
talk
about.
We
started
our
fields
and
the
question
is:
is
this
a
list
our
pair
of
years?
O
But
I
did
actually
change
the
spec
since
this
was
put
in
here.
So
that's
no
longer
a
concern,
at
least
from
others,
to
other
restrictions.
Standpoint
in
the
sense
that
you
know
there's
a
part
of
the
spec
where
it
says
where
it
talks
about
you.
If
you
have
list
format
you
it's
a
comma
separator.
This
is
list
format
and
if
you
don't
have,
if
it's
not
defined
as
list
format,
then
you
can't
use
the
comma.
O
You
can't
have
multiple
forms
of
that
and
what
it
now
says
is
if
you
have
at
least
one
of
the
alternatives
for
the
field
definition
being
a
list
format,
then
you
can
have
a
comma
separate
so
from
there
used
to
be
a
logic.
Failure
in
the
spec.
Now
it's
just
an
ugly
failure
and
like
I
said,
but
we
can
change
the
spec
all
we
want,
but
that's
not
going
to
change
the
fact
that
there
are.
There
exists,
these
definitions
for
these
header
fields
and
one
unlikely
to
change
them.
Just
for
this
reason,
I
don't.
G
N
So
so
job
I
just
wanted
to
point
out
that
there's
if
we
have
the
syntax
s
and
the
ID
service
example,
we've
got
potential
into
our
problems.
Then,
for
instance,
you
have
star,
comma
and
one
recipient
might
say
that
doesn't
conform
to
the
ANF
and
ignores
it,
and
the
other
sees
a
list
type
head
of
length.
One
and
says
that's:
okay,
so.
N
N
G
G
G
I
I
Around
this,
since
we
last
met,
this
is
mostly
thankless
work,
but
I
will
offer
my
thank
you,
so
you
get
one
in
there.
Many
others
should
do
the
same,
and
if
you
would
like
to
make
1,400
github
entries
yourselves
I'm
sure
you
can,
you
know,
make
the
acknowledgments
but
I
wonder
if
the
the
editor
team
would
like
to
talk
about
schedule
and
how
they
think
this
project
has
been
doing
is
a
pretty
big
scope,
and
you
know
what
we
have
in
our
future.