New kio_http branch ?

[Dawit A.]

On Wednesday 23 April 2003 04:58, Waldo Bastian wrote:
> 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?

Hmm... I must not have read you response very well the first time :(  On paper 
there is a possible work around this issue on paper. It is specified in 
section 8.2.3 of RFC 2616.  Basically, we can add an Expect: 100-continue to 
our header when the request is PUT or POST and send it without transmitting 
the data. We can then read the response from the server and react 
accordingly. The only problem with doing this is that this particular feature 
seems to be only applicable to HTTP/1.1 compliant servers and proxies at 
least according to the spec. So we still have to deal with exceptions...  And 
the new branch we discussed seems to be well suited for this kind of 
experimentation. :)

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

Indeed it does not. I did not realize that we pumped data from one io-slave to 
another when doing those XXX-to-YYY copies. 

[snipped]
> 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.

Ahh... I see what you mean. And if I use kill I lose the ability to set the 
error code, right ? I guess one way to get around this limitation to add a 
flag (e.g. setErrorCode) to KIO::Job which would be set to true by default 
and add a protected member function to manipulate it. This way I can set this 
flag to false before calling kill(...) from KIO::PostJob::slotDataReq. Would 
that work ?

Regards,
Dawit A.