New kio_http branch ?

[Dawit A.]

On Tuesday 22 April 2003 08:13, Waldo Bastian wrote:
> > 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?

The chances of the above scenario happenning are actually small since you 
first have to pull the page that allows to upload the form, but it can indeed 
occur. Anyways, the new job (PostJob) tries to deal with this issue by 
resetting its buffer whenever it reaches the end or an error occurs.  The 
only thing missing is the ability to have it reset on command/request of the 
io-slave so that the io-slave can have some control.  So the kio_http I have 
right now simply streams the data in chunks and does not store anything.  

> > 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.

I added those functions to allow some control over the rate of upload for 
those that want/need to limit upload rates for whatever reason.  I thought a 
reasonable default of 256 KB would suffice for most, but by making it 
configurable I get out of the issue of having to determine what is the 
appropriate value under all circumstances. :)

> 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.

I actually tested this by accident and it seemed to work at the time. The 
original implementation you sited above had a bug where if you submitted an 
empty form, it would cause this condition (KIO::ERR_INTERNAL) to be reached.  
I do call slotFinished which seems to call slaveDone, which in turn invokes 
Scheduler::jobFinished.  Would that suffice ?

Regards,
Dawit A.

P.S.  Latest version of PostJob is attached below.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postjob.cpp
Type: text/x-c++src
Size: 7733 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20030423/b9636ac5/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postjob.hpp
Type: text/x-c++src
Size: 3289 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20030423/b9636ac5/attachment.c>