configurable-http-proxy
Advanced tools
configurable-http-proxy (CHP) provides you with a way to update and manage a proxy table using a command line interface or REST API. It is a simple wrapper around node-http-proxy. node-http-proxy is an HTTP programmable proxying library that supports websockets and is suitable for implementing components such as reverse proxies and load balancers. By wrapping node-http-proxy, configurable-http-proxy extends this functionality to JupyterHub deployments.
Prerequisite: Node.js ≥ 10
If you're installing configurable-http-proxy in Linux, you can follow the instruction of nodesource to install arbitrary version of Node.js.
To install the configurable-http-proxy package globally
using npm:
npm install -g configurable-http-proxy
To install from the source code found in this GitHub repo:
git clone https://github.com/jupyterhub/configurable-http-proxy
cd configurable-http-proxy
npm install # Use 'npm install -g' for global install
The configurable proxy runs two HTTP(S) servers:
--ip,
--port)
--api-ip, --api-port)
CONFIGPROXY_AUTH_TOKEN environment variable.
configurable-http-proxy [options]
where [options] are the command-line options described below.
The default target is used when a client has requested a URL for which
there is no routing target found in the proxy table. To set a
default target, pass the command line option,
--default-target, when starting the configurable proxy:
configurable-http-proxy --default-target=proto://host[:port]
For example:
configurable-http-proxy --default-target=http://localhost:8888
Usage: configurable-http-proxy [options]
Options:
-V, --version output the version number
--ip <ip-address> Public-facing IP of the proxy
--port <n> (defaults to 8000) Public-facing port of the proxy
--ssl-key <keyfile> SSL key to use, if any
--ssl-cert <certfile> SSL certificate to use, if any
--ssl-ca <ca-file> SSL certificate authority, if any
--ssl-request-cert Request SSL certs to authenticate clients
--ssl-reject-unauthorized Reject unauthorized SSL connections (only meaningful if --ssl-request-cert is given)
--ssl-protocol <ssl-protocol> Set specific SSL protocol, e.g. TLSv1_2, SSLv3
--ssl-ciphers <ciphers> `:`-separated ssl cipher list. Default excludes RC4
--ssl-allow-rc4 Allow RC4 cipher for SSL (disabled by default)
--ssl-dhparam <dhparam-file> SSL Diffie-Helman Parameters pem file, if any
--api-ip <ip> Inward-facing IP for API requests (default: "localhost")
--api-port <n> Inward-facing port for API requests (defaults to --port=value+1)
--api-ssl-key <keyfile> SSL key to use, if any, for API requests
--api-ssl-cert <certfile> SSL certificate to use, if any, for API requests
--api-ssl-ca <ca-file> SSL certificate authority, if any, for API requests
--api-ssl-request-cert Request SSL certs to authenticate clients for API requests
--api-ssl-reject-unauthorized Reject unauthorized SSL connections (only meaningful if --api-ssl-request-cert is given)
--client-ssl-key <keyfile> SSL key to use, if any, for proxy to client requests
--client-ssl-cert <certfile> SSL certificate to use, if any, for proxy to client requests
--client-ssl-ca <ca-file> SSL certificate authority, if any, for proxy to client requests
--client-ssl-request-cert Request SSL certs to authenticate clients for API requests
--client-ssl-reject-unauthorized Reject unauthorized SSL connections (only meaningful if --client-ssl-request-cert is given)
--default-target <host> Default proxy target (proto://host[:port])
--error-target <host> Alternate server for handling proxy errors (proto://host[:port])
--error-path <path> Alternate server for handling proxy errors (proto://host[:port])
--redirect-port <redirect-port> Redirect HTTP requests on this port to the server on HTTPS
--redirect-to <port> Redirect HTTP requests from --redirect-port to this port
--pid-file <pid-file> Write our PID to a file
--no-x-forward Don't add 'X-forward-' headers to proxied requests
--no-prepend-path Avoid prepending target paths to proxied requests
--no-include-prefix Don't include the routing prefix in proxied requests
--auto-rewrite Rewrite the Location header host/port in redirect responses
--change-origin Changes the origin of the host header to the target URL
--protocol-rewrite <proto> Rewrite the Location header protocol in redirect responses to the specified protocol
--custom-header <header> Custom header to add to proxied requests. Use same option for multiple headers (--custom-header k1:v1 --custom-header k2:v2) (default: {})
--insecure Disable SSL cert verification
--host-routing Use host routing (host as first level of path)
--metrics-ip <ip> IP for metrics server (default: "")
--metrics-port <n> Port of metrics server. Defaults to no metrics server
--log-level <loglevel> Log level (debug, info, warn, error) (default: "info")
--timeout <n> Timeout (in millis) when proxy drops connection for a request.
--proxy-timeout <n> Timeout (in millis) when proxy receives no response from target.
--storage-backend <storage-class> Define an external storage class. Defaults to in-MemoryStore.
-h, --help display help for command
The configurable-http-proxy REST API is documented and available as:
API Root
| HTTP method | Endpoint | Function |
|---|---|---|
| GET | /api/ | API Root |
Routes
| HTTP method | Endpoint | Function |
|---|---|---|
| GET | /api/routes | Get all routes in routing table |
| POST | /api/routes/{route_spec} | Add a new route |
| DELETE | /api/routes/{route_spec} | Remove the given route |
The REST API is authenticated via passing a token in the Authorization
header. The API is served under the /api/routes base URL.
For example, this curl command entered in the terminal
passes this header "Authorization: token $CONFIGPROXY_AUTH_TOKEN" for
authentication and retrieves the current routing table from this endpoint,
http://localhost:8001/api/routes:
curl -H "Authorization: token $CONFIGPROXY_AUTH_TOKEN" http://localhost:8001/api/routes
Request:
GET /api/routes[?inactive_since=ISO8601-timestamp]
Parameters:
inactive_since: If the inactive_since URL
parameter is given as an ISO8601
timestamp, only routes whose last_activity is earlier than the timestamp
will be returned. The last_activity timestamp is updated whenever the proxy
passes data to or from the proxy target.
Response:
Status code
status: 200 OK
Response body
A JSON dictionary of the current routing table. This JSON dictionary excludes the default route.
Behavior:
The current routing table is returned to the user if the request is successful.
POST requests create new routes. The body of the request should be a JSON
dictionary with at least one key: target, the target host to be proxied.
Request:
POST /api/routes/[:path]
Required input:
target: The host URL
Example request body:
{
"target": "http://localhost:8002"
}
Response:
status: 201 Created
Behavior:
After adding the new route, any request to /path/prefix on the proxy's
public interface will be proxied to target.
Request:
DELETE /api/routes/[:path]
Response:
status: 204 No Content
Behavior:
Removes a route from the proxy's routing table.
Custom error pages can be provided when the proxy encounters an error and has no proxy target to handle a request. There are two typical errors that CHP may hit, along with their status code:
404 error: Returned when a client has requested a URL for which there is no
routing target. This error can be prevented by setting a
default target before starting the configurable-http-proxy.
503 error: Returned when a route exists, but the upstream server isn't responding. This is more common, and can be due to any number of reasons, including the target service having died, not finished starting, or network instability.
When starting the CHP, specify an error path --error-path /usr/share/chp-errors
to the location of the error page:
configurable-http-proxy --error-path /usr/share/chp-errors
When a proxy error occurs, CHP will look in the following location for a custom html error page to serve:
/usr/share/chp-errors/{CODE}.html
where {CODE} is a status code number for an html page to serve. If there is
a 503 error, CHP will look for a custom error page in this location
/usr/share/chp-errors/503.html.
If no custom error html file exists for the error code, CHP will use the default
error.html. If you specify an error path, make sure you also create
a default error.html file.
You can specify a target URL to use when errors occur by setting
--error-target {URL} when starting the CHP.
If, for example, CHP starts with --error-target http://localhost:1234,
and the proxy encounters an error, the proxy will make a GET request to
the error-target server. The GET request will be sent to the error-target
server URL, http://localhost:1234, appending the status code
/{CODE}, and passing the failing request's URL escaped in a URL parameter:
GET /404?url=%2Fescaped%2Fpath
If the CHP is started with the --host-routing option, the proxy will
use the hostname of the incoming request to select a target.
When using host-based routes, the API uses the target in the same way as if the hostname were the first part of the URL path, e.g.:
{
"/example.com": "https://localhost:1234",
"/otherdomain.biz": "http://10.0.1.4:5555",
}
Q: My proxy is not starting. What could be happening?
LTS
version.4.6.2 - 2024-06-10
4.6.2 switches the unmaintained http-proxy dependency to the http-proxy-node16 fork,
which improves behavior around leaking sockets.
The following people contributed discussions, new ideas, code and documentation contributions, and review. See our definition of contributors.
(GitHub contributors page for this release)
@consideRatio (activity) | @manics (activity) | @minrk (activity)
FAQs
A configurable-on-the-fly HTTP Proxy
We found that configurable-http-proxy demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 3 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.