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.
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.
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.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
