When a native FTP request is transparently redirected to the FTP Proxy, it contains no hostname
information for the FTP server, only its IP address. Because of this, some predefined URL categories
and Web Reputation Filters that have only hostname information will not match native FTP requests,
even if the requests are destined for those servers. If you wish to block access to these sites, you must
create custom URL categories for them using their IP addresses.

Large FTP Transfers Disconnect

If the connection between the FTP Proxy and the FTP server is slow, uploading a large file may take a long
time, particularly when Cisco Data Security Filters are enabled. This can cause the FTP client to time out
before the FTP Proxy uploads the entire file and you may get a failed transaction notice. The transaction
does not fail, however, but continues in the background and will be completed by the FTP Proxy.

You can workaround this issue by increasing the appropriate idle timeout value on the FTP client.

Zero Byte File Appears On FTP Servers After File Upload

FTP clients create a zero byte file on FTP servers when the FTP Proxy blocks an upload due to outbound
anti-malware scanning.

Chrome Browser Not Detected As User Agent in FTP-over-HTTP Requests

Chrome browsers do not include a user-agent string in FTP-over-HTTP requests; therefore, Chrome
cannot be detected as the user agent in those requests.

Upload/Download Speed Issues

The WSA is designed to handle thousands of client and server connections in parallel, and the sizes of
the send and receive buffers are configured to deliver optimal performance, without sacrificing stability.
Generally, actual usage is browse traffic, consisting of numerous short-lived connections for which we
have receive-packet-steering (RPS) and receive-flow-steering (RFS) data, and for which the WSA has
been optimized.