Upcoming SPDY/4 changes to bring it more in sync with the HTTP/2 draft

1,846 views
Skip to first unread message

William Chan (陈智昌)

unread,
May 8, 2013, 3:31:29 PM5/8/13
to spdy...@googlegroups.com
I'm going to start updating the draft SPDY/4 spec so we can stay more closely aligned with HTTP/2.

Here's what I have tracked so far to update:
* In HTTP/2, clients initiate sessions with 464f4f202a20485454502f322e300d0a0d0a4241520d0a0d0a ("FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n") followed by a SETTINGS frame. The magic byte sequence is to trigger fast fail at proxies. Servers must start with a SETTINGS frame.
* HTTP/2 frame headers replace Num-of-Entries-or-Stream-ID-or-ID with Stream Identifier. Number of entries is deduced from the frame data length field in the header.
* SYN_STREAM, SYN_REPLY, HEADERS => HEADERS+PRIORITY and HEADERS
* Error codes have been unified in HTTP/2. No more different codes for RST_STREAM and GOAWAY. Some error codes have been eliminated. Many have been renumbered.
* Per-stream & per-session flow control is able to be disabled with a WINDOW_UPDATE flag.
* PUSH_PROMISE *MUST* have an associated stream ID. I think this is a HTTP/2 design bug and I'll look into addressing it there. It seems to unnecessarily preclude other non-HTTP application layer protocols on top of the framing layer.
* PING changed a little bit. Instead of reserving a bit of the ID space to determine if this is a PING or a PING response, there's a new HTTP/2 flag called PONG (0x2)
* There's a new setting - FLOW_CONTROL_OPTIONS to disable flow control on a all streams or per-session basis.

This is definitely not exhaustive, just my first pass.

If there are any major disagreements about substance here, it's best to bring them up at ietf-h...@w3.org, since we are trying to track their http/2 draft spec changes.

Cheers!
Message has been deleted

Jeff

unread,
May 9, 2013, 5:55:09 PM5/9/13
to spdy...@googlegroups.com
I'd like to wait on merging two of the issues:

1) Let's delay a bit on merging the client sent magic bytes since it is unclear if these have to be sent on an NPN-negotiated link.
2) Let's not make the PING frame have arbitrary length -- I think this is still unresolved in HTTPbis and would prefer to keep the ID as the only payload for now.

Roberto Peon

unread,
May 9, 2013, 6:16:53 PM5/9/13
to spdy...@googlegroups.com
My preference is to always just send the bytes. This is what I've been arguing in the HTTP/2 context as well.
That makes the code less complex, and any performance disadvantage of doing so is really really tiny.
-=R


--
 
---
You received this message because you are subscribed to the Google Groups "spdy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spdy-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

William Chan (陈智昌)

unread,
May 9, 2013, 6:17:14 PM5/9/13
to spdy...@googlegroups.com
On Thu, May 9, 2013 at 6:55 PM, Jeff <jpi...@twitter.com> wrote:
I'd like to wait on merging two of the issues:

So I've already starting merging stuff in, but I'm happy to revert if we want. That said, my suggestion is don't implement that part of the draft yet. SPDY/4's not done yet anyway, there's more stuff to update. Does that seem reasonable? Or do you want me to actually rip parts back out?
 

1) Let's delay a bit on merging the client sent magic bytes since it is unclear if these have to be sent on an NPN-negotiated link.

 
2) Let's not make the PING frame have arbitrary length -- I think this is still unresolved in HTTPbis and would prefer to keep the ID as the only payload for now.

Well, I merged this one in. Whenever it gets resolved, I'll merge in that change too.
 

On Wednesday, May 8, 2013 12:31:29 PM UTC-7, William Chan wrote:
I'm going to start updating the draft SPDY/4 spec so we can stay more closely aligned with HTTP/2.

Here's what I have tracked so far to update:
* In HTTP/2, clients initiate sessions with 464f4f202a20485454502f322e300d0a0d0a4241520d0a0d0a ("FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n") followed by a SETTINGS frame. The magic byte sequence is to trigger fast fail at proxies. Servers must start with a SETTINGS frame.
* HTTP/2 frame headers replace Num-of-Entries-or-Stream-ID-or-ID with Stream Identifier. Number of entries is deduced from the frame data length field in the header.
* SYN_STREAM, SYN_REPLY, HEADERS => HEADERS+PRIORITY and HEADERS
* Error codes have been unified in HTTP/2. No more different codes for RST_STREAM and GOAWAY. Some error codes have been eliminated. Many have been renumbered.
* Per-stream & per-session flow control is able to be disabled with a WINDOW_UPDATE flag.
* PUSH_PROMISE *MUST* have an associated stream ID. I think this is a HTTP/2 design bug and I'll look into addressing it there. It seems to unnecessarily preclude other non-HTTP application layer protocols on top of the framing layer.
* PING changed a little bit. Instead of reserving a bit of the ID space to determine if this is a PING or a PING response, there's a new HTTP/2 flag called PONG (0x2)
* There's a new setting - FLOW_CONTROL_OPTIONS to disable flow control on a all streams or per-session basis.

