#5063 closed Patch (rejected)
[PATCH] FileZilla not waiting for server reply before upload (starts too early)
| Reported by: | Bogdan Drozdowski | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | FileZilla Client |
| Keywords: | upload too early, not waiting for response | Cc: | |
| Component version: | Operating system type: | Windows | |
| Operating system version: | XP SP3 on a x86-32 |
Description
FileZilla Client 3.3.0.1 issuea a STOR doesn't wait for the FTP server to send a reply (assumes positive) and starts sending the selected file immediately after the STOR command. Wireshark dump available, if needed.
This patch should fix this issue, but I'm warning: I didn't compile FileZilla after patching (too old system), so I don't know if it compiles (should) or works. Even if it doesn't, I hope it will "push" you in the right direction.
Check if this could fix the "file uploaded, but zero length" series of bugs.
Attachments (1)
Change History (3)
by , 14 years ago
| Attachment: | filezilla-wait-for-150.diff.gz added |
|---|
follow-up: 2 comment:1 by , 14 years ago
| Resolution: | → rejected |
|---|---|
| Status: | new → closed |
Thanks, however I don't think the patch is correct. According to the specifications there is no requirement to wait for the confirmation:
To quote RFC 959:
The passive data transfer process (this may be a user-DTP or a
second server-DTP) shall "listen" on the data port prior to
sending a transfer request command. The FTP request command
determines the direction of the data transfer. The server, upon
receiving the transfer request, will initiate the data connection
to the port. When the connection is established, the data
transfer begins between DTP's, and the server-PI sends a
confirming reply to the user-PI.
If taking the RFC literally, it's even the other way around, the transfer has to begin before even sending the 1yz confirmation.
Another problem with your patch would be a significant slowdown of the overall throughput if transferring many small files, since every transfer would be slowed down by at least one additional application layer round-trip-time.
comment:2 by , 14 years ago
Replying to codesquid:
Thanks, however I don't think the patch is correct. According to the specifications there is no requirement to wait for the confirmation:
To quote RFC 959:
The passive data transfer process (this may be a user-DTP or a
second server-DTP) shall "listen" on the data port prior to
sending a transfer request command. The FTP request command
determines the direction of the data transfer. The server, upon
receiving the transfer request, will initiate the data connection
to the port. When the connection is established, the data
transfer begins between DTP's, and the server-PI sends a
confirming reply to the user-PI.
If taking the RFC literally, it's even the other way around, the transfer has to begin before even sending the 1yz confirmation.
I'd argue about the "has to begin". The "and" doesn't say anything about the order of the actions. But never mind that.
I've just wanted to avoid unnecessary data transfers in case the server sends a negative reply to the STOR command, in which case the data wouldn't reach the server (or worse, would reach it in another transfer, when a 125 reply is sent). However, if the client issues a PASV before each transfer and the server gets a new port each time, mistakenly assigning data to the new transmission hopefully should never happen. Perhaps it could happen in active mode if the client uses the same port and doesn't close it each time.
Another problem with your patch would be a significant slowdown of the overall throughput if transferring many small files, since every transfer would be slowed down by at least one additional application layer round-trip-time.
You're absolutely right about the delay, I realized that.
Anyway, thanks for reading my ticket and for replying so quickly. Keep up the good work on FileZilla!
GZipped patch to (hopefully) fix the issue and another minor mistake