Server push SYN_STREAM before associated SYN_REPLY

[Matthew Steele]

I'm working on server push in mod_spdy, and the implementation I am
currently testing will sometimes send the SYN_STREAM for the pushed
stream _before_ sending the SYN_REPLY for the associated stream.
Chrome does not seem to like it; it responds to the push with a
RST_STREAM with PROTOCOL_ERROR.

Is this ordering against the spec? As near as I can tell, the spec
only requires that the associated stream be "open", and a stream is
"open" from the moment the SYN_STREAM is sent by the client, even if
the SYN_REPLY hasn't yet arrived.

This ordering quirk is totally fixable in mod_spdy (I haven't done so
yet, so it may even be that that's not the real reason that Chrome is
upset with the pushed stream), but I'm wondering if the spec could be
clarified on this point. Is the pushed SYN_STREAM permitted to come
before the associated SYN_REPLY, or must it come after?

Cheers,
-Matthew

[Hasan Khalil]

This is clearly either a bug in Chrome or a bug in the spec, depending on how you want to slice it. I vote for the former; it may be completely reasonable for the server to know that a particular resource will be needed before it even has its response headers for the initial request ready.

Either way, this should be included in a client-side compliance suite whenever that happens.

    -Hasan

[Ryan Hamilton]

Yup, it was from the compliance suite work that this question came up :>

[Mike Belshe]

Sweet - good catch.

I think I wrote this bug into Chrome, only because I hadn't really considered the option that a server would send a push before the SYN_REPLY.  But the stream exists and is open on both sides as soon as we have the SYN_STREAM, so it seems legit to me.

Ryan - can you get the bug filed on chrome?

Do I need to update the spec at all?

Mike

[Ryan Hamilton]

I've filed http://code.google.com/p/chromium/issues/detail?id=114057.  I think it might be worth adding a note to 3.2.1 of the spec.  Currently is says:

To minimize race conditions with the client, the SYN_STREAM for the pushed resources MUST be sent prior to sending any content which could allow the client to discover the pushed resource and request it.

I might add a sentence saying something like:

 the SYN_STREAM for the pushed resources MAY be sent prior to sending the SYN_REPLY for the associated stream.

BTW, I'me unable to view the SPDY spec in chrome or safari today.  Did something change recently?  When I view it in firefox, I see warnings about target names not existing:

WARNING: The following target names do not exist: RFC2616, RFC0793, RFC6454, RFC1950, RFC2616, RFC6454, RFC1738, RFC1738, RFC2617, RFC4559, RFC6454, RFC6454, RFC2119

Cheers,

Ryan

[Mike Belshe]

On Mon, Feb 13, 2012 at 12:20 PM, Ryan Hamilton <r...@google.com> wrote:

I've filed http://code.google.com/p/chromium/issues/detail?id=114057.  I think it might be worth adding a note to 3.2.1 of the spec.  Currently is says:

To minimize race conditions with the client, the SYN_STREAM for the pushed resources MUST be sent prior to sending any content which could allow the client to discover the pushed resource and request it.

I might add a sentence saying something like:

 the SYN_STREAM for the pushed resources MAY be sent prior to sending the SYN_REPLY for the associated stream.

ok

 

BTW, I'me unable to view the SPDY spec in chrome or safari today.  Did something change recently?  When I view it in firefox, I see warnings about target names not existing:

WARNING: The following target names do not exist: RFC2616, RFC0793, RFC6454, RFC1950, RFC2616, RFC6454, RFC1738, RFC1738, RFC2617, RFC4559, RFC6454, RFC6454, RFC2119

Yeah - sorry about that.  I modified the xml file to use "proper"  refernces, and the xslt is not smart enough to process these for chrome/safari, although firefox works fine.  When I run the real xml2rfc tool, it cleans them all up and makes them look pretty.

Perhaps I need to start using that instead of pointing people directly at the xml.

mike