On Fri, 9 Jan 2004, Daniel Stenberg wrote:

> On Wed, 17 Dec 2003, Dave Meyer wrote:
>
> > I've put together my first version (well, first public version) of a patch
> > to handle ftp server REST inconsistencies.
>
> Any news on this subject?

Nope, not yet -- about all I've been able to do is think about it briefly
at random intervals, which isn't terribly useful for actually
accomplishing anything.

> I'm starting to get a feeling that we should perhaps deal with this
> differently, as we the whole idea is a bit kludgy and it won't work fine for
> uploads.
>
> Perhaps we should instead figure out a good way to detect this and return back
> a clever error message somehow, and leave the application to re-attempt with a
> different REST value? I realize this makes it less transparant to
> applications, but this is all due to crappy servers, lack of support in the
> FTP protocol to do this and a limited API in libcurl...

Returning an appropriate error message (something that indicates the
application may want to retry with a different offset) sounds like a
pretty decent idea to me. I'd been thinking of proposing that as a
solution for the upload side of the solution anyway, since it seemed like
that was about the *only* way to make sure that applications would end up
doing the right thing (or, at least, would end up doing the right thing or
failing, as opposed to doing the wrong thing and thinking they'd
succeeded).

From the standpoint of symmetry, it probably makes sense for downloading
data, too. And, in fact, I wouldn't find it impossible for some
client-side application to wish to fail in cases where the download offset
wasn't properly supported (perhaps something time-sensitive), which
wouldn't be possible with my last patch. So I think I agree that
returning some type of clever error might be the best way to go.

If there was an exceedingly clever way to return the error message, we may
even be able to address the concerns that Dominick Meglio raised about
potential FTP servers whose replies aren't parsed appropriately by the
offset checking stuff. If we could get the server's message back to the
application, *it* could decide that the server was actually going to do
the right thing, and continue the transfer anyway. But that might be too
complicated, and for now, I digress. :)

> Anyway, would you mind if we postpone this REST issue to 7.11.1? It doesn't
> mean that you need to do anything different, just that I will get one item
> less to wait for/fix before 7.11.0 can be considered complete.

By all means, feel free to push this back to 7.11.1. That would certainly
make my life a little less hectic in the short term!

Thanks,

Dave

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
Received on 2004-01-09