Actually enable Alternate-Protocol support for QUIC.

Actually enable Alternate-Protocol support for QUIC.

Also, since we expect QUIC for HTTP URLs to run on port 80, changed the tests to use that port.

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

[willchan no longer on Chromium, 2013-06-20 17:48:08]

https://codereview.chromium.org/17410014/diff/5001/net/http/http_stream_facto...
File net/http/http_stream_factory.cc (right):

https://codereview.chromium.org/17410014/diff/5001/net/http/http_stream_facto...
net/http/http_stream_factory.cc:147: next_protos.push_back("quic");
Does order matter? Historically order matters for this vector. But you guys
aren't actually sending this within NPN are you? I'm not understanding how this
is supposed to work.

[Ryan Hamilton, 2013-06-20 17:56:47]

https://codereview.chromium.org/17410014/diff/5001/net/http/http_stream_facto...
File net/http/http_stream_factory.cc (right):

https://codereview.chromium.org/17410014/diff/5001/net/http/http_stream_facto...
net/http/http_stream_factory.cc:147: next_protos.push_back("quic");
On 2013/06/20 17:48:08, willchan wrote:
> Does order matter? Historically order matters for this vector. But you guys
> aren't actually sending this within NPN are you? I'm not understanding how
this
> is supposed to work.

I don't think that order matters.  If you notice, each of these methods calls
SetNextProtos, which simply iterates over the list and sets
enabled_protocols_[foo] = true.  As you say, we're not sending QUIC via NPN, but
rather Alternate-Protocol.  These "EnableFoo" methods which end up setting
enabled_protocols_ configure both of these mechanism.  Since we use
Alternate-Protocol, this works fine.  That being said, I re-ordered this list to
match the others (sorted alphabetically).

[willchan no longer on Chromium, 2013-06-20 18:10:49]

LGTM

OK, thanks for the explanation. I think my knowledge of SetNextProtos() is out
of date :) The naming kinda sucks now. Maybe we should rename to
EnableNewProtocols() or something else, so it doesn't appear NPN specific.

But that shouldn't block this CL. Fine to commit.

[commit-bot: I haz the power, 2013-06-20 18:33:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/17410014/9001

[Ryan Hamilton, 2013-06-20 19:00:07]

On 2013/06/20 18:10:49, willchan wrote:
> LGTM
> 
> OK, thanks for the explanation. I think my knowledge of SetNextProtos() is out
> of date :) The naming kinda sucks now. Maybe we should rename to
> EnableNewProtocols() or something else, so it doesn't appear NPN specific.
> 
> But that shouldn't block this CL. Fine to commit.

Thanks!  Committing.  I totally agree with you, by the way. These static methods
on the factory are *really* hideous warts.  I would simply remove them and
replace them with HttpNetworkSession::Params fields, but there is an extension
API that we exposed which mutates these values at runtime.  Ugh.  Total mess.

[commit-bot: I haz the power, 2013-06-20 19:08:07]

Sorry for I got bad news for ya.
Compile failed with a clobber build on linux_chromeos_clang.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-06-20 19:20:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/17410014/9001

[commit-bot: I haz the power, 2013-06-21 05:45:49]

Change committed as 207722