[Webkit-unassigned] [Bug 126006] [SOUP] ResourceHandleSoup should use async client callbacks when client uses async callbacks

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=126006





--- Comment #8 from Carlos Garcia Campos <cgarcia at igalia.com>  2013-12-20 08:31:09 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> 
> > This is because in the network process, the ResourceHandleClient (implemented by NetworkResourceLoader) only uses the async versions of the callbacks (usesAsyncCallbacks returns true). So, if the client uses async callbacks, calling, for example, didReceiveResponse has no effect, because it's not handled, the version didReceiveResponseAsync is the one implemented in NetworkResourceLoader. I think mac uses a different thread to implement the network callback asynchronously, but our implementation has always been async using the main loop instead. I think the only continueFoo that we need to implement is continueWillSendRequest, because the request might have changed (note that willSendRequest, the one that allows the user to change the request happens in the web process so it still works), in the other cases we don't need them. Note that loader client pass now, and also most of the resource load client test as well.
> 
> What sort of thing would happen in continueWillSendRequest?

We would not call sendPendingRequest() in doRedirect and in continueWillSendRequest we would replace the current request by the passed in one, then we would call sendPendingRequest() to actually send the request. I left that part for a following up patch, because I haven't been able to find a test case that calls this willSendRequest in a redirect. This patch fixes a lot of problems we currently have, basically everything that depends on having a response in the UI process.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.