Bug 54253 - mod_proxy_ftp doesn't handle/log partial or cancelled downloads correctly
Summary: mod_proxy_ftp doesn't handle/log partial or cancelled downloads correctly
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_ftp (show other bugs)
Version: 2.2.22
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2012-12-05 19:37 UTC by Adam Dosch
Modified: 2018-11-07 21:09 UTC (History)
0 users

mod_proxy_ftp FTP rc426 handling proposed patch (1.44 KB, patch)
2012-12-05 19:37 UTC, Adam Dosch
Details | Diff
mod_proxy_ftp - completed download debug (5.58 KB, text/plain)
2012-12-05 19:38 UTC, Adam Dosch
mod_proxy_ftp - user cancelled/aborted/terminated download debug (5.73 KB, text/plain)
2012-12-05 19:39 UTC, Adam Dosch

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Dosch 2012-12-05 19:37:36 UTC
Created attachment 29701 [details]
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.
Comment 1 Adam Dosch 2012-12-05 19:38:45 UTC
Created attachment 29702 [details]
mod_proxy_ftp - completed download debug
Comment 2 Adam Dosch 2012-12-05 19:39:18 UTC
Created attachment 29703 [details]
mod_proxy_ftp - user cancelled/aborted/terminated download debug
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:36 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.