HEADERS frame in draft 3 spec
William Chan (陈智昌)
"status" or "version" is missing from SYN_STREAM/SYN_REPLY was wrong.
I blame this on the spec not fully specifying SYN_STREAM/SYN_REPLY +
HEADERS interaction in HTTP.
In Chromium code (roughly draft 2 compliant), we check whether or not
a SYN_REPLY or SYN_STREAM has "status" or "version". If either is
missing, the headers are assumed to be incomplete, and a HEADERS frame
is still coming.
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/spdy/spdy_http_stream.cc&type=cs&l=327
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/spdy/spdy_http_utils.cc&type=cs&l=31
We need to clarify this behavior in the draft 3 spec. I don't remember
us saying we were planning on changing this behavior in draft 3, so I
think we need to codify it.
FWIW, I find it a bit hokey that missing this special headers implies
a HEADERS frame is coming. Perhaps it's better to use an explicit
control flag. Maybe that's wasteful.
Btw, once response headers are "complete", Chromium's network stack
will send it onwards to WebKit. The spec however says HEADERS frames
can be sent at any point
(http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#HEADERS:
"It may be optionally sent on an existing stream at any time. Specific
application of the headers in this frame is application-dependent.")
When application-dependent is specified, does that mean layering a
protocol other than HTTP? If so, then in the HTTP section of the spec,
we should specify the expected behavior.
Mike Belshe
> I think my earlier comment on needing to send a RST_STREAM when
> "status" or "version" is missing from SYN_STREAM/SYN_REPLY was wrong.
> I blame this on the spec not fully specifying SYN_STREAM/SYN_REPLY +
> HEADERS interaction in HTTP.
>
> In Chromium code (roughly draft 2 compliant), we check whether or not
> a SYN_REPLY or SYN_STREAM has "status" or "version". If either is
> missing, the headers are assumed to be incomplete, and a HEADERS frame
> We need to clarify this behavior in the draft 3 spec. I don't remember
> us saying we were planning on changing this behavior in draft 3, so I
> think we need to codify it.
>
> FWIW, I find it a bit hokey that missing this special headers implies
> a HEADERS frame is coming. Perhaps it's better to use an explicit
> control flag. Maybe that's wasteful.
- he didn't realize that his push responses needed to have all
headers, and thought that chrome had just hung, when really it was
waiting for a headers frame to deliver those values. I think this
supports your claim that this is a bit hokey.
We could have FLAG_END_OF_HEADERS which the sender should use when
finished sending headers. HEADERS frames received after the
FLAG_END_OF_HEADERS would be ignored.
>
> Btw, once response headers are "complete", Chromium's network stack
> will send it onwards to WebKit. The spec however says HEADERS frames
> can be sent at any point
> application of the headers in this frame is application-dependent.")
> When application-dependent is specified, does that mean layering a
> protocol other than HTTP? If so, then in the HTTP section of the spec,
> we should specify the expected behavior.
any time.
HTTP implementations (the application layer) very much do care, and we
need to specify explicitly. If we like the FLAG_END_OF_HEADERS
approach, then the layering for HTTP would likely specify that
responses won't start until after seeing a FLAG_END_OF_HEADERS.
This topic has overlap with clarifying the 100 continue related
issues, so the timing is good on this one. To deal with 100-
continues, we've really got multiple sets of headers that come back.
Further, there will be duplicate header names across the header
chunks, so we need to ease the uniqueness requirement only for the
case of 1xx header blocks. Unfortunately, in HTTP, I don't think
headers are supposed to be additive between response header blocks
(e.g. the HEADERS frame adding headers to an existing set from a
SYN_REPLY would be bad). So now we need to restructure how the
response headers work. To deal with this, I think we'll make it so
that a frame containing headers is inclusive of all headers in the
set. So, if you send a SYN_REPLY, and later a HEADERS, the HEADERS
block will completely replace all previously sent headers rather than
adding onto them. This will modify the way we implement server push a
bit, since now we'll need to resend all headers in the subsequent
HEADERS block, rather than just filling in the additive ones.
Mike
Dzonatas Sol
Can you solidify the packets (bitbuckets) of UDP such that the path is
seamless-solid state in units into number of udp? How many udp packets
are available on android to google, hop-by-hop? Does hypermedia need
hypershells?
> To deal with this, I think we'll make it so
> that a frame containing headers is inclusive of all headers in the
> set. So, if you send a SYN_REPLY, and later a HEADERS, the HEADERS
> block will completely replace all previously sent headers rather than
> adding onto them. This will modify the way we implement server push a
> bit, since now we'll need to resend all headers in the subsequent
> HEADERS block, rather than just filling in the additive ones.
>
Things remembered; isThing(DataType).
> Mike
>
>
>
>
>
>
>
--
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant