New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 704649 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 704949
Owner: ----
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

QuicCryptoClientStream::CryptoConnect() API signature doesn't imply synchronous error

Project Member Reported by zhongyi@chromium.org, Mar 23 2017

Issue description

Branched disucssion from https://codereview.chromium.org/2766603004. 

xunjieli@ suggests a change QuicCryptoClientStream::CryptoConnect API to make the API contract clearer as the current signature doesn't indicate that it can return error synchronously.  crbug.com/700617  is caused by failing to handle the sync error in this code.

int QuicChromiumClientSession::CryptoConnect(
    const CompletionCallback& callback) {
  connect_timing_.connect_start = base::TimeTicks::Now();
  RecordHandshakeState(STATE_STARTED);
  DCHECK(flow_controller());
  crypto_stream_->CryptoConnect();   <------- doesn't indicate could fail synchronously.

  if (IsCryptoHandshakeConfirmed()) {
    connect_timing_.connect_end = base::TimeTicks::Now();
    return OK;
  }

  // Unless we require handshake confirmation, activate the session if
  // we have established initial encryption.
  if (!require_confirmation_ && IsEncryptionEstablished())
    return OK;

  callback_ = callback;
  return ERR_IO_PENDING;
}

 

Comment 1 by rch@chromium.org, Mar 23 2017

(This would need to happen in shared code, of course.)

It should be pretty easy to make that method return true if the connection is still connected, and false otherwise. Is that what you're thinking?

Mergedinto: 704949
Status: Duplicate (was: Untriaged)
Yup. That's what I was thinking, mark this issue as duplicate as 704949. 

Sign in to add a comment