Introduce STATE_RESERVED_REMOTE. No behavioral changes

net/spdy/spdy_network_transaction_unittest.cc

Index: net/spdy/spdy_network_transaction_unittest.cc
diff --git a/net/spdy/spdy_network_transaction_unittest.cc b/net/spdy/spdy_network_transaction_unittest.cc
index 46f0500fd1d46950ad40e5606137e1a7db6d71a7..a35f5f5fd2212cc12fefcf433ffc67d9b9aeabe2 100644
--- a/net/spdy/spdy_network_transaction_unittest.cc
+++ b/net/spdy/spdy_network_transaction_unittest.cc
@@ -5338,6 +5338,8 @@ TEST_P(SpdyNetworkTransactionTest, ServerPushClaimBeforeHeaders) {
   EXPECT_TRUE(data.at_write_eof());
 }
 
+
+// TODO(baranovich): HTTP 2 does not allow multiple HEADERS frames

[Johnny, 2014/06/05 02:56:04]

This isn't quite right. There's no restriction on multiple HEADERS frames in
HTTP/2 that I'm aware of.

They are disallowed by [1], and I think it's fine to leave them as disallowed,
but we should probably avoid adding further places which restrict this or
comment it as such.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_stre...

[baranovich, 2014/06/05 19:16:57]

http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-8.1 states that:

An HTTP message (request or response) consists of:

   1.  one HEADERS frame, followed by zero or more CONTINUATION frames
       (containing the message headers; see [HTTP-p1], Section 3.2), and

   2.  zero or more DATA frames (containing the message payload; see
       [HTTP-p1], Section 3.3), and

   3.  optionally, one HEADERS frame, followed by zero or more
       CONTINUATION frames (containing the trailer-part, if present; see
       [HTTP-p1], Section 4.1.2).

And unless we support trailing headers, I think this means that only one HEADERS
frame is allowed.

On 2014/06/05 02:56:04, Johnny wrote:

 TEST_P(SpdyNetworkTransactionTest, ServerPushWithTwoHeaderFrames) {
   // We push a stream and attempt to claim it before the headers come down.
   scoped_ptr<SpdyFrame> stream1_syn(
@@ -5465,24 +5467,7 @@ TEST_P(SpdyNetworkTransactionTest, ServerPushWithTwoHeaderFrames) {
   EXPECT_TRUE(response2.headers.get() != NULL);
   EXPECT_EQ("HTTP/1.1 200 OK", response2.headers->GetStatusLine());
 
-  // Verify we got all the headers
-  if (spdy_util_.spdy_version() < SPDY3) {
-    EXPECT_TRUE(response2.headers->HasHeaderValue(
-        "url",
-        "http://www.google.com/foo.dat"));
-  } else {
-    EXPECT_TRUE(response2.headers->HasHeaderValue(
-        "scheme", "http"));
-    EXPECT_TRUE(response2.headers->HasHeaderValue(
-        "path", "/foo.dat"));
-    if (spdy_util_.spdy_version() < SPDY4) {
-      EXPECT_TRUE(response2.headers->HasHeaderValue(
-          "host", "www.google.com"));
-    } else {
-      EXPECT_TRUE(response2.headers->HasHeaderValue(
-          "authority", "www.google.com"));
-    }
-  }
+  // Verify we got all the headers from both header blocks.

[Johnny, 2014/06/05 02:56:04]

Expose and verify request headers on the transaction? Or add a TODO to do this
later?

[baranovich, 2014/06/05 19:16:57]

I'm not quite sure what and how should be checked then. Request headers are
available for transaction, but these are headers set by the client. We need
something like "server implied request headers", but that would be a kind of
abstraction leak.
Do we really need to check it there?
Technically, we check here that final response has headers from SYN_STREAM and
all HEADERS frames. Facts about correct push stream routing are checked in other
tests and getting 200 OK status line for a given URI implies that everything
worked. For this test, scheme/path/host headers are no more then just headers
imo, so if they're unavailable, we may check some other =) Maybe I'd better add
some headers to |initial_headers| block (which is used for SYN_STREAM
construction) which will go to response section instead?
PS Did that in the patch #4.
On 2014/06/05 02:56:04, Johnny wrote:

   EXPECT_TRUE(response2.headers->HasHeaderValue("hello", "bye"));
   EXPECT_TRUE(response2.headers->HasHeaderValue("status", "200"));