FASP HTTP fallback explained (for command line or SDK)

Overview

This article provides key information to understand the FASP HTTP fallback mechanism.

HTTP fallback is a way for FASP to fallback on HTTP transport when FASP nominal ports (TCP+UDP/33001) of a server cannot be reached by a client.

There are several other articles that describe how to configure HTTP fallback, or how to (reverse) proxy http fallback with a standard HTTP server. This article concentrates on the lower client side level.

Architecture

In nominal FASP (UDP) mode, a client "ascp" process communicates directly with a server "ascp" process.

The architecture in HTTP fallback is slightly different:

  • The client side is also provided directly by the "ascp" executable.
  • The server side is provided by the "asperahttpd" daemon/service

Restrictions

HTTP fallback requires the use of a FASP "authorization token" for authorization. If no authorization token is provided on client side (-W or ASPERA_SCP_TOKEN), then HTTP fallback will fail with HTTP code: 403 Forbidden. So, in general, a higher level application (typically, a web application, but not necessarily) requests such authorization token from the transfer node, using the node API, and then provides this token to the client application, which in turn provides it to FASP (ascp command line "-W" or "ASPERA_SCP_TOKEN" env. var. , but it could be also through the "FaspManager" native API, or connect javascript API).

Command line activation

The following command line arguments are used for the HTTP fallback: (from ascp user manual)

ArgumentDescription
 -y <0|1>

Enable HTTP fallback transfer when UDP connection fails. Set to 1 to enable. (Default: 0)

(Note: for testing purpose, one can specify the "F" value for "-y" to bypass native FASP)

 -T Disable in-transit encryption. (not present -> HTTPS, present -> HTTP)
 -t <port> HTTP (with "-T") port or HTTPS (without "-T") port for fallback.
 -Y <key> HTTPS cert key for transfer (HTTPS only)
 -I <cert> HTTPS cert for transfer (HTTPS only)
 -x <url>  HTTP(S) forward proxy (optional)
-W <token> specify authorization token in command line. Note: prefer to use the "ASPERA_SCP_TOKEN" envvar for security purpose (token not shown on command line, not displayed with "ps")

Example use

In order to test http fallback we need access to a transfer node where HTTP fallback is configured, where a token encryption key is configured, and access to the node API.

The following command line example shows 1: token creation using node api, 2: transfer with http fallback.

$ curl -ki --user node_user:node_password  -d '{"transfer_requests":[{"transfer_request":{"paths":[{"destination":"/"}]}}]}' -H "Accept: application/json" -H "Content-Type: application/json"  -X POST https://eudemo.asperademo.com:9092/files/upload_setup
HTTP/1.1 200 OK
Cache: no-cache
Connection: close
Content-Type: application/json; charset=utf-8

{
"transfer_specs" : [
{
"transfer_spec" : {
"paths" : [
{
"destination" : "/"
}
],
"source_root" : "",
"destination_root" : "/",
"token" : "ATM3_ACsGh7NRzGA2-ANT6j6mT3O4UYw48JKSstgxg2y8PunjPYAAEc-5aMrqwWI9XCbMaE2Kxk_3MTA",
"direction" : "send",
"cipher" : "aes-128",
"rate_policy_allowed" : "fixed",
"rate_policy" : "fair",
"target_rate_kbps" : 50000,
"min_rate_kbps" : 0,
"remote_host" : "eudemo.asperademo.com",
"remote_user" : "xfer",
"ssh_port" : 33001,
"fasp_port" : 33001,
"http_fallback" : true,
"http_fallback_port" : 8443
}
}
]

$ ASPERA_SCP_TOKEN="ATM3_ACsGh7NRzGA2-ANT6j6mT3O4UYw48JKSstgxg2y8PunjPYAAEc-5aMrqwWI9XCbMaE2Kxk_3MTA" ascp -D -L- -T -l 1m -y F -t 8080 --user="xfer" --host="eudemo.asperademo.com" --mode=send Documents/Samples/200KB.1 /

 Notes:

Usually, when token authorization is used, then SSH is "bypassed" (but still used) with a "well known" SSH private key (with "-i", e.g. the one provided in connect client). Here we dont use any SSH authentication, so normally an SSH password would be asked. Here, for testing, we directly bypass nominal FASP by specifying "-yF", one can also stop the SSH server, or place a firewall, or specify (-P) a wrong SSH port. Anyway, here HTTP fallback is directly used, so none of SSH password or key will be used and the token authorization is the only authorization method used (and required).

The parameters returned in the REST call shall be used as a reference for arguments to ascp (remote_host, remote_user, ssh_port, token, etc...). For instance, a token is generated only for a given transfer user, and using a token for another transfer user shall result in a rejection.

For testing purpose, it is possible to use the command line "astokengen" on server side to generate a token (/opt/aspera/bin/astokengen --mode=send -u xfer). We intentionally did not use this here in order to not promote its use: the REST API shall always be used for token generation in production environments. (in order to retrieve other parameters, such as ports, user, address of server, etc... and so, avoid hardcoded duplicated values in an application.). Note that the result shows if HTTP fallback is enabled, encryption, etc...

For simplicity, we used HTTP in the example, by specifying "-T" (no encryption). HTTPS would require additional arguments for HTTPS certificates.

More information is available on the Aspera Developer Network, accessible with a SDK subscription. Contact us !

0 Comments

Article is closed for comments.
Powered by Zendesk