This may be related to  issue 779919  (Dev does have the fix for that issue).

This looks very similar to 779919, except the fix there fixes it for HttpNetworkTransaction and not for the streams.

The issue is that  request_info_ which is owned by the URLRequestHttpJob may have been already destroyed. The  request_info_ is set to null currently in ReadResponseBody but actually should be set to null at the end of the headers because its possible that Read never gets called.

bnc@, mmenke@: Is OnHeadersReceived() a good point to unconditionally assume that headers phase is complete or is there any case (like auth etc. ) where the headers phase can be entered again?

It looks to me like response_info_ is not modified after OnHeadersReceived, and OnHeadersReceived is called only once, though I defer to bnc.

Tried the change and one of the existing tests is failing: SpdyNetworkTransactionTest.ResponseBeforePostCompletes
because the following line 
https://cs.chromium.org/chromium/src/net/spdy/chromium/spdy_network_transaction_unittest.cc?sq=package:chromium&q=ResponseBeforePostCompletes&l=1682

works on the upload data stream after the response headers are complete. It seems this is a valid scenario but wanted to confirm.

Matt, Bence, any thoughts?

Yes, it's valid.  For HTTP, it's legal, we just don't start reading the response until we've finished uploading the body.  For H2 and QUIC we can't really do that, since the stream is shared.

Sorry, I am not sure what part of the code I am supposed to be looking at.  |request_info_| is a member of URLRequestHttpJob, I see that.  But which class has the OnHeadersReceived and ReadResponseBody methods?  I did not find it either in HttpNetworkTransaction or UrlRequestHttpJob.

Its spdy_http_stream.cc

Here is a WIP CL that seems to be working:
https://chromium-review.googlesource.com/c/chromium/src/+/764652

2 CLs uploaded for review:
Spdy stream: Move request info resetting to null at the end of headers phase. (https://chromium-review.googlesource.com/c/chromium/src/+/769492/)

Parallel writing should only be allowed for GET requests.
(https://chromium-review.googlesource.com/c/chromium/src/+/769492/)

Re comment #3:  I agree that response_info_ is not modified after OnHeadersReceived, and that OnHeadersReceived is meant to be called only once.

However, SpdyStream::SetDelegate() posttasks SpdyStream::PushedStreamReplay(), so in theory it is possible that SpdyStream::SaveResponseHeaders() is called after |delegate_| is set by SetDelegate but before PushedStreamReplay() is called.  In this unfortunate case, SpdyHttpStream::OnHeadersReceived() could be called twice.  I don't think it could happen, because SetDelegate() is called by SpdyHttpStream upon initialization, and SaveResponseHeaders::SaveResponseHeaders() is called by SpdyStream::OnHeadersReceived(), which must happen later, but it's not immediately obvious.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7dbf0b9563d08c4a5cdbb4beeb80a83a547026ab

commit 7dbf0b9563d08c4a5cdbb4beeb80a83a547026ab
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Wed Nov 15 21:02:11 2017

Parallel writing should only be allowed for GET requests.

Requests other than GET like POST/PUT/DELETE do not need the parallel writing functionality.
Allowing 2 POSTs to do parallel writing would have also led to a race in the Spdy stream
(See https://chromium-review.googlesource.com/c/chromium/src/+/764652)

Bug:  783859 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Ia1422fc4ce767affc28fd1121209c7394cca00da
Reviewed-on: https://chromium-review.googlesource.com/769492
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516821}
[modify] https://crrev.com/7dbf0b9563d08c4a5cdbb4beeb80a83a547026ab/net/http/http_cache.cc
[modify] https://crrev.com/7dbf0b9563d08c4a5cdbb4beeb80a83a547026ab/net/http/http_cache.h
[modify] https://crrev.com/7dbf0b9563d08c4a5cdbb4beeb80a83a547026ab/net/http/http_cache_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/32ade74db781e7ff890d9424300398c1300c90a1

commit 32ade74db781e7ff890d9424300398c1300c90a1
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Wed Nov 15 21:47:04 2017

Spdy stream: Move request info resetting to null at the end of headers phase.

There was a gap existing where request_info_ may have been destroyed because the consumer died
and it was still non-null since Read was not yet called. This CL moves the resetting of
request_info_ to either the end of headers phase or the end of upload data stream whichever is
later.

Note that if the request_info_ is destroyed after the headers completion and before upload
data stream's completion then its not an issue because the cache transaction layer will not allow
parallel writing of two POST requests with the same upload id. That change is landing via
https://chromium-review.googlesource.com/#/c/chromium/src/+/769492


Bug:  783859 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I0b78a55f197eef35144047b0f3c594d106cec98e
Reviewed-on: https://chromium-review.googlesource.com/764652
Reviewed-by: Bence Béky <bnc@chromium.org>
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516839}
[modify] https://crrev.com/32ade74db781e7ff890d9424300398c1300c90a1/net/spdy/chromium/spdy_http_stream.cc
[modify] https://crrev.com/32ade74db781e7ff890d9424300398c1300c90a1/net/spdy/chromium/spdy_http_stream.h
[modify] https://crrev.com/32ade74db781e7ff890d9424300398c1300c90a1/net/spdy/chromium/spdy_http_stream_unittest.cc