On Thursday 04 November 2010 11:29:41 Daniel Stenberg wrote:
> On Thu, 4 Nov 2010, Kamil Dudka wrote:
> > Daniel, could you please have a look at the following trace?
> >
> > $ curl -s 'https://bugzilla.redhat.com/attachment.cgi?id=457738' \
> >
> > | grep ' FTP '
>
> It looks funny to me. Look at this particular section. I've edited the
> output slightly to appear less weird in mail so the [C] is for client
> sending and [S] is for sever responding:
>
> 3981 235.072002 [C] SIZE fedora-release-notes-14.1.1-1.fc14.noarch.rpm
> 3982 235.072101 [S] 213 1555788
> 3983 235.072277 [C] REST 1384
> 3984 235.072332 [S] 350 Restart position accepted (1384).
> 3985 235.072502 [C] RETR fedora-release-notes-14.1.1-1.fc14.noarch.rpm
> 3986 235.072687 [S] 150 Opening BINARY mode data connection for
> fedora-release-notes-14.1.1-1.fc14.noarch.rpm (1555788 bytes).
> 4054 235.102878 [C] ABOR
> 4059 235.103017 [S] 426 Failure writing network stream.
> 4064 235.103184 [S] 225 No transfer to ABOR.
>
> Assuming 235.072687 is the time the 150 response to RETR was seen, the ABOR
> command is sent only 30ms afterwards which seems very fast. Now that could
> be fine if that was just a small range of data requested. I can't see how
> much data it wanted other than it wanted to start at offset 1384.

Thanks for looking at the issue. I don't know the exact amount of downloaded
data. It may be a few bytes only.

> But, the server's response seems to indicate that the transfer was not
> succesful in the first place: "426 Failure writing network stream" with the
> following "225 No transfer to ABOR.". So why was ABOR sent? I think perhaps
> the condition for sending ABOR should also check if 'premature' is TRUE so
> that it only ABORs when closing before the expected end of transfer.

We close the data channel in the middle of the data transfer. That is what
causes the failure I think. Checking the 'premature' flag does not solve the
problem. At least it did not in the case of Pure-ftpd. The flag was not set
anyway.

> I suspect there's also another problem here since this ABOR introduces a
> second server response that isn't supported by the ABOR code that was
> added. But that's a secondary problem, if anything.

I wonder if a solution would be to send ABOR, wait for a response and even
then close the data connection?

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-11-04