QUIC - chromium server push support.

QUIC - chromium server push support.

chromium specific parts of push promise rendezvous.

BUG=

Committed: https://crrev.com/3865ee0f51a7531cc3d489810299d3b59611329b
Cr-Commit-Position: refs/heads/master@{#378284}

[Buck, 2016-02-23 18:18:06]

ckrasic@chromium.org changed reviewers:
+ rch@chromium.org

[Buck, 2016-02-23 18:18:06]

The core functionality changes are in quic_http_stream.cc and
quic_stream_factory.cc.   quic_chromium_client_stream.cc also has moderate
changes to deal with the push-specific case of notifications happening before
the receiving delegate has been attached, due to the push promised stream
arriving before the rendezvous with matching browser request.

[Ryan Hamilton, 2016-02-24 00:34:00]

Wow, there's a lot of work here!

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
File net/quic/quic_chromium_client_session.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
net/quic/quic_chromium_client_session.cc:593:
RecordUnexpectedOpenStreams(CREATE_INCOMING_RELIABLE_STREAM);
I'm not sure this is unexpected in the sense that this histogram is looking for
programming errors in chrome. If the server sends a push after sending (or
receiving) a goaway, that's not a chrome bug. So I think you can ignore this.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
File net/quic/quic_chromium_client_stream.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
net/quic/quic_chromium_client_stream.h:103: size_t frame_len);
I wonder if this can be done in a stand-alone CL.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
File net/quic/quic_http_stream.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:103: return true;
nit: early return

if (!vary_data.Init(...)) {
  // Promise didn't contain valid vary info, so URL match was sufficient.
  return true;
}

// Now compare the client request for matching.
return vary_data.MatchesRequest

Or you could be really clever and do:
  return !var_data.Init() || vary_data.Match()
