Hi all, this patch waits for long time in queue. If no objection I will apply this patch to trunk.
On 12/29/2015 06:31 PM, Christos Tsantilas wrote:
Problem description -------------------- FTP client gets stuck after the following chain of events: * Client requests a file that will be blocked by ICAP. * Squid starts downloading the file from the FTP server and sends "150 Opening..." to the FTP client. * Squid aborts the data connection with the FTP server as soon as the ICAP service blocks it. * Squid sends "451 Forbidden" to the FTP client. * The FTP server sends "500 OOPS: setsockopt: linger" to Squid. * Squid terminates the control connection to the FTP server. * Squid establishes a new control connection to the FTP server but does not authenticate itself. * Further commands from the FTP client do not work any more. The above and many similar problems exist because Squid handles FTP client-to-squid and squid-to-FTP server data connections independently from each other. In many cases, one connection does not get notified about the problems with the other connection. Tech details ------------ This patch: - Add Ftp::MasterState::userDataDone to record received the FTP client final response status code to sent (or to be send) to the client. - The Ftp::MasterState::waitForOriginData flag to hold status of the squid-to-server side. If the squid-to-server side is not finishes yet this is true. - Send a control reply to the FTP client only after the data transferred on both server and client sides. - Split Client::abortTransaction to Client::abortOnData and to Client::abortAll() - Implement the Ftp::Relay::abortOnData() and Ftp::Relay::Abort() (i.e., StoreEntry abort handler) to avoid closing the control connection when the data connection is closed unexpectedly. This is a Measurement Factory project.
_______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
