How will the API look? Are we going to buffer all the data in memory as a field in UrlResponse?

I suppose that API could look like 'readToFile(File)' on the 'onResponseStarted' callback.

We wouldn't want to read entire file into memory, but we may not want to write every 'onReadCompleted' into the file either as depending on protocol that could result in many small writes.

It seems if onReadCompleted is called for small pieces of data for a particular protocol, we should really fix Cronet to not call Java onReadCompleted multiple times with small pieces of data. We would continue calling url_request_->Read(read_buffer_.get(), buffer_size, &bytes_read) in cronet_url_request_adapter.cc until the 32kB read buffer is full or the request is completed before surfacing to Java. WDYT?

I talked to Matt briefly and we can't just delay the Read as I previously suggested, since we do not know if there will be more data coming and it might be a hanging GET. 

However, we could try to keep reading and buffering internally in Cronet so we have more data to surface to Java for the next Read. We could expose this option on a per-request basis, so embedder can experiment and see how much a difference this makes.

The received data is getting buffered on the net layer, so there is no need to have additional buffers on Cronet layer.

I think we could add a flag that buffer needs to be filled completely, and don't return it to the app until either it is filled or request is completed (successfully or not). 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this feature still needed?

There was no significant interest for this feature, and it can be easily implemented on top of current UrlRequest API so I'm closing this as Wontfix.