[webkit-help] Download manager using IWebDownloadDelegate (cairo port)

[Chris Hatko]

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
<alexander.shulgin at yessoftware.com> 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.
>