--
---
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.
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.
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!
--
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.I think it was decided that they are always sent: https://github.com/http2/http2-spec/commit/d6eefeafc362cd22a639bd608f8601b04820dc7b.
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.