Thanks Alex, This is very helpful while I'm in the process of writing my version. However, I am having one other issue in triggering the download. I find that some sites rely on Content-Disposition being set to "attachment" in the header. For example: http://typewith.me/ (export/import, saving as html or plain text), where download decision can't be made on mime type alone.
I've been trying to do this in the policy delegate , however I only have access to the request not the response that i really need. In other places, such as resource load delegate I have the response however it seems too late to make a use/download decision. Have you encountered this or perhaps have a suggestion? Thanks, Chris On Tue, Sep 21, 2010 at 6:11 AM, Alexander Shulgin <[email protected]> wrote: > On 21.09.2010 5:29, Chris Hatko wrote: >> >> Hi I'm trying to put together a download manager under webkit cairo. >> >> I've implemented a download handler via "IWebDownloadDelegate". I >> register this download delegate by calling " setDownloadDelegate " in >> my webview. When I try to download a file I can see that >> "WebFrame::download(ResourceHandle* handle, const ResourceRequest& >> request, const ResourceRequest&, const ResourceResponse& response) " >> gets called and it seems to correctly find a pointer to my delegate. >> However none of my delegates functions are ever called and hence I >> can't download the file. >> >> Any ideas as to what i'm missing in this procedure? > > I think it's because WebDownloadCurl is not implemented as of current > trunk: > http://trac.webkit.org/browser/trunk/WebKit/win/WebDownloadCurl.cpp#L63 > > Now I have this possibly incomplete patch (attached) to implement that. It > works for me, but I never took the time get it reviewed/accepted, sorry. > > One thing I was forced to do is adding reference counting to > ResourceHandleClient in order to support wasCancelled() callback. This > resulted in rather large amount of small changes to files where the client > is used, so I never really liked this part of the patch. > > Comments are welcome. :) > > -- > Alex > PS: the patch is not against current trunk, but r57813, so it might not > apply cleanly. :-/ You were warned. > _______________________________________________ webkit-help mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
