My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 534: Problem with CefSchemeHandlerCallback at end of stream
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  May 2012

Sign in to add a comment
Reported by, Feb 24, 2012
What steps will reproduce the problem?
The following call sequence locks things up:
CefSchemeHandler::ReadResponse() returning true bytes_read=0
CefSchemeHandler::ReadResponse() returning true bytes_read=423
CefSchemeHandler::ReadResponse() returning true bytes_read=0
CefSchemeHandler::ReadResponse() returning false

What is the expected output? What do you see instead?
Expect the 423 bytes to be successfully passed to the browser.  Browser becomes unresponsive and does not issue further requests.

What version of the product are you using? On what operating system?
Windows 7

Please provide any additional information below.

Please see for more information.

Feb 24, 2012
When 423 bytes are first available, we announce them but don't know it's the end of stream. ReadResponse delivers those 423 bytes fine. Later our thread discovers there is no more data so calls BytesAvailable to prompt a call to ReadResponse. Subsequently returning false from ReadResponse seems to lock things up.
Mar 2, 2012
I found another case that is easier to replicate. It may be a different issue entirely.  

See here:

In this case, Cancel() _is_ called at the end but browser does not render or make further requests.

Mar 19, 2012
Attached is a modified cefclient source file that will allow this defect to be replicated and perhaps help test scheme handlers more thoroughly.

This file allows the client:// scheme to work just like http:// - the HTTP is directed via the stream handler to WinHttp API.  So you can go to client:// and it's like you were using http.  Windows only, sadly.  Implementation is partial, HTTP POST not tested.  Also any http links in docs served via client:// will revert to HTTP - I tried to prevent this without success.

Nevertheless if you remove the small hack that postpones delivery of the last byte of each "packet", CEF hangs.  Here is that code...

			if (bytes_read > 1)
				// workaround for CEF problem at end of stream
				this->data[0] = this->data.back();
				this->bytes = 1;

Feel free to take use, modify...
8.1 KB   View   Download
Apr 16, 2012
Project Member #5
It appears that you are re-using the callback passed to ProcessRequest() instead of using the callback passed to ReadResponse(). This is incorrect usage.
Status: WontFix
Labels: -Type-Defect Type-Other
Apr 17, 2012
I had been aware that there was it might be possible to mix up callbacks.  I will double check and see if this is responsible for my various scheme handler issue.  Many thanks.
May 4, 2012
I found this bug in function BytesAvailable. The else branch for done notification is misplaced.


May 4, 2012
Project Member #8
@comment#7: I agree that there appears to be a bug in BytesAvailable() but I don't think your proposed solution is completely correct. From the comments on ReadRawData() in net/url_request/url_request_job.h:

  // Called to read raw (pre-filtered) data from this Job.
  // If returning true, data was read from the job.  buf will contain
  // the data, and bytes_read will receive the number of bytes read.
  // If returning true, and bytes_read is returned as 0, there is no
  // additional data to be read.
  // If returning false, an error occurred or an async IO is now pending.
  // If async IO is pending, the status of the request will be
  // URLRequestStatus::IO_PENDING, and buf must remain available until the
  // operation is completed.  See comments on URLRequest::Read for more
  // info.

The proposed solution is attached (patch against 963 branch), please try it and let me know if it works for you.
585 bytes   View   Download
Status: Accepted
Labels: -Type-Other Type-Defect
May 4, 2012
Project Member #9
Fixed in revision 617, revision 618 and revision 619.
May 4, 2012
Project Member #10
(No comment was entered for this change.)
Status: Fixed
Sign in to add a comment

Powered by Google Project Hosting