https://issues.apache.org/bugzilla/show_bug.cgi?id=54253
Bug ID: 54253
Summary: mod_proxy_ftp doesn't handle/log partial or cancelled
downloads correctly
Product: Apache httpd-2
Version: 2.2.22
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_ftp
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Created attachment 29701
--> https://issues.apache.org/bugzilla/attachment.cgi?id=29701&action=edit
mod_proxy_ftp FTP rc426 handling proposed patch
Noticed this problem in 2.2.22 for HTTP distribution that ties into other
distribution hubs via FTP protocol, thus mod_proxy_ftp is used along with a
balancer group.
The problem is when a file is being downloaded via FTP through mod_proxy_ftp,
and the user cancels or stops the download, on the FTP server side, issues
'426' and then an 'i' is logged for 'incomplete' download in the xferlogs
(assuming you're logging with traditional xferlog style). I am using
vsftpd-2.0.5-16.
However, on the httpd side, the data connection terminates and handles
correctly (from my point of view) in the module, however, the reporting of a
HTTP retval of '200' to the access_log for that request seems incorrect to me.
I feel that if it's cancelled, aborted or terminated on the client side, then
it should be logged as so. The functionality isn't broken, it just causes a
big issue (in my case) when doing distribution metrics on full and complete
item(s).
It looks as though in proxy_ftp_handler() on line ~1707, it's just
automatically assumed that an HTTP_OK is fine all the way through, and only set
once at the very top of the handler function stack. It made sense to me to
re-evaluate this later down the line around line ~1905 when the last response
from the LIST or RETR commands is done.
I couldn't find any HTTP retval in RFC 2616 that would make sense from a
logging perspective for client-side termination, so I used what Nginx uses:
499 HTTP_CLIENT_CLOSED_REQUEST
Attached are my debug logs showing the FTP client/server output and a very
rough patch showing my 'solution' to it.
Please be kind; I'm a mere hack. If there's a better way to achieve the same
results, I'm certainly willing to listen.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
