v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=
Just a little info on how we want to use Caddy.
We make devices. The endpoint of all devices is a “3”. In the middle may be a “2” and a starting point is the “1”. The “1” may be connected to multiple "2"s which in turn are connected to multiple "3"s or an “1” could be connected directly to several "3"s.
The “1” and “2” software was written by me. They handle dynamic protocols and path (for NAT). The “3” is legacy software and is much harder to get updated in the field.
The problem is when using Caddy as a reverse proxy, it all works well until it hits a “3” when running in HTTPS mode on the local server of an “1”. When reversed proxied, the context is running in the "1"s local server which is HTTPS, but the “3” is hard-coded to use http in it’s path to it’s own local server’s web sockets. Of course this gets errors.
Is it possible to have a configuration where it sees the HTTP and redirects it to HTTPs?
I saw this:
header_up X-Forwarded-Proto {scheme}
and wondering if this would be suitable.
One thing I should mention is that for “1” or “2” the end-user is able to run with HTTP, HTTPS or BOTH. We use the JSON api-endpoint. I set up both HTTP and HTTPS and before sending to Caddy, I determine of one of the servers should be removed.
As well, I dynamically add to the config by reading in some JSON as text, then replacing some placement text with actual data, convert it to JSON and merge it with the Caddy config that I’ll be sending to the JSON endpoint.
All of this is too big to post here, so I’ll add some fragments:
“2” template:
[
{
"handle":[
{
"handler":"subroute",
"routes":[
{
"handle":[
{
"handler":"rewrite",
"strip_path_prefix":"/%%SLUG%%"
}
]
},
{
"handle":[
{
"handler":"reverse_proxy",
"headers":{
"request":{
"set":{
"Access-Control-Allow-Credentials":[
"true"
],
"Access-Control-Allow-Headers":[
"Cache-Control,Content-Type"
],
"Access-Control-Allow-Origin":[
"*"
],
"X-Forwarded-Proto":[
"{http.request.scheme}"
],
"X-Real-Ip":[
"{http.request.remote.host}"
]
}
}
},
"upstreams":[
{
"dial":"%%ADDRESS%%:%%PORT%%"
}
]
}
]
}
]
}
],
"match":[
{
"path":[
"/%%SLUG%%/*"
]
}
]
}
]
“3” template:
[
{
"handle":[
{
"handler":"subroute",
"routes":[
{
"handle":[
{
"handler":"rewrite",
"strip_path_prefix":"/%%SLUG%%/ivt-hvr-web-app"
}
]
},
{
"handle":[
{
"handler":"reverse_proxy",
"headers":{
"request":{
"set":{
"Access-Control-Allow-Credentials":[
"true"
],
"Access-Control-Allow-Headers":[
"Cache-Control,Content-Type"
],
"Access-Control-Allow-Origin":[
"*"
],
"X-Forwarded-Proto":[
"{http.request.scheme}"
],
"X-Real-Ip":[
"{http.request.remote.host}"
]
}
}
},
"upstreams":[
{
"dial":"%%ADDRESS%%:%%WEBPORT%%"
}
]
}
]
}
]
}
],
"match":[
{
"path":[
"/%%SLUG%%/ivt-hvr-web-app/*"
]
}
]
},
{
"group":"group7",
"handle":[
{
"handler":"subroute",
"routes":[
{
"handle":[
{
"handler":"rewrite",
"strip_path_prefix":"/%%SLUG%%_files"
}
]
},
{
"handle":[
{
"handler":"reverse_proxy",
"headers":{
"request":{
"set":{
"Access-Control-Allow-Credentials":[
"true"
],
"Access-Control-Allow-Headers":[
"Cache-Control,Content-Type"
],
"Access-Control-Allow-Origin":[
"*"
],
"X-Forwarded-Proto":[
"{http.request.scheme}"
],
"X-Real-Ip":[
"{http.request.remote.host}"
]
}
}
},
"upstreams":[
{
"dial":"%%ADDRESS%%:%%DATAPORT%%"
}
]
}
]
}
]
}
],
"match":[
{
"path":[
"/%%SLUG%%_files/*"
]
}
]
},
{
"handle":[
{
"handler":"subroute",
"routes":[
{
"handle":[
{
"handler":"rewrite",
"uri_substring":[
{
"find":"/%%SLUG%%_socket_data/socket.io",
"replace":"/socket.io"
}
]
}
]
},
{
"handle":[
{
"handler":"reverse_proxy",
"headers":{
"request":{
"set":{
"Access-Control-Allow-Credentials":[
"true"
],
"Access-Control-Allow-Headers":[
"Cache-Control,Content-Type"
],
"Access-Control-Allow-Origin":[
"*"
],
"X-Forwarded-Proto":[
"{http.request.scheme}"
],
"X-Real-Ip":[
"{http.request.remote.host}"
]
}
}
},
"upstreams":[
{
"dial":"%%ADDRESS%%:%%DATAPORT%%"
}
]
}
]
}
]
}
],
"match":[
{
"path":[
"/%%SLUG%%_socket_data/*"
]
}
]
},
{
"handle":[
{
"handler":"subroute",
"routes":[
{
"handle":[
{
"handler":"rewrite",
"uri_substring":[
{
"find":"/%%SLUG%%_socket/socket.io",
"replace":"/socket.io"
}
]
}
]
},
{
"handle":[
{
"handler":"reverse_proxy",
"headers":{
"request":{
"set":{
"Access-Control-Allow-Credentials":[
"true"
],
"Access-Control-Allow-Headers":[
"Cache-Control,Content-Type"
],
"Access-Control-Allow-Origin":[
"*"
],
"X-Forwarded-Proto":[
"{http.request.scheme}"
],
"X-Real-Ip":[
"{http.request.remote.host}"
]
}
}
},
"upstreams":[
{
"dial":"%%ADDRESS%%:%%WEBPORT%%"
}
]
}
]
}
]
}
],
"match":[
{
"path":[
"/%%SLUG%%_socket/*"
]
}
]
}
]
and each of these will be filled out and merged with each server.
The actual beginning of the JSON template looks like this:
"apps":{
"http":{
"servers":{
"srv0":{
"automatic_https":{
"disable_redirects":true
},
"listen":[
":80"
],
...
and, I am wondering if I set "disable_redirects":false, when in HTTPS mode would help. Currently, this part of the server is complete removed from the JSON. But, would it be suitable to set it for this one, if the other one is removed?
"srv1":{
"automatic_https":{
"disable_redirects":true
},
"listen":[
":443"
],
...
One thing we are trying to avoid is the 301 Moved Permanently issue because end-users can change from HTTP or HTTPS any time.
As always, I appreciate your feedback and knowledge. Thanks in advance.
