[webkit-qt] Handling downloads with QtWebKit
Florian Bruhin
me at the-compiler.org
Mon Nov 17 23:09:19 PST 2014
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>
More information about the webkit-qt
mailing list