putting "https://....." in hostname config directive results in a malformed URL

[dBitech]

My tegola instance is behind a haproxy that handles my ssl termination/offloading. To meet the requirement that there is no mixed mode (http/https) in the front end, I need to have the URL's being returned within the capabilities.json upgrade the proto from http to https.

To do this, I was told to use the hostname = directive in the `[webserver]' section which I've done below:

[webserver]
port = ":9001"
hostname = "https://myhost.tld"
...

This however results in malformed url's in the capabilites.json

{
  "attribution":"",
  "bounds":[-180,-85.0511,180,85.0511],
  "center":[0,0,0],
   "format":"pbf",
   "minzoom":5,
   "maxzoom":24,
   "name":"locationdata",
   "description":null,
    "scheme":"xyz",
    "tilejson":"2.1.0",
    "tiles":[
         "http://https:%2F%2Fmyhost.tld/maps/location/{z}/{x}/{y}.pbf"
     ],
    "grids":[],
    "data":[],
    "version":"1.0.0",
    "template":null,
    "legend":null,
    "vector_layers" [
        {
            "version":2,
            "extent":4096,
            "id":"subscribers",
            "name":"subscribers",
            "geometry_type":"point",
            "minzoom":5,
            "maxzoom":24,
            "tiles":[
                "http://https:%2F%2Fmyhost.tld/maps/location/subscribers/{z}/{x}/{y}.pbf"
            ]
        },
        {
            "version":2,
            "extent":4096,
            "id":"subscriber_areas",
            "name":"subscriber_areas",
            "geometry_type":"line",
            "minzoom":9,
            "maxzoom":24,
            "tiles":[
                "http://https:%2F%2Fmyhost.tld/maps/radiolocation/subscribers/{z}/{x}/{y}.pbf"
            ]
        }
    ]
}

If it makes any difference I'm running FreeBSD 14.1 as the OS, with tegola from a fresh (today) git pull

[dBitech]

In looking at func scheme() I see we do some auto detection for X-forward-for, This header is considered non-standard though its use is fairly ubiquitous.
X-Forward-For has been superseded by RFC7239. It would probably be well served to implement support for that as well. Haproxy will set this header properly when options forwarded is add to the relevant haproxy backend section of the configuration. The go-forward package makes handling both X-Forward-* and forwarded headers easy.

[gdey]

Thank you for this report. This does sound like a bug.

[gdey]

I'll look at this issue tomorrow.

[ARolek]

@dBitech well fixing this turned into a bit of a refactor journey for me. Here's the PR if you want to give it a test: #1004. Note, I have not implemented the forward header enhancement yet. That will happen in a separate issue (#1003)