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
