HttpTransaction::Start() interface should be clearer w.r.t HttpRequestInfo lifetime |
||
Issue descriptionCurrently the interface states: // The consumer should ensure that request_info points to a valid value till // final response headers are received; after that point, the HttpTransaction // will not access |*request_info| and it may be deleted. It is clear for both consumer and producer for most derived classes of HttpTransaction like HttpNetworkTransaction. The one case where it isn't too clear is HttpCache::Transaction since for a request which is served via multiple range requests, final response headers from the consumer's perspective happens after the first time headers are received, but the HC::T state machine itself can go to headers phase again for the next range and will need request_info to be present at that time. If we change the interface to something like this: // The consumer should ensure that request_info points to a valid value while // the consumer is alive; after that point, the HttpTransaction will not // access |*request_info|. it works for HC::T as well since HC::T does not outlive its consumer and HttpNetworkTransaction uses headers phase ending to null its pointer so that it can outlive its consumer. But these seem implementation specifics and the interface itself is not clear for the producer and consumer. rdsmith@ also suggested using a scoped_refptr for passing request info between multiple layers.
,
May 18 2017
That's right and that's the reason we would like to change it to something that's clear to both the HttpTransaction and its consumer class.
,
Feb 16 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by mmenke@chromium.org
, May 17 2017