Support special webserver.port ports ending in "s" (secure) and "r" (redirect)

[DL6ER]

What does this implement/fix?

Add support for special webserver.port ports ending in "s" (secure) and "r" (redirect)

Even when it made the code somewhat more bulky (especially the last-character-is-check), all my additions are POSIX-compliant.

---

Related issue or feature (if applicable): N/A

Pull request in docs with documentation (if applicable): N/A

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories developmental branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.

[yubiuser]

The redirect part is tricky

nanopi@nanopi:~$ pihole -q flurry.com
curl: (6) Could not resolve host: nanopi.lan
curl: (6) Could not resolve host: nanopi.lan
Found  domains exactly matching 'flurry.com'.

/opt/pihole/query.sh: 66: [: Illegal number: 
Found  adlists exactly matching 'flurry.com'.

/opt/pihole/query.sh: 79: [: Illegal number: 

++ pihole-FTL --config webserver.port
+ ports=80r,443s
+ port=80r
+ '[' r = s ']'
+ '[' r = r ']'
+ API_PROT=http
+ API_PORT=80
+ API_URL=http://localhost:80/api
++ curl -skSL -o /dev/null -w '%{http_code}' http://localhost:80/api/auth
curl: (6) Could not resolve host: nanopi.lan
+ availabilityResonse=308

nanopi@nanopi:~$ curl -vL -o /dev/null -w '%{http_code}' http://localhost:80/api/auth
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /api/auth HTTP/1.1
> Host: localhost
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 308 Permanent Redirect
< Location: https://nanopi.lan/api/auth
< Cache-Control: max-age=3600
< Content-Security-Policy: default-src 'self' 'unsafe-inline';
< X-Frame-Options: DENY
< X-XSS-Protection: 0
< X-Content-Type-Options: nosniff
< Referrer-Policy: strict-origin-when-cross-origin
< Content-Length: 0
< Date: Sun, 26 Nov 2023 20:42:53 GMT
< Connection: close
< 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://nanopi.lan/api/auth'
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Could not resolve host: nanopi.lan
* Closing connection 1
curl: (6) Could not resolve host: nanopi.lan
308

---

Do you see what's happening here: FTL returning the hostname instead of localhost for the redirect, but the device does not use FTL as upstream do it does not know about the hostname.....

[yubiuser]

/etc/hosts did contain the hostname, but without domain suffix.

[DL6ER]

We discussed at some place that redirects should go to webserver.domain instead of whatever IP, etc. is used to ensure TLS certificates will work as expected. But I do see where this may be problematic. Any good suggestions? I will keep thinking about this myself but, yeah, I did not factor in the possibility that the device running Pi-hole cannot resolve its own domain.

How does it look like if you configure webserver.domain to be nanopi without lan?

[yubiuser]

How does it look like if you configure webserver.domain to be nanopi without lan?

This works.

---

Any good suggestions?

I still love your idea of FTL offering a TXT record where to find the (final) API.

[DL6ER]

I still love your idea of FTL offering a TXT record where to find the (final) API.

But it suffers from the same illness. It'd also report something like http://<webserver.domain>:<port>/api and when the host does not know how to resolve webserver.domain we'd be in exactly the same scenario as we are now (with much less code)

[yubiuser]

Should we keep the approach to use pihole-FTL --config or use the feature implemented in pi-hole/FTL#1793?

[DL6ER]

Let's go for the simpler option...