This is definitely not exhaustive, just my first pass.

If there are any major disagreements about substance here, it's best to bring them up at ietf-h...@w3.org, since we are trying to track their http/2 draft spec changes.

Cheers!

--

Hasan Khalil

unread,
May 9, 2013, 6:28:32 PM5/9/13
to spdy...@googlegroups.com
On Thu, May 9, 2013 at 6:17 PM, William Chan (陈智昌) <will...@google.com> wrote:
On Thu, May 9, 2013 at 6:55 PM, Jeff <jpi...@twitter.com> wrote:
I'd like to wait on merging two of the issues:

So I've already starting merging stuff in, but I'm happy to revert if we want. That said, my suggestion is don't implement that part of the draft yet. SPDY/4's not done yet anyway, there's more stuff to update. Does that seem reasonable? Or do you want me to actually rip parts back out?

FWIW, this is my stance as well. We can pick and choose what to implement first. By the time we're done with that, it might be the case that some remaining bits have stabilized a bit more.
 
 

1) Let's delay a bit on merging the client sent magic bytes since it is unclear if these have to be sent on an NPN-negotiated link.



+1 for always sending.

 
2) Let's not make the PING frame have arbitrary length -- I think this is still unresolved in HTTPbis and would prefer to keep the ID as the only payload for now.

Well, I merged this one in. Whenever it gets resolved, I'll merge in that change too.


I don't see the need to implement this particular change, for example, all that soon anyway.

Roberto Peon

unread,
May 9, 2013, 6:31:12 PM5/9/13
to spdy...@googlegroups.com
imho, if it isn't something we strongly disagree with, we should merge into SPDY4 since that reduces the overhead for people doing implementations.

If it *is* something we strongly disagree with, we should be making noise at the IETF and getting it changed (or having our minds changed).

-=R

William Chan (陈智昌)

unread,
May 14, 2013, 3:12:26 PM5/14/13
to spdy...@googlegroups.com
Status update here. I believe I've made all my aforementioned updates. There are some definite changes, so implementers who have begun SPDY/4 draft implementations should note my commit logs for changes from previous versions, where I've called out all known substantive differences.

Note that the FLAG_HEADER_END (otherwise known as the header frame continuation bit) has been removed, but ietf-http-wg@ seems to very tentatively lean toward adding it in there. More discussion needed.

Also note there's an open issue to fix the arbitrary length PING frame payload as jpinner notes is silly.

It's on my plate to re-review the SPDY and HTTP/2.0 deltas and see if there are more substantive changes to make. After doing so, I will post my next set of planned updates.

Here are the commits:

https://github.com/grmocg/SPDY-Specification/commit/3e08f04b8c8c8df240359569aae8cc89a61aae22
Add connection header section

Update the frame header to make the second word always be the stream-ID.
As per HTTP/2.0 changes, # of entries is redundant information with the
length field. For non-stream specific frames, stream-ID is set to 0x0.

Note that 2 frames here had non-trivial changes:
* PING - previously the stream-ID field was a generic ID that would be
  echoed back. Now it's always 0, and the frame payload is an arbitrary
  byte sequence that gets echoed. Also introduces a new flag.
* GOAWAY - previously the stream-ID field was used for the "last good
  stream ID" field. Now it's kept as stream-ID and set to 0. This moves
  the last good stream ID field to the payload ahead of the status code.

SYN_STREAM,SYN_REPLY,HEADERS => HEADERS+PRIORITY,HEADERS
This reduces the number of frames as per HTTP/2.0 draft changes. It also
has the following effects:
* Eliminates some RST_STREAM error codes
* Eliminates the unidirectional stream stuff like HTTP/2.0
* Fixes up some of the push text to say PUSH_PROMISE instead of
  SYN_STREAM
* Removes the unused FLAG_HEADER_END

Update SPDY error handling with HTTP/2.0 changes.
* Copies the stream error handling and error codes from HTTP/2.0 draft
spec.
* In doing so, provides a single list of error codes.

TODO: Remove references to old error codes.
TODO: Update session error handling section too when confusion in that

Update RST_STREAM with HTTP/2.0 draft text.
This eliminates the error codes there and references the error code
section.

Update the GOAWAY frame and SessionErrorHandler sections.
Purely editorial changes. Note that the GOAWAY framing change was in an
earlier commit.

Update WINDOW_UPDATE from HTTP/2.0 draft spec.
Key change is addition of new flag for ending flow control for the
entire session or a specific stream.


Reply all
Reply to author
Forward
0 new messages