New kio_http branch ?

Waldo Bastian bastian at kde.org
Tue Apr 22 13:13:55 BST 2003


On Tuesday 22 April 2003 13:27, you wrote:
> We store and then attempt to transmit the buffer to be uploaded in one fell
> swoop. This is becomes a problem when one is uploading say a 100 MB of
> data.

Yes, that should be done in chunks.

> The reason we keep the buffer is to workaround the problem of
> authentication failure. That is if authentication fails the first time due
> to incorrect input for example, we could still re-transmit the data. And we
> need to do this because we cannot re-request the data from
> KIO::TransferJob.

Ugh, that's nasty indeed. Otoh you don't want to send 100Mb only to discover 
that authentication has failed and that you need to send those 100Mb all over 
again.

This is a rather fundamental problem though since it will also affect 
XXX-to-HTTP copies. (E.g. http put, but probably more likely webdav put)

Is there a way to make sure we have authenticated before doing the PUT / POST?

> No. It is not really the fault of KHTML.  It is actually a problem with the
> implementation of KIO::http_post and hence KIO::TransferJob which only
> take a QByteArray as an argument. If both this interfaces took a filename
> or a file descriptor, this whole problem would not exist. Any application
> making use of them can then save the data to be uploaded to a temporary
> file as need and pass that information.
>
> Right now if you attempt to upload a large file, KHTML first loads it into
> memory and transfers that data to konqueror, which then copies it into its
> own buffer just in case you want to re-post (back-button), and it sends the
> data to the KIO sub system where kio_http makes yet another copy for the
> aforementioned reason.  The picture is a bit better with webdav since the
> KHTML equation is out of the picture. That is why I wrote KIO::PostJob
> which was derived from KIO::TransferJob and posted it to kfm-devel. 
> However, no one bothered to take a look at it :(

Must have missed it. (http://lists.kde.org/?l=kfm-devel&m=104520816914645&w=2 
I assume?) Looks good although I would keep this blockSize stuff out of the 
API.

Did you test the error handling? I think you need to kill the slave when you 
hit these KIO::ERR_INTERNAL; conditions, otherwise the slave is kept around 
in an undefined state.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com





More information about the kfm-devel mailing list