New kio_http branch ?

[Waldo Bastian]

On Wednesday 23 April 2003 09:59, Dawit A. wrote:
> 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 works with POST but it doesn't fix the problem for PUT.

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

It only affects internal data handling.

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

It's not about the job, it's about the slave. You are only supposed to hand back a slave 
to the scheduler when the slave is ready to accept a new job. I guess this is ok in PostJob::start 
since at that time the slave hasn't actually received anything yet. But in dataReq the slave
is in the middle of doing stuff. If you then call jobFinished the slave is handed back to the 
scheduler but doesn't expect any commands at all yet. So the next job who happens to get
this slave will end up with a non-functioning io-slave.

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