A lightweight proxy application where the client can define the request to the target.

My main reason is to be able to build powerful PWA. An PWA is an application which is running inside a browser. Therefore, this kind of application are bound to the restrictions of the browser. One restriction is the CORS-Policy: The application can not make a request to a different origin than the application is hosted. For that issue you can use for example CORS Anywhere-Proxy to let set the required CORS-Headers. This will resolve a lot of issues but not all. If you want to build an application which crawl information from other origins it can be happened that you have click accept a cookie-banner to get the information. This is not an CORS- Issue but a Cookie-Issue. And because of browser restrictions an js-application is not able to store/read cookies from foreign origins!

Don't get me wrong: these are all good mechanism to prevent users from hacking... But in my case this drives me to implementing such applications not as PWA but as Desktop-Apps - and it makes me sag :(

You can build it on your own (you will need golang installed):

go build -a -installsuffix cgo -o r-ray ./cmd/app

Or you can download the release binaries: here

Or you can start this application as docker:

docker pull ghcr.io/rainu/r-ray

Start the application:

# as binary
CREDENTIALS=user:secret ./r-ray

# as docker container
docker run -p 8080:8080 -e "CREDENTIALS=user:secret" ghcr.io/rainu/r-ray:main

After that you can make any request:

# path encoded url. For example: https://github.com/rainu/r-ray
curl -v -u "user:secret" localhost:8080/https%3A%2F%2Fgithub.com%2Frainu%2Fr-ray

 +--------+          +-------+         +--------+        
 |        |  --1-->  |       |  --2--> |        |
 | client |          | r-ray |         | target |
 |        |  <--4--  |       |  <--3-- |        |
 +--------+          +-------+         +--------+

• The target url must be given in the path. This path should be encoded correctly!
• The same http-method will be used for target request as the clients request is.
• All header which have the prefix from REQUEST_HEADER_PREFIX (default R-) will be transferred to the url's target (without the prefix).
• If a header with FORWARD_REQUEST_HEADER (default R-Forward-Request-Header-) is sent, all request headers which match the regular expression, will be transferred to the target too
• All headers from the target will be prefixed with REQUEST_HEADER_PREFIX (default R-) and sent to the client
• If a header with FORWARD_RESPONSE_HEADER (default R-Forward-Response-Header-) was sent, all response headers which match the regular expression, will be transferred as is to the client
• If the header FORWARD_RESPONSE_STATUS_HEADER (default R-Forward-Response-Status) was sent with any value, the targets status code will be forwarded to the client.

> POST /http://target.com/ HTTP/1.1
> User-Agent: fancy-client
> R-Accept: money
> R-Forward-Request-Header: user-.*

Will results in:

> POST http://target.com/ HTTP/1.1
> User-Agent: fancy-client
> Accept: money