Can SPDY/3.1 clients start with stream ID 3 ?
Jesse Wilson
The SPDY/3.1 spec says the following about stream IDs:
A stream is created by sending a control frame with the type set to SYN_STREAM (Section 2.6.1). If the server is initiating the stream, the Stream-ID must be even. If the client is initiating the stream, the Stream-ID must be odd. 0 is not a valid Stream-ID. Stream-IDs from each side of the connection must increase monotonically as new streams are created. E.g. Stream 2 may be created after stream 3, but stream 7 must not be created after stream 9. Stream IDs do not wrap: when a client or server cannot create a new stream id without exceeding a 31 bit value, it MUST NOT create a new stream.
The stream-id MUST increase with each new stream. If an endpoint receives a SYN_STREAM with a stream id which is less than any previously received SYN_STREAM, it MUST issue a session error (Section 2.4.1) with the status PROTOCOL_ERROR.
To make room for a possible HTTP/1.1 to HTTP/2 upgrade, HTTP/2 clients skip stream ID 1 and start with stream ID 3. We started doing this in OkHttp for both HTTP/2 and SPDY/3.1 streams: starting all client stream IDs at 3.
But that caused the SPDY/3.1 server running on https://google.com to send GOAWAY frames reporting a PROTOCOL_ERROR. I tried https://twitter.com and https://facebook.com; neither site had a problem accepting 3 as the client’s first stream ID. Changing the client to start with stream ID 1 fixed the problem for https://google.com.
Is https://google.com behaving correctly?
Should the SPDY/3.1 spec mention that streams must start with 1 and not skip any IDs?
Thanks!
William Chan (陈智昌)
--
---
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/d/optout.
