Page 2 of 2

Re: CEF Custom Scheme Handler

PostPosted: Thu Aug 20, 2009 7:32 pm
by heshiming
Well I haven't thought about this. But URLRequestJob have these methods put separately.

The thing is that ProcessRequest is currently designed to be a synchronized call. CefUrlRequestJob took care of threading. But it can still be made into an asynchronous call, by putting an extra "IsRequestComplete" method into the interface. And have CefUrlRequestJob::DidResolve or CefUrlRequestJob::ReturnResults check whether the process is complete. ProcessRequest could return immediately, without knowing mimetype or size.

If mimetype and size are moved to ProcessRequest, then it has to be a synchronized call.

Plus, theoretically, the response can also be put into ProcessRequest as a parameter, because the response should become available after ProcessRequest. This way, ReadResponse could be offloaded to CefUrlRequestJob, and the client only have to return a byte sequence. So it could become:
Code: Select all
virtual bool ProcessRequest(CefRefPtr<CefRequest> request, std::wstring& mime_type, vector<unsigned char>& response) = 0;

Is this a good idea? It works but isn't it too limited?

Re: CEF Custom Scheme Handler

PostPosted: Thu Aug 20, 2009 9:28 pm
by magreenblatt
Just the mime type and response length values, not the actual response content :-). The call to ProcessRequest is already happening in, and blocking, the IO (worker) thread. I don't think the GetMimeType and GetResponseLength methods will be called until after DidResolve calls NotifyHeadersComplete, which doesn't take place until the ProcessRequest call returns.

I've combined GetMimeType and GetResponseLength into ProcessRequest and committed as rev 37, along with various style corrections, refactoring and code simplification. There's a test for it on the Tests menu called "Scheme Handler," but please test with your particular usage case and let me know if you run into any problems. I haven't forgotten your XMLHttpRequest question -- I'll try to have a response for you by early next week.

Re: CEF Custom Scheme Handler

PostPosted: Fri Aug 21, 2009 6:36 am
by heshiming
Alrighty, thank you for the work. I'll update to this revision and see if there are any problems.

Re: CEF Custom Scheme Handler

PostPosted: Tue Sep 22, 2009 8:49 am
by magreenblatt
It is discovered that although an XMLHttpRequest may generate a POST request that goes through our custom scheme handler like a form post, the upload data (XML data posted) will be lost. The cause is that WebKit's XMLHttpRequest checks the URL and see if it's HTTP or HTTPS protocol before setting post data. This is done inside XMLHttpRequest::send of third_party/WebKit/WebCore/xml/XMLHttpRequest.cpp. The method calls KURL::protocolInHTTPFamily to determine whether post data should be created for the request.

I'm not really sure where to patch. I picked KURLGooglePrivate::initProtocolInHTTPFamily in third_party/WebKit/WebCore/platform/KURLGoogle.cpp , and changed:

I finally had a chance to look into this issue. You've identified the right culprit, but I don't believe your change to KURLGooglePrivate::initProtocolInHTTPFamily() is valid. KURLGooglePrivate::initProtocolInHTTPFamily() should only return true for HTTP and HTTPS as any other return may break code elsewhere in the system. Your best bet, if you need to use XMLHttpRequest, would be to use the HTTP protocol and generate the response in CefHandler::HandleBeforeResourceLoad().

Re: CEF Custom Scheme Handler

PostPosted: Sun Jul 14, 2013 1:37 pm
by jorgea
Thanks for providing this most useful coding