[webkit-qt] Handling downloads with QtWebKit

[Florian Bruhin]

Hi Allan,

* Allan Sandfeld Jensen <kde at carewolf.com> [2014-11-17 09:53:23 +0100]:
> On Sunday 16 November 2014, Florian Bruhin wrote:
> > Hi,
> > 
> > I'm searching for some howto or example on how to handle downloads
> > with QtWebkit correctly, especially the unsupportedContent signal.
> > 
> > My main problem is what to do with the open QNetworkReply while asking
> > the user for a filename to save the file to. I've looked into some
> > existing projects using QtWebKit and I've seen these approaches so
> > far:
> > 
> > - Just downloading to RAM (i.e. the default Qt behaviour, ignoring
> >   readRead with no buffer size set) -> RAM could fill up rather fast.
> >   I have a 250 MBit connection here, so potentially a gigabyte of RAM
> >   is filled if I take 30 seconds to enter a filename.
> > 
> > - Not downloading anything until the filename is entered -> server
> >   will probably close the connection after some seconds.
> > 
> > - Just re-doing the request using the URL from the reply -> Could lead
> >   to a lot of problems, e.g. with DRM-like "you may download this file
> >   N times" sites.
> > 
> > - Downloading to a temporary file until the user has entered the
> >   filename, then copying it over and deleting the temporary file.
> > 
> > The last approach seems to be the cleanest to me, and this seems to be
> > what Firefox/Chrome do as well. I've seen the Otter browser[1] doing
> > this, but not anything else yet.
> > 
> > Am I on the right track? Is there some documentation about how to do
> > this the right way anywhere?
> > 
> The correct way is to suspend the TCP connection until you know where to save. 

Is there some special method to suspend the connection I missed? Or do
you just mean I should call setReadBufferSize with a reasonable size
and then not read anything?

> If the server closes the connection it is doing it wrong, and what we are 
> talking about is a wor- around

Unfortunately that seems to happen in the wild more often than I'd
like...

> but if it does close, you can usually just rerequest, can't you?

That sounds reasonable... Though I guess there must be some reason the
big browsers seem to write to a temp-file immediately? Unless I
misinterpreted what I saw via strace.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.webkit.org/pipermail/webkit-qt/attachments/20141118/335f49a8/attachment.sig>