Problem with CefSchemeHandlerCallback at end of stream

[GoogleCodeExporter]

What steps will reproduce the problem?
The following call sequence locks things up:
CefSchemeHandler::ProcessRequest()
CefSchemeHandler::GetResponseHeaders()
CefSchemeHandler::ReadResponse() returning true bytes_read=0
CefSchemeHandlerCallback::BytesAvailable()
CefSchemeHandler::ReadResponse() returning true bytes_read=423
CefSchemeHandler::ReadResponse() returning true bytes_read=0
CefSchemeHandlerCallback::BytesAvailable()
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?
cef_binary_1.963.439_windows
Windows 7

Please provide any additional information below.

Please see http://magpcss.org/ceforum/viewtopic.php?f=6&t=670 for more 
information.

Original issue reported on code.google.com by j...@mustardtechnology.com on 24 Feb 2012 at 12:56

[GoogleCodeExporter]

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.

Original comment by j...@mustardtechnology.com on 24 Feb 2012 at 12:57

[GoogleCodeExporter]

I found another case that is easier to replicate. It may be a different issue 
entirely.  

See here: http://magpcss.org/ceforum/viewtopic.php?f=6&t=687

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

Original comment by j...@mustardtechnology.com on 2 Mar 2012 at 10:52

[GoogleCodeExporter]

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://google.com 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
                --bytes_read;
                this->data[0] = this->data.back();
                this->bytes = 1;
            }

Feel free to take use, modify...

Original comment by j...@mustardtechnology.com on 19 Mar 2012 at 10:22

Attachments:

• scheme_test.cpp

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It appears that you are re-using the callback passed to ProcessRequest() 
instead of using the callback passed to ReadResponse(). This is incorrect usage.

Original comment by magreenb...@gmail.com on 16 Apr 2012 at 6:37

• Changed state: WontFix
• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

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.

Original comment by j...@mustardtechnology.com on 17 Apr 2012 at 9:14

[GoogleCodeExporter]

I found this bug in scheme_impl.cc function BytesAvailable. The else branch for 
done notification is misplaced.

See http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=670&p=3201#p3201

Original comment by Mirco.Ba...@gmail.com on 4 May 2012 at 5:31

[GoogleCodeExporter]

@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.

Original comment by magreenb...@gmail.com on 4 May 2012 at 6:00

• Changed state: Accepted
• Added labels: Type-Defect
• Removed labels: Type-Other

Attachments:

• scheme_impl_963.patch

[GoogleCodeExporter]

Fixed in revision 617, revision 618 and revision 619.

Original comment by magreenb...@gmail.com on 4 May 2012 at 6:37

[GoogleCodeExporter]

Original comment by magreenb...@gmail.com on 4 May 2012 at 6:37

• Changed state: Fixed