HTTP fallback configuration, testing and troubleshooting

by Jay Migliaccio


This article intends to educate the reader on the various options for using HTTP fallback and what configuration settings are required for those options. The article focuses in on the use of HTTP Fallback with the Aspera Connect server, or your own custom web application. This article also provides a few troubleshooting tips.


Simply put, HTTP fallback is a Aspera file transfer service which uses HTTP as the file transfer protocol. This service is available if you happen to be one of the unfortunate few whose Network Administrators do not allow you to do FASP Transfers. This service comes as part of the Aspera Enterprise Server installation package.

The HTTP Fallback service can be configured in two basic scenarios: Direct Mode and Indirect Mode. I describe both of them in this article.

Direct mode:

The HTTP Fallback service is not running on the standard HTTP ports (80/443). In this mode, the Aspera Connect client, when falling back to HTTP will connect directly to the Aspera HTTP server on a port other than 80 and/or 443. The reason that the Aspera HTTP Fallback service is not run on port 80/443 is simple: There is a web application already running on those ports; most likely the Aspera Connect server, or your own custom developed one.

The following 4 configurations must be set:

  1. Aspera HTTP server must be running and configured. The aspera.conf file must contain the following:


    If you have changed any of the settings in this section, be sure to restart the AsperaHTTPD server. In Windows, please use the Services panel to restart the AsperaHTTPD service. On Linux systems, you can issue this command, when logged in as the user root:

    # /etc/init.d/asperahttpd restart
  2. Set 'Token Auth' required in . This is most commonly set in the default section, but it can also be set per user or group.

    <encryption_key>change-me-secret-key-for-http fallback</encryption_key>
  3. The FASP URL must list the right ports for the Connect client to connect to the HTTP Fallback service. If you are using Aspera Connect Server, make sure to edit to advertise the HTTP ports:

    <WEB HttpFallback="yes" 
    HttpsFallbackPort="8443" />

    Example FASP URL
    . The URL must direct Connect client to use HTTP fallback on the appropriate ports. For Connect Server, view the source of web page, for example, this is what you need to see at a minimum, that the 'token', 'fallback' and 'httpport' settings have values:

  4. Encryption works dynamically

    The dir-listing script will automatically set the appropriate URL parameter value (HTTPport) depending on what 'enc' value is set. This works per user. For example, if user aspera has encryption set (via ), then the aspera-dirlist.plscript will automatically set the appropriate HTTPport in the FASP URL.

Indirect mode/proxy mode:

The HTTP Fallback service is only accessible via a reverse proxy running on the Web server. The Aspera Connect client will connect to the Web server (ie: Apache) on port 80/443 which in turn will proxy the connection to the Aspera HTTP service. This configuration is used in environments where Clients can only connect on the standard HTTP ports (80/443).

  1. Aspera HTTP server must be running and configured, for example, . Note how in this case, the service is configured to run on the local interface, rather than the public one. Also note how only HTTP is enabled - that is because Apache can only proxy in HTTP, not in HTTPS.


    If you have changed any of these settings, restart the AsperaHTTPD service: Set 'Token Auth' required in the default section of : Configure the Connect Server to advertise the HTTP ports:

    <WEB HttpFallback="yes" 
    HttpsFallbackPort="443" />
  2. FASP URL must direct the Connect client to use HTTP fallback on the appropriate ports. For Connect Server, view the source of web page, for example, this is what you need to see:

  3. The web server (Apache) must be configured as a proxy, to proxy the requests that Connect client initiate.

    a. Configure the Apache SSL proxy engine on in the SSL config (Cent OS/ RHEL): /etc/httpd/conf.d/ssl.conf

    b. Set this value:

    SSLProxyEngine on

    c. Configure Apache to be a proxy balancer.

    NOTE: this configuration needs to be in /opt/aspera/common/apache/custom/fallback.conf:

    <Proxy balancer://http_fallback> 
    ProxyPass /aspera/http balancer://http_fallback
    ProxyPass /aspera/https balancer://http_fallback

    d. After making these changes, you will need to restart the Apache service. For example:
    # /etc/init.d/httpd restart
  4. Encryption works dynamically - see note above.

Custom web apps:

If you are building your own custom web application, be sure to create a FASP URL that includes
the 'fallback=yes' key/value pair. Additionally, if you are not using the default ports (80 / 443), please specify the ports you want to use with the 'httpport=XXX' key/value pair. If you have a custom web application, it is necessary to generate your own tokens as well. You can learn more about our token generator in the Aspera Developer Network.

Testing and troubleshooting

How can you verify if HTTP fallback is working - and what to look at, if it is not?

  1. Trigger a failure - Block UDP or SSH 22 on the server (in Connect Server configure section WEB to SSH_PORT 7777 so client tries to reach SSH on port 7777 and fail)
  2. Check the FASP URL (does it contain Token, fallback=yes, http_fallback_port=XX)?
  3. Check the connect logs for a sign that connect is attempting to use HTTP
  4. Check the server logs, to confirm that the asperahttpd server is initiated
  5. If needed: Check the Apache logs to verify that it is receiving requests for HTTP fallback
Powered by Zendesk