Support asynchronous continuation of custom scheme handler read requests

[GoogleCodeExporter]

A custom scheme handler may use a separate thread to read data and then return 
that data via ReadResponse(). It's possible that reading data will be slow, so 
ReadResponse() might be called when no data is available. Currently, it is not 
possible to indicate that no data is available without canceling the request.

Chromium uses asynchronous callbacks for this purpose. The net/ convention is 
to return net::ERR_IO_PENDING. For example, see 
URLRequestHttpJob::ReadRawData() in net/url_request/url_request_http_job.cc.
This works as follows:

1. When no data is available ReadRawData() sets the status to IO_PENDING.
2. When more data becomes available a callback is executed to reset the status.
3. ReadRawData() will now be called again. 

To support this capability in CEF we'll add a new Continue() method to 
CefSchemeHandler and change the ReadResponse() return value to an enumeration 
of: READ_SUCCESS, READ_CANCEL, READ_PENDING. If READ_PENDING is returned the 
client must execute the Continue() method when more data is available for 
reading.

Original issue reported on code.google.com by magreenb...@gmail.com on 16 Jun 2011 at 4:39

[GoogleCodeExporter]

Original comment by magreenb...@gmail.com on 8 Aug 2011 at 5:36

• Added labels: SPI

[GoogleCodeExporter]

A quick comment about the proposed solution:

While I think that it will solve some of our problems, I think it doesn't 
address all of our (long-term) concerns. The introduction of ::Continue() still 
requires the CefSchemeHandler::ProcessRequest() to execute synchronously. 
ProcessRequest() (if I understand correctly) is the only place where we can 
return headers and metadata about the request, because we basically want to 
bridge the SchemeHandler to our own HTTP-like protocol I we actually need the 
ProcessRequest() to be async as well.

From a quick glance at the chromium code I saw the function NotifyHeadersDone() 
as well as some other NotifyXXX() functions, I wonder if those (or a Cef 
version thereof) can be exposed in the CEF-Api as well?

Original comment by Mikael.O...@gmail.com on 8 Aug 2011 at 9:09

[GoogleCodeExporter]

I have added a thread handler to resolve this on my end. It's not a pretty fix, 
but thus far I haven't run in to any issues.

in CefUrlRequestJob::Start, instead of posting the work to CefThread::IO, I 
post it to CefThread::REQUEST_XX which can do the processing/fetching.

Original comment by crazy.fu...@gmail.com on 9 Aug 2011 at 3:54

[GoogleCodeExporter]

Revision 278 implements asynchronous continuation of requests via a new 
CefSchemeHandlerCallback class. This supports delayed retrieval of header 
information and response data.

Original comment by magreenb...@gmail.com on 17 Aug 2011 at 1:59

• Changed state: Fixed