The SCSP Proxy accepts HTTP requests from a host network, forwards them to a DX Storage
cluster, handles redirects transparently, and then supplies the response back to the requestor. In
many deployments, a DX Storage cluster might be isolated on an internal network, protecting it from
undesired interaction with the host network, and also protecting the host network from services like
PXE boot and multicast traffic that can interfere with other network resources.
This reverse proxy can serve several other purposes as well, both in production deployments and in
test environments.
Specifically, the SCSP Proxy supports the following types of interactions:
• Basic SCSP Proxy for a local cluster
• Remote cluster coordination and communication
• Validation of incoming client requests for proper syntax and formatting
1.1. Basic SCSP Proxy
In a local cluster deployment, the SCSP Proxy handles all local SCSP traffic and manages the
associated communication with the local DX Storage cluster. The SCSP Proxy listens for any
inbound SCSP communications on the configured port and determines which DX Storage node to
send the initial request to.
For optimal performance, the SCSP Proxy caches open connections to DX Storage for reuse.
For more information, see one of the following sections:
• Section 1.1.1, “Getting a List of DX Storage Cluster IPs”
The SCSP Proxy intercepts GET / and HEAD / requests and responds with information it stores
internally about itself and about the cluster for which it serves as a forward proxy. Only GET / and
HEAD / requests result in this type of special handling by the SCSP Proxy.
Query arguments are not processed, even when the resource is empty. A request with a query
argument is forwarded as-is to the cluster and receives no special processing by the Proxy.
The Proxy responds to a GET / request from a client running in a private network with the Proxy's
list of DX Storage IP addresses and data and metadata describing the Proxy's DX Storage cluster.
You can prevent the Proxy from returning cluster IP addresses using the configuration parameter
reportHosts. For more information about configuration parameters, see Chapter 3, Configuration
Parameters
1.1.1.1. Scsp-Proxy-Cluster Request Header
The optional Scsp-Proxy-Cluster: cluster-name request header, if included with a request,
causes the Proxy to first compare the case-sensitive cluster-name against the Proxy's own
configured cluster name. If the names do not match, no node IP addresses are returned in the
response.
If Scsp-Proxy-Cluster is not present, the request uses the configured cluster name and the list of
node IP addresses reflects the currently known node IPs for that cluster.
In either case, the response metadata includes a response header with the same name containing
the cluster name used by the Proxy.
1.1.1.2. Response Headers
The following table discusses response headers:
ResponseDescription
Scsp-Proxy-ClusterCluster name (for example, if the cluster is configured on
a CSN, it is the value of scsp.clusterName in /etc/
caringo/scspproxy/scspproxy.cfg).
Scsp-Proxy-NodesASCII string count of the number of node IP addresses
returned in the body of the response. If this count is zero,
an additional reason is supplied to explain why there were
no nodes returned. More information about the zero-node
response is discussed following the table.
Scsp-Proxy-AgentProxy and its software version.
Castor-System-
TotalGBAvailable, CastorSystem-TotalGBCapacity
Obtained by polling any available node on the local
cluster. These headers are provided to maintain
consistency with current Proxy and DX Storage
responses.
For example, the following response indicates there are 10 nodes in the cluster:
Scsp-Proxy-Nodes: count=10
If the response indicates zero nodes in the cluster, it is accompanied by a reason, as follows:
Scsp-Proxy-Nodes: count=0, reason=no-nodes
The following table discusses reason codes.
Reason for empty node listMeaning
no-nodesThe Proxy reports no nodes when, for example, the cluster is
off-line or is being rebooted.
bad-subnetThe request was made from a subnet from which the node IP
addresses are not routable.
The Proxy determines whether or not a request originated from
the same private subnet as its cluster and responds only if the
request did originate in that subnet. The Proxy does this to help
prevent malicious discovery about the cluster and because
private IP addresses are not routable anyway.
bad-clusterThe cluster name supplied in the Scsp-Proxy-Cluster
header did not match the currently configured cluster.
disabledIndicates the Proxy's reportHosts configuration parameter is
set to False.
1.1.1.3. Response Body
The body of the response to a GET / is Content-Type text/plain list of IP addresses of DX Storage
nodes local to that proxy, one address per CRLF-terminated line.
The Content-Length header calculation is based on the number of bytes in this list of CRLF
terminated IPs. If the list is empty, the Scsp-Proxy-Nodes header indicates count=0 and the
Content-Length header is zero.
The body of the response to a HEAD / is always empty, although the Content-Length header
indicates the total number of response bytes that would have been returned if the HEAD had been
a GET. Additionally, the Scsp-Proxy-Nodes header indicates the number of nodes that would have
been returned and, if this count is zero, provides the reason for the empty list exactly as it does for
GET /.
1.1.2. About Expect: 100-continue Behavior
If the initial request includes an Expect: 100-continue header, the SCSP Proxy waits to read
the input stream and won't rewind, seek, or reset it on a WRITE, APPEND, or UPDATE for small
streams until 100-continue is received. If the initial request does not include an Expect: 100-continue header, the SCSP Proxy buffers input from the client but attempts to stall the input data
object from the client if the buffer reaches a limit. If the request content length is larger than 128K, it
adds Expect: 100-continue to the request it sends to the local cluster and handle DX Storage's
100 response.
1.1.3. About Location Headers
To properly route subsequent requests, the SCSP Proxy returns one Location response header
with its own external IP address and discards any other Location headers. For Replicate on Write
requests, this means all Location response headers are rewritten.
1.2. Remote Cluster Communication and Coordination
Developers who need to interact with multiple DX Storage clusters, either independently or in
multi-cluster requests, can use the SCSP Proxy for remote cluster communication and can even
coordinate requests between more than one cluster at a time.
To use the following syntax, the proxy must be configured with a list of all known remote clusters (for
more information, see Chapter 3, Configuration Parameters). The following syntax is valid only with
the Proxy; sending requests formatted as follows directly to a DX Storage cluster results in a 404
(Not Found) error because DX Storage attempts to resolve it as a path to a named object.
SyntaxDescription
/_proxy/cluster-name/uuid-orname
/_proxy/any/uuid-or-nameany is valid only for remote INFO requests and
Sends a request for an object, referenced by UUID or
by name, to a specific cluster-name.
results in an error if used with any other method.
any causes a request to be sent for an object,
referenced by UUID or by name, to any available
cluster (local or remote).