[Webkit-unassigned] [Bug 49018] [GTK] response.isNull() assert when using directory file URI

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk>  2010-11-09 05:32:00 PST ---
(In reply to comment #12)
> > That would mean calling didReceiveResponse multiple time in the case of HTTP. Also there was discussion about Soup future where FTP would fire callbacks that triggers didReceiveResponse too, and potentially other protocols. Checking if a response was send right before passing the first buffer seems to be the most generic solution at the moment.
> 
> Maybe I'm missing something but that did receive response is only called for "file:" URIs. HTTP requests don't match that condition.

client->didReceiveResponse() is called in signals fired between the notification for the request being sent and the first data buffer (see gotHeadersCallback(), contentSniffedCallback()). client->didReceiveResponse() is also the only way to set a response and MUST be called before didReceiveData(). I'm trying to guaranty that this will always happen and will not happend twice. This way, if someone add support for protocols with proper response (ftp, gopher, etc.) we can just concentrate on the soup backend and know that the binding is ready for it (aside the file/ftp/ftps filter that could be removed when the GIO backend is fixed).

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