but I suspect that won't be terribly readable

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:113: if (!callback_.is_null()) {
Can you comment about under what circumstances will the callback be non-null?

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:117: DoCallback(OK);
Instead of DoCallback, can you simply do OnIOComplete(OK)? Does that work? The
asymetry between these two paths feel tingly but it might be totally fine.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:150: return OK;
Can you add a comment here which explains that the push will be coming later (or
some such)

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:168: EnterStateSendHeaders();
I think it would be more common to rename EnterStateSendHeaders to
 DoStreamRequestComplete
and make it an explicit state.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:179: // non-null value, so priority_ etc. are also
set).
This comment implies some conditional logic which I don't seem to see. Does that
logic live elsewhere?

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:194: }
My brain is working slowly. What circumstances lead to this new path?

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:206: if (push_status == QUIC_FAILURE) {
nit: consider a switch statement here.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:223: if (next_state_ != STATE_OPEN) {
How 'bout avoiding this conditional by doing a return; in the QUIC_SUCCESS case?
(And add a comment to explain why)

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:247: return ERR_CONNECTION_CLOSED;
I wonder if this should have the same logic as below?

if (!session_ || (!found_promise! && !stream_)) {
  return was_handshake_confirmed_ ? ERR_CONNECTION_CLOSED
                                                             :
ERR_QUIC_HANDSHAKE_FAILED;

but I'm not sure.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
File net/quic/quic_http_stream.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.h:95: STATE_STREAM_REQUEST,
Perhaps this should be STATE_REQUEST_STREAM to be of the form
STATE_<verb>_<noun>

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.h:130: HttpRequestHeaders* http_headers);
Consider adding this method to:

net/spdy/spdy_http_utils.h

It looks like the other 3 methods already exist :>

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.h:201: QuicClientPushPromiseIndex::TryHandle*
push_handle_;
Can you comment on ownership of this object, and under what circumstances it
will be set.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_protocol.h
File net/quic/quic_protocol.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_protocol...
net/quic/quic_protocol.h:487: QUIC_INVALID_PROMISE_METHOD,
This can probably go in a stand alone CL (perhaps landing internally first)

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.cc:785: promised->Cancel();
This suggests that privacy_mode should be part of the key in the push promise
index.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.h:79: base::StringPiece origin_host,
I suspect we don't need origin host if we're now passing in the URL. (Should the
URL be a GURL?

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.h:533: int num_push_streams_created_;
What is this variable used for?

[Buck, 2016-02-26 23:54:17]

PTAL.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
File net/quic/quic_chromium_client_session.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
net/quic/quic_chromium_client_session.cc:593:
RecordUnexpectedOpenStreams(CREATE_INCOMING_RELIABLE_STREAM);
On 2016/02/24 00:33:59, Ryan Hamilton wrote:
> I'm not sure this is unexpected in the sense that this histogram is looking
for
> programming errors in chrome. If the server sends a push after sending (or
> receiving) a goaway, that's not a chrome bug. So I think you can ignore this.

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
File net/quic/quic_chromium_client_stream.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_chromium...
net/quic/quic_chromium_client_stream.h:103: size_t frame_len);
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> I wonder if this can be done in a stand-alone CL.

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
File net/quic/quic_http_stream.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:103: return true;
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> nit: early return
> 
> if (!vary_data.Init(...)) {
>   // Promise didn't contain valid vary info, so URL match was sufficient.
>   return true;
> }
> 
> // Now compare the client request for matching.
> return vary_data.MatchesRequest
> 
> Or you could be really clever and do:
>   return !var_data.Init() || vary_data.Match()
> but I suspect that won't be terribly readable

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:113: if (!callback_.is_null()) {
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> Can you comment about under what circumstances will the callback be non-null?

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:117: DoCallback(OK);
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> Instead of DoCallback, can you simply do OnIOComplete(OK)? Does that work? The
> asymetry between these two paths feel tingly but it might be totally fine.

No, because OnIoComplete() calls DoLoop() which toggles next_state_ back from
STATE_OPEN to STATE_NONE, and later code, namely IsResponseComplete(), wants to
see STATE_OPEN.

Unless maybe... change DoLoop to be a no-op on next_state_ == STATE_OPEN?

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:150: return OK;
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> Can you add a comment here which explains that the push will be coming later
(or
> some such)

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:179: // non-null value, so priority_ etc. are also
set).
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> This comment implies some conditional logic which I don't seem to see. Does
that
> logic live elsewhere?

I updated the comment.   [ The conditional logic *was* here in a pre-review
version, but I later lifted it out to the callsites.  ]

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:194: }
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> My brain is working slowly. What circumstances lead to this new path?

Added a comment to explain.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:206: if (push_status == QUIC_FAILURE) {
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> nit: consider a switch statement here.

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:223: if (next_state_ != STATE_OPEN) {
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> How 'bout avoiding this conditional by doing a return; in the QUIC_SUCCESS
case?
> (And add a comment to explain why)

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.cc:247: return ERR_CONNECTION_CLOSED;
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> I wonder if this should have the same logic as below?
> 
> if (!session_ || (!found_promise! && !stream_)) {
>   return was_handshake_confirmed_ ? ERR_CONNECTION_CLOSED
>                                                              :
> ERR_QUIC_HANDSHAKE_FAILED;
> 
> but I'm not sure.

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
File net/quic/quic_http_stream.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.h:95: STATE_STREAM_REQUEST,
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> Perhaps this should be STATE_REQUEST_STREAM to be of the form
> STATE_<verb>_<noun>

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.h:130: HttpRequestHeaders* http_headers);
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> Consider adding this method to:
> 
> net/spdy/spdy_http_utils.h
> 
> It looks like the other 3 methods already exist :>

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_http_str...
net/quic/quic_http_stream.h:201: QuicClientPushPromiseIndex::TryHandle*
push_handle_;
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> Can you comment on ownership of this object, and under what circumstances it
> will be set.

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_protocol.h
File net/quic/quic_protocol.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_protocol...
net/quic/quic_protocol.h:487: QUIC_INVALID_PROMISE_METHOD,
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> This can probably go in a stand alone CL (perhaps landing internally first)

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.cc:785: promised->Cancel();
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> This suggests that privacy_mode should be part of the key in the push promise
> index.

It could but I think it would lead to some extra messiness, for instance, the
privacy mode isn't handy when a lookup is done in QuicHttpStream::Initialize(),
since the state machine hasn't put the request together yet.   This was the same
reason I had to add QuicClientPushPromiseIndex::GetPromised() in this cl.

I think a very similar issue of how to index applies to the way vary is handled
in chromium http cache layer, that cache is keyed strictly by url, so it may
thrash if a multiple requests for the same url fail vary checks due to
particular content negotiation scenarios.   One could imagine a cache that is
indexed by url + the vary specified header values to eliminate the potential for
such thrashing, but I *think* the consensus is that the extra complexity isn't
worth it. [ I had asked cbentzel@ about it ].

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.h:79: base::StringPiece origin_host,
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> I suspect we don't need origin host if we're now passing in the URL. (Should
the
> URL be a GURL?

Done.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.h:533: int num_push_streams_created_;
On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> What is this variable used for?

Used in quic_http_stream_test.cc via
QuicStreamFactoryPeer::GetNumPushStreamsCreated().

[Ryan Hamilton, 2016-02-29 17:49:40]

Just a few minor comments!

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.cc:785: promised->Cancel();
On 2016/02/26 23:54:17, Buck wrote:
> On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> > This suggests that privacy_mode should be part of the key in the push
promise
> > index.
> 
> It could but I think it would lead to some extra messiness, for instance, the
> privacy mode isn't handy when a lookup is done in
QuicHttpStream::Initialize(),
> since the state machine hasn't put the request together yet.  

I thought that privacy_mode was a field of HttpRequestInfo, which is passed in
to InitializeStream?

> This was the same
> reason I had to add QuicClientPushPromiseIndex::GetPromised() in this cl.
> 
> I think a very similar issue of how to index applies to the way vary is
handled
> in chromium http cache layer, that cache is keyed strictly by url, so it may
> thrash if a multiple requests for the same url fail vary checks due to
> particular content negotiation scenarios.   One could imagine a cache that is
> indexed by url + the vary specified header values to eliminate the potential
for
> such thrashing, but I *think* the consensus is that the extra complexity isn't
> worth it. [ I had asked cbentzel@ about it ].

Fair enough.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.h:533: int num_push_streams_created_;
On 2016/02/26 23:54:17, Buck wrote:
> On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> > What is this variable used for?
> 
> Used in quic_http_stream_test.cc via
> QuicStreamFactoryPeer::GetNumPushStreamsCreated().

This is totally a minor point, but I don't usually love test-only code in
non-test classes. How hard would it be to make the test work w/o this? Maybe not
worth it?

https://codereview.chromium.org/1692253004/diff/180001/net/http/http_stream_f...
File net/http/http_stream_factory_impl_job.cc (right):

https://codereview.chromium.org/1692253004/diff/180001/net/http/http_stream_f...
net/http/http_stream_factory_impl_job.cc:998: url =
url.ReplaceComponents(replacements);
I would have thought you could just set this to https:// + destination, since
that's the pseudo-URL we're connecting to. Do you need to preserve the other
components of the URL?

https://codereview.chromium.org/1692253004/diff/180001/net/quic/quic_chromium...
File net/quic/quic_chromium_client_session.cc (right):

https://codereview.chromium.org/1692253004/diff/180001/net/quic/quic_chromium...
net/quic/quic_chromium_client_session.cc:61: CREATE_INCOMING_RELIABLE_STREAM =
6,
I think you can get rid of this change now?

https://codereview.chromium.org/1692253004/diff/180001/net/spdy/spdy_http_uti...
File net/spdy/spdy_http_utils.cc (right):

https://codereview.chromium.org/1692253004/diff/180001/net/spdy/spdy_http_uti...
net/spdy/spdy_http_utils.cc:199: for (auto it : spdy_headers) {
const auto& ?

https://codereview.chromium.org/1692253004/diff/180001/net/spdy/spdy_http_uti...
net/spdy/spdy_http_utils.cc:206: for (auto value : values) {
const auto& ?

[Buck, 2016-02-29 19:03:02]

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.cc (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.cc:785: promised->Cancel();
On 2016/02/29 17:49:40, Ryan Hamilton wrote:
> On 2016/02/26 23:54:17, Buck wrote:
> > On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> > > This suggests that privacy_mode should be part of the key in the push
> promise
> > > index.
> > 
> > It could but I think it would lead to some extra messiness, for instance,
the
> > privacy mode isn't handy when a lookup is done in
> QuicHttpStream::Initialize(),
> > since the state machine hasn't put the request together yet.  
> 
> I thought that privacy_mode was a field of HttpRequestInfo, which is passed in
> to InitializeStream?
> 
> > This was the same
> > reason I had to add QuicClientPushPromiseIndex::GetPromised() in this cl.
> > 
> > I think a very similar issue of how to index applies to the way vary is
> handled
> > in chromium http cache layer, that cache is keyed strictly by url, so it may
> > thrash if a multiple requests for the same url fail vary checks due to
> > particular content negotiation scenarios.   One could imagine a cache that
is
> > indexed by url + the vary specified header values to eliminate the potential
> for
> > such thrashing, but I *think* the consensus is that the extra complexity
isn't
> > worth it. [ I had asked cbentzel@ about it ].
> 
> Fair enough.

Yep, I was mistaken about privacy_mode availabilty.

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
File net/quic/quic_stream_factory.h (right):

https://codereview.chromium.org/1692253004/diff/160001/net/quic/quic_stream_f...
net/quic/quic_stream_factory.h:533: int num_push_streams_created_;
On 2016/02/29 17:49:40, Ryan Hamilton wrote:
> On 2016/02/26 23:54:17, Buck wrote:
> > On 2016/02/24 00:34:00, Ryan Hamilton wrote:
> > > What is this variable used for?
> > 
> > Used in quic_http_stream_test.cc via
> > QuicStreamFactoryPeer::GetNumPushStreamsCreated().
> 
> This is totally a minor point, but I don't usually love test-only code in
> non-test classes. How hard would it be to make the test work w/o this? Maybe
not
> worth it?

I took another look, and I don't see an easy way to make the test work
otherwise.   It *might* have non-debug value when I add UMA instrumentation...

https://codereview.chromium.org/1692253004/diff/180001/net/http/http_stream_f...
File net/http/http_stream_factory_impl_job.cc (right):

https://codereview.chromium.org/1692253004/diff/180001/net/http/http_stream_f...
net/http/http_stream_factory_impl_job.cc:998: url =
url.ReplaceComponents(replacements);
On 2016/02/29 17:49:40, Ryan Hamilton wrote:
> I would have thought you could just set this to https:// + destination, since
> that's the pseudo-URL we're connecting to. Do you need to preserve the other
> components of the URL?

Done.

https://codereview.chromium.org/1692253004/diff/180001/net/quic/quic_chromium...
File net/quic/quic_chromium_client_session.cc (right):

https://codereview.chromium.org/1692253004/diff/180001/net/quic/quic_chromium...
net/quic/quic_chromium_client_session.cc:61: CREATE_INCOMING_RELIABLE_STREAM =
6,
On 2016/02/29 17:49:40, Ryan Hamilton wrote:
> I think you can get rid of this change now?

Done.

https://codereview.chromium.org/1692253004/diff/180001/net/spdy/spdy_http_uti...
File net/spdy/spdy_http_utils.cc (right):

https://codereview.chromium.org/1692253004/diff/180001/net/spdy/spdy_http_uti...
net/spdy/spdy_http_utils.cc:199: for (auto it : spdy_headers) {
On 2016/02/29 17:49:40, Ryan Hamilton wrote:
> const auto& ?

Done.

https://codereview.chromium.org/1692253004/diff/180001/net/spdy/spdy_http_uti...
net/spdy/spdy_http_utils.cc:206: for (auto value : values) {
On 2016/02/29 17:49:40, Ryan Hamilton wrote:
> const auto& ?

Done.

[Ryan Hamilton, 2016-02-29 19:39:44]

lgtm

Woo hoo!

[Buck, 2016-02-29 20:18:00]

The CQ bit was checked by ckrasic@chromium.org

[commit-bot: I haz the power, 2016-02-29 20:18:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1692253004/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1692253004/200001

[commit-bot: I haz the power, 2016-02-29 20:32:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-29 20:32:44]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Buck, 2016-02-29 20:35:31]

The CQ bit was checked by ckrasic@chromium.org

[commit-bot: I haz the power, 2016-02-29 20:35:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1692253004/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1692253004/200001

[commit-bot: I haz the power, 2016-02-29 22:05:04]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2016-02-29 22:06:09]

Description was changed from

==========
QUIC - chromium server push support.

chromium specific parts of push promise rendezvous.

BUG=
==========

to

==========
QUIC - chromium server push support.

chromium specific parts of push promise rendezvous.

BUG=

Committed: https://crrev.com/3865ee0f51a7531cc3d489810299d3b59611329b
Cr-Commit-Position: refs/heads/master@{#378284}
==========

[commit-bot: I haz the power, 2016-02-29 22:06:10]

Patchset 11 (id:??) landed as
https://crrev.com/3865ee0f51a7531cc3d489810299d3b59611329b
Cr-Commit-Position: refs/heads/master@{#378284}

[Ryan Hamilton, 2016-12-23 01:32:46]

On 2016/02/29 22:06:10, commit-bot: I haz the power wrote:
> Patchset 11 (id:??) landed as
> https://crrev.com/3865ee0f51a7531cc3d489810299d3b59611329b
> Cr-Commit-Position: refs/heads/master@{#378284}

I noticed that the shared parts of this CL were not merged back to the internal
repository. I'll do this now, but please be mindful of back-merges.