[SPDY] Add flag and about:flags entry for SPDY/4 alpha 1

[SPDY] Add flag and about:flags entry for SPDY/4 alpha 1

BUG=230124
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=193832

[akalin, 2013-04-10 23:03:22]

+rch for review

Hasan, can you point me to a URL where I can test this? (send me a private
e-mail)

[Ryan Hamilton, 2013-04-10 23:07:53]

This is good, but I don't see any tests of SPDY/4.  What's the plan for that?

https://codereview.chromium.org/13845012/diff/1/net/http/http_stream_factory.cc
File net/http/http_stream_factory.cc (right):

https://codereview.chromium.org/13845012/diff/1/net/http/http_stream_factory....
net/http/http_stream_factory.cc:188: next_protos.push_back("spdy/3");
We could also consider adding spdy/3.1 in this list.  That way we could enable
4a1 for google, while still speaking 3.1 to twitter.

[akalin, 2013-04-10 23:20:04]

https://codereview.chromium.org/13845012/diff/1/net/http/http_stream_factory.cc
File net/http/http_stream_factory.cc (right):

https://codereview.chromium.org/13845012/diff/1/net/http/http_stream_factory....
net/http/http_stream_factory.cc:188: next_protos.push_back("spdy/3");
On 2013/04/10 23:07:53, Ryan Hamilton wrote:
> We could also consider adding spdy/3.1 in this list.  That way we could enable
> 4a1 for google, while still speaking 3.1 to twitter.

Done.

[akalin, 2013-04-10 23:20:59]

On 2013/04/10 23:07:53, Ryan Hamilton wrote:
> This is good, but I don't see any tests of SPDY/4.  What's the plan for that?

I think this is just so that Hasan or anyone else can run end-to-end SPDY/4
tests.

Aren't there tests of the framing layer at the spdy_protocol.* / spdy_framer.*
layer already?

[Ryan Hamilton, 2013-04-10 23:47:59]

On 2013/04/10 23:20:59, akalin wrote:
> On 2013/04/10 23:07:53, Ryan Hamilton wrote:
> > This is good, but I don't see any tests of SPDY/4.  What's the plan for
that?
> 
> I think this is just so that Hasan or anyone else can run end-to-end SPDY/4
> tests.
> 
> Aren't there tests of the framing layer at the spdy_protocol.* / spdy_framer.*
> layer already?

With spdy/2 and spdy/3 we have protocol-specific tests at the
HttpNetworkTransaction layer.  (SpdyNetworkTransactionTest and
HttpNetworkTransactionTest).  Are you proposing that we do not need these?

[akalin, 2013-04-10 23:57:26]

On 2013/04/10 23:47:59, Ryan Hamilton wrote:
> On 2013/04/10 23:20:59, akalin wrote:
> > On 2013/04/10 23:07:53, Ryan Hamilton wrote:
> > > This is good, but I don't see any tests of SPDY/4.  What's the plan for
> that?
> > 
> > I think this is just so that Hasan or anyone else can run end-to-end SPDY/4
> > tests.
> > 
> > Aren't there tests of the framing layer at the spdy_protocol.* /
spdy_framer.*
> > layer already?
> 
> With spdy/2 and spdy/3 we have protocol-specific tests at the
> HttpNetworkTransaction layer.  (SpdyNetworkTransactionTest and
> HttpNetworkTransactionTest).  Are you proposing that we do not need these?

Ah, I see what you mean. No, we probably should add spdy/4 tests. But for now, I
think it's okay to have this flag for end-to-end testing, even with only the
framing-level tests, right?

[Ryan Hamilton, 2013-04-11 00:21:20]

On 2013/04/10 23:57:26, akalin wrote:
> 
> Ah, I see what you mean. No, we probably should add spdy/4 tests. But for now,
I
> think it's okay to have this flag for end-to-end testing, even with only the
> framing-level tests, right?

Hm.  Possibly.  I notice that we have about 3 slightly different albeit related
versions of SPDY/4 coming down the pike in the near future.  I'd hate to have
4a1 4a2 and 4a3 all enabled without "end-to-end" tests.  What would you imagine
the ETA is on such tests.  It would be pretty easy (tm) to simply fork the
existing tests, though of course that incurs a technical debt burden that needs
to be paid off.  On the other hand doing the yak shaving necessary to unfork all
of the tests might take too long to come in time for spdy/4.

How are you thinking about how to handle this?

[akalin, 2013-04-11 00:29:29]

On 2013/04/11 00:21:20, Ryan Hamilton wrote:
> On 2013/04/10 23:57:26, akalin wrote:
> > 
> > Ah, I see what you mean. No, we probably should add spdy/4 tests. But for
now,
> I
> > think it's okay to have this flag for end-to-end testing, even with only the
> > framing-level tests, right?
> 
> Hm.  Possibly.  I notice that we have about 3 slightly different albeit
related
> versions of SPDY/4 coming down the pike in the near future.  I'd hate to have
> 4a1 4a2 and 4a3 all enabled without "end-to-end" tests.  What would you
imagine
> the ETA is on such tests.  It would be pretty easy (tm) to simply fork the
> existing tests, though of course that incurs a technical debt burden that
needs
> to be paid off.  On the other hand doing the yak shaving necessary to unfork
all
> of the tests might take too long to come in time for spdy/4.
> 
> How are you thinking about how to handle this?

I think I want to unblock Hasan and being able to run a SPDY/4 client against a
SPDY/4 server -- such testing will probably shake out bugs quicker than forking
/ unforking in the short-term.

It's also worth noting that the Chrome will only ever speak one alpha version of
Chrome, as will the servers.

So my preference would be to start the discussion around how best to get tests
for SPDY/4 separately and not block this CL on that. (I'd prefer to unfork the
tests, myself.) WDYT?

[akalin, 2013-04-11 00:36:44]

+jam for chrome/browser owners

[akalin, 2013-04-11 00:37:15]

chrome/* owners rather

[jam, 2013-04-11 02:14:18]

lgtm

[Ryan Hamilton, 2013-04-11 02:23:42]

On 2013/04/11 00:29:29, akalin wrote:
> 
> I think I want to unblock Hasan and being able to run a SPDY/4 client against
a
> SPDY/4 server -- such testing will probably shake out bugs quicker than
forking
> / unforking in the short-term.

*nod*  Geting the client-server testing up and running is a very good thing.

> It's also worth noting that the Chrome will only ever speak one alpha version
of
> Chrome, as will the servers.

Ah, I see.

> So my preference would be to start the discussion around how best to get tests
> for SPDY/4 separately and not block this CL on that. (I'd prefer to unfork the
> tests, myself.) WDYT?

Couple of thoughts:
* I'm *very* uncomfortable running SPDY code with test coverage, particularly
given the recent SPDY "fun" :>
* You should probably chat with ttuttle since he was doing a bit of work last
week to un fork the tests.  Y'all should make sure you're on the same page.
* I think it's probably OK to land this as is, but I think we need a concrete
plan for when we'll get test coverage.  I don't think we should roll to 4a2
without tests.

So how 'bout you add a simple test that if we see the NPN string spdy/4a1 that
the spdy session actually creates a spdy framer with version 4?  Not an
end-to-end test at all, but at least it will give us good confidence?  Is that
pretty straightforward to do?

[akalin, 2013-04-11 19:33:43]

Added test, PTAL. (Although it's admittedly kind of hackish.)

[Ryan Hamilton, 2013-04-11 23:57:34]

lgtm

[akalin, 2013-04-12 02:42:37]

Committed patchset #4 manually as r193832 (presubmit successful).