How can I configure Serv-U to redirect HTTP to HTTPS

This isn't currently supported in Serv-U, but I can see the utility of it.  You should definitely post this in the feature request forum to document it and improve visibility of the request so other users can vote on it:

http://thwack.solarwinds.com/community/application-and-server_tht/serv-u-ftp-server/serv-u-ftp-server-feature-requests

In the meantime, if you're already running a traditional web server (like IIS or Apache) on the same machine (or are comfortable doing this), you could have it handle the redirect request for you.

I added a similar comment already to the associated feature request. This feature seems or seemed to exist at least for Serv-U server since version 8.0.0.1 and we are using it since version 11 up to and including version 15. If it is currently not support, then we maybe work with a bug (but not a feature request) and should not touch the configuration, but it works excellent. Serv-U replies on port 80 with "302 Moved temporarily" containing the https fqdn.

Please see the release notes:

Serv-U Release Notes - 8

"Automatically redirect from HTTP to HTTPS when a secure connection is required and a corresponding HTTPS listener is found".

So we had set "require secure connection before login" in the server limits and settings section and enabled both the HTTP and HTTPS listeners within a domain on the same but only on one of the server IPv4 addresses only.

Just give it a try.

I've also made the same remark in the associated feature request.

I've tested this setting and enabling 'Require secure connection before login' did redirect HTTP to HTTPS even when using the Gateway.

However it also disallows normal FTP traffic. After setting 'Require secure connection before login' to YES only SFTP and 'FTP over TLS' are allowed. I would like to see a seperate option for http and ftp.

You are correct, but as a potential workaround the FTP listener on the same IP may be used in another domain that has 'require secure connection' disabled. It is not the best way to handle it, but it works well in our current configuration.

Wanted to add: in a normal configuration noone would want to encrypt the one connection and expose the same account credentials and data via another uncencrypted channel. From this perspective, the enforcement of secure channels on all listeners makes perfect sense. We are using it only for limited, local and anonymous FTP, so that different account credentials are not to be used at all.