SPDY Spec
Mike Belshe
Mike
Luke-Jr
> I'm getting ready to finalize the SPDY specification, so I have posted it
> on github. This is a significant change since the last draft, and I hope
> is getting close to a version worthy of submission to the ietf. But there
> is still a lot of work to do.
>
> I welcome and invite anyone willing to go through it to checkout a copy,
> make edits, and contribute them back. github makes this process very easy.
>
> You can view the current spec here: http://mbelshe.github.com/SPDY-
> Specification/
Is there a human-readable version somewhere?
Mike Belshe
Gabriel Ciuloaica
Mike Belshe
Hi Mike,There is something wrong in the SPDY spec. In the section 7. "Incompatibilities with SPDY draft #2", you are mentioning that Name/value block will be included only in HEADERS frame, but the description of SYN_FRAME and SYN_REPLY frame still mentions Name/Value block...
Luke-Jr
I don't like bloated browsers. Is there standard HTML/CSS?
Mike Belshe
James Cloos
MB> This should be human readable on FF, Chrome, or IE9.
There is no stylesheet so, no, it is not readable.
In fact it is worse in a browser than the raw xml.
(I looked at both a local checkout and the posted url.)
-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
James Cloos
I should have continued:
but (the current version of) xml2rfc renders it propperly.
And xml2rfc's xml2html variant generates html output which
looks great in all browsers.
Mike Belshe
Fedor Indutny
Cheers,
James Cloos
MB> http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml
That was what I tested.
I tried again with more browsers. FF3 and opera do render it. But
both arora (webkit) and SM21 (same rendering engine as FF4) fail to
use a stylesheet.
The SM21 rendering should be identical to a FF4 rendering.
Roy T. Fielding
> I'm getting ready to finalize the SPDY specification, so I have posted it on github. This is a significant change since the last draft, and I hope is getting close to a version worthy of submission to the ietf. But there is still a lot of work to do.
>
> I welcome and invite anyone willing to go through it to checkout a copy, make edits, and contribute them back. github makes this process very easy.
Er, not much time for editing at the moment, but editorially I suggest
replacing "receiver" with "recipient" everywhere it occurs.
....Roy
Mike Belshe
....Roy
Leen Besselink
As I was reading part about Server Push Transactions of the
specification I noticed it mentioned browser same-origin policy as the
way for the browser to check if the pushed response should be accepted.
Recently I read a study Microsoft had done called HTTPi [1] * where they
used the X-Content-Security-Policy from the Mozilla CSP specification. [2]
I'm just thinking out loud, as I'm not sure how useful it would be, but
could something like not also be added to the SPDY-specification to
allow for content from other domains to be pushed as well ?
Have a nice day,
Leen.
* the HTTPi study [0] [1] is kind of interresting as it is trying to
solve things SPDY does not solve, to allow intermediate servers
(proxies/CDN) to cache/serve static content.
[0] http://research.microsoft.com/apps/pubs/default.aspx?id=148963
[1] http://research.microsoft.com/pubs/148963/htti-techreport.pdf
[2]
https://developer.mozilla.org/en/Security/CSP/Introducing_Content_Security_Policy
Mike Belshe
I suppose SPDY could make them mandatory, but we have been trying to avoid those types of restrictions in general.
Alexandre Prates
syn_reply field must contain the same block name / value? For the
specification given that this frame has fixed length of 4 bytes.
Regards,
Alexandre Prates
James A. Morrison
2.3.1: Why is it a session error not "not increase" the stream id for
new streams vs a stream error if a stream
id is used twice in a row? These seem like the same error to me. I'm
fine with either having to close the session
or simply resetting offending stream.
2.3.1: The specification doesn't say that -1 or -2324 are invalid, it's only
sort of implied since the top bit of a 32 bit number is removed for the
control frame bit.
Better than mentioning negative numbers anywhere else, you could say
"All integer values, ... are in unsigned in network byte order." in section 2.2.
2.3.2: Please link to where priorities are defined or the SYN_STREAM/SYN_REPLY
frames. You still have a TODO about the trickle priority. Is this
still useful? You
haven't defined anything else about the priorities, so you can
probably get rid of the
TODO.
2.3.3: You said you got rid of the headers frame, correct?
2.3.4: More uses of the HEADERS frame.
2.6.2: Should STREAM_IN_USE or STREAM_ALREADY_CLOSED be listed in
2.6.3?
2.6.6: Do you have more errors to put in?
2.6.7: So the headers frame is staying, ok.
2.7: I think you should explicitly state that the spec is for version = 3.
3.2.1: Do you mean SYN_STREAM instead of HEADERS?
3.x: I think you should deal with the 100 response codes
explicitly.
3.3: You may as well say that pushed content must at least
be privately cacheable.
If you would like me to make any of these changes, my github user is phython. I
can make a branch that you can pull from.
--
Thanks,
Jim
http://phython.blogspot.com
Roy T. Fielding
The word receiver was invented for the telephone (IIRC) and later
extended to radio to be the listening device. Recipient is the
traditional English noun for the recipient of a message, letter, etc.
In a spec, it is just my preference, though the noun pairs should be
consistently transmitter/receiver or sender/recipient. NICs are
sometimes referred to as transceivers, but most app-level specs
use the terms sender/recipient.
Not important -- it just stood out on a quick scan (all I had time
for before heading out on vacation).
....Roy
Alexandre Prates
frame-update windows because there are only two fixed field of 32 bits
after the Length field.
Regards,
Alexandre Prates
William Chan (陈智昌)
2.2.2: I just realized that DATA frame compression is specified on a frame
by frame basis. Is this flexibility really intended / desired? If so, what's
the use case?
2.3.5: We should probably mandate sending a RST_STREAM with a PROTOCOL_ERROR
if further data is sent after a FLAG_FIN.
2.3.6: Likewise, we should mandate sending a RST_STREAM with a
PROTOCOL_ERROR if further data is sent after the stream is closed.
2.6.2: You don't mention STREAM_IN_USE/STREAM_ALREADY_CLOSED elsewhere.
Maybe STREAM_ALREADY_CLOSED should be used for 2.3.5/2.3.6 errors.
2.6.9: Have you defined what the version number is in this draft? 3?
2.6.10: How should non-lowercased headers be handled? RST_STREAM with
PROTOCOL_ERROR?
2.6.10.1: "The Name/Value Header Block is the portion of the HEADERS frame
which follows the Stream-ID field." Why only the HEADERS frame?
3.2.1: I'm not sure why we document that
Connection/Keep-Alive/Proxy-Connection must be ignored, rather than must not
be sent. "If a client sends a HEADERS without all of the method, host, path,
scheme, and version headers, the server must reply with a HTTP 400 Bad
Request reply." Probably should capitalize MUST.
3.2.2: I find it interesting that if the request leaves out certain HTTP
headers (method/scheme/etc), the response must be a HTTP 400 Bad Request,
but if the response leaves out the status/version header
Fedor Indutny
Cheers,
William Chan (陈智昌)
SPDY version in Chrome and Google servers. We don't plan on making
exceptions.
Mike Belshe
Hi, Another suggestion, the field has fixed length of 8 bytes in the
frame-update windows because there are only two fixed field of 32 bits
after the Length field.
Regards,
Alexandre Prates
Mike Belshe
Comments:
2.2.2: I just realized that DATA frame compression is specified on a frame
by frame basis. Is this flexibility really intended / desired? If so, what's
the use case?
2.3.5: We should probably mandate sending a RST_STREAM with a PROTOCOL_ERROR
if further data is sent after a FLAG_FIN.
2.3.6: Likewise, we should mandate sending a RST_STREAM with a
PROTOCOL_ERROR if further data is sent after the stream is closed.
2.6.2: You don't mention STREAM_IN_USE/STREAM_ALREADY_CLOSED elsewhere.
Maybe STREAM_ALREADY_CLOSED should be used for 2.3.5/2.3.6 errors.
2.6.9: Have you defined what the version number is in this draft? 3?
2.6.10: How should non-lowercased headers be handled? RST_STREAM with
PROTOCOL_ERROR?
2.6.10.1: "The Name/Value Header Block is the portion of the HEADERS frame
which follows the Stream-ID field." Why only the HEADERS frame?
3.2.1: I'm not sure why we document that
Connection/Keep-Alive/Proxy-Connection must be ignored, rather than must not
be sent.
"If a client sends a HEADERS without all of the method, host, path,
scheme, and version headers, the server must reply with a HTTP 400 Bad
Request reply." Probably should capitalize MUST.
3.2.2: I find it interesting that if the request leaves out certain HTTP
headers (method/scheme/etc), the response must be a HTTP 400 Bad Request,
but if the response leaves out the status/version header
Mike
Mike Belshe
William, MikeWill ID in settings frame stored in network byte order in next protocol implementation in Chrome?
Yoav
1. As we have learned from the HTTP spec, defining "zlib" compression
is not enough. The original zlib terminology refers to the compression
algorithm as "deflate" (http://www.gzip.org/zlib/rfc-deflate.html)
when "zlib" (http://www.gzip.org/zlib/rfc-zlib.html) and
"gzip" (http://www.gzip.org/zlib/rfc-gzip.html) are wrappers using
"deflate" internally. The HTTP spec defined the "deflate" content
encoding as using "zlib". That caused a lot of confusion in various
implementations and made "deflate" practically unreliable.
IMO the SPDY spec should explicitly define which compression it uses,
and stick to the original terminology. I.e. if we want to use raw
deflate (since we don't need a checksum), we should call that
compression "zlib's deflate algorithm as defined in RFC 1951" (or
something of that nature).
2. Regarding compression contexts for data:
There can be scenarios where a global compression context can give
better results then a compression context per resource (One example is
a series of small & similar JS/CSS files).
OTOH, that will force using the same stream for multiple resources in
situations where multiple streams may have given better results (in
terms of speed).
Another problem is that the content author and server side (who may
have prior knowledge as to what compression context usage would be
more beneficial) have no saying in the matter. Assigning resources to
stream (as far as I understand it) in a traditional browsing scenario,
is the client-side's job. The client can use heuristics (such as
assigning dedicated streams according to requesting tag type) but
naturally, it has less info regarding the actual data that's going to
come in.
I think the "static, up to 16 compression contexts" proposal from
section 4.5 could have resolved the above issues if the compression
context number could be given on a per resource/frame basis from the
server side. I believe the benefits for such a compression scheme
would outweigh the extra implementation complexity/cost. A short, non
scientific test I ran shows 5-10% compression improvement from mutual
ZLIB context between text resources.
We should take the opportunity of introducing SPDY to also enable
newer compression algorithms such as bzip (which was removed from
chrome due to intermediary proxies trouble as far as I understand) and
7zip. A zlib variant with a larger window might also be beneficial in
mutual context scenarios. In yet another non-scientific test I ran, I
see 7zip compressing HTML,CSS & JS, producing files that are 30%
smaller then gzip (with a mutual context for both), with relatively
similar decompression speeds. The server can then decide regarding the
CPU vs. BW tradeoff.
All in all, IMO removing data compression from the specification would
be a wasted opportunity to provide significant data reduction to the
web.
Yoav
http://blog.yoav.ws
On May 26, 5:44 pm, Mike Belshe <mbel...@google.com> wrote:
> On Thu, May 26, 2011 at 6:40 AM, William Chan (陈智昌)
Simon B.
get wrapped in SSL, maybe all compression can be done by SSL?
If SPDY will do compression -- things to consider when choosing:
* There might be a point in using the same compression as for HTTP, in
that a web server can precompress all its static resources. (Maybe
servers like nginx and varnish already does this?)
* Is there risk of degrading overall performance if compressed SPDY is
tunnelled through SSL that also does compression?
* For non-static content there is no need to allow pre-compression,
thus a more modern compression can be pushed to gain adoption. On
http://stackoverflow.com/questions/124239/fastest-c-file-compression-library-available
I found hints towards LZMA. Either way, any new algorithm must come
with well-tested code and no "problems" of copyright, patents, etc.
Also Google Chrome want's to have a smaller binary (just speed, or
perhaps aiming for embedded use?) and thus may reject adding big new
libs to its codebase, making deflate an easy choice to avoid adding
more code.
Simon B.
> thus a more modern compression can be pushed to gain adoption.
it combines several different compression methods apart from LZMA -
and freearc also gives some trouble license-wise.
Google internally supposedly uses http://code.google.com/p/snappy/
which seems tiny enought and may come with benefits regarding
licensing.
More on snappy: http://code.google.com/p/snappy/source/browse/trunk/README
William Chan (陈智昌)
William Chan (陈智昌)
confusing/wrong. Examples:
* http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#StreamHalfClose
says: "If an endpoint receives a data frame after the stream is
half-closed, it must send a RST_STREAM to the sender with the status
STREAM_ALREADY_CLOSED." This is vague and should be clarified. It
could be interpreted such that, if the client has set the FIN flag in
its SYN_STREAM, receives a SYN_REPLY without a FIN, and then receives
data frames, that the client should respond to the data frames with a
RST_STREAM.
* http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#SYN_REPLY
says: "If an endpoint receives a SYN_REPLY frame for a stream already
in the half-closed state, it MUST issue a stream error (Section 2.4.2)
with the error code STREAM_ALREADY_CLOSED." I'm confused by this. If
the client's SYN_STREAM already had a FIN, and thus the stream is
half-closed, it seems perfectly reasonable to send a SYN_REPLY. I'm
also not sure when this is applicable. Perhaps it's meant to cover the
case when the server has already sent a SYN_REPLY with a fin or a data
frame with a FIN, but then sends another SYN_REPLY for the same
stream? But that would be covered in the previous sentence which says:
"If an endpoint receives multiple SYN_REPLY frames for the same active
stream ID, it MUST issue a stream error (Section 2.4.2) with the error
code STREAM_IN_USE." There is also some ambiguity about which of these
two sentences applies to the fully closed state, STREAM_ALREADY_CLOSED
or STREAM_IN_USE?
Perhaps I'm being too anal, but I think the descriptions could be clarified.
Also, I see that you've updated the spec wrt the invalid headers like
Connection. The request headers section notes that these headers MUST
not be sent: "The Connection, Keep-Alive, and Proxy-Connection headers
are not valid and MUST not be sent."
(http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#rfc.section.3.2.1)
However, the response headers section does not include the same "MUST
not be sent" language: "The Connection and Keep-alive response headers
are no longer valid."
(http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#rfc.section.3.2.2).
And for both the requests and responses, the spec notes that
Transfer-Encoding is no longer valid. How about we add the same
language and say that it must not be sent?
On Sun, Jun 12, 2011 at 4:01 PM, William Chan (陈智昌)
William Chan (陈智昌)
vs name/value header block lengths, in the Chromium SPDY
implementation (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/spdy/spdy_framer.cc&exact_package=chromium&q=SpdyFramer&type=cs&l=233)
we return RST_STREAM
(http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/spdy/spdy_session.cc&type=cs&l=1213).
The problem here is, since we compress the name/value header block,
isn't the compression context horked now? Should the spec document
this case and treat it as a session error instead of a stream error?
On Mon, Jun 13, 2011 at 4:01 PM, William Chan (陈智昌)