This fixes an issue I had running get_iplayer behind a reverse proxy. This only touches the inbuilt webserver, not the fetching part of get_iplayer.
Context
The get_iplayer web ui can sit behind a reverse proxy, in its own subpath, on a shared domain. (e.g. https://mydomain.com/get_iplayer).
To make this work the flag --baseurl https://mydomain.com/get_iplayer is used.
However the problem arises as get_iplayer now redirects every link to the reverse proxy url - regardless if you're trying to access it locally via http://localhost:8080 say. This means if the reverse proxy is not functional interactions with get_iplayer are broken too.
I feel that being able to directly interact with get_iplayer, regardless if it's being fronted by a proxy, should be possible.
Solution
As an alternative to --baseurl, --basepath allows get_iplayer to be accessed via the reverse proxy (on it's own /get_iplayer path), and still locally via http://localhost:8080.
To maintain current behavior of browser directly to the get_iplayer port, if --basepath is defined, and someone requests / it'll be redirected to /$basepath, instead of just returning a 404.
[...]
* Connected to localhost (127.0.0.1) port 9090 (#1)
> GET /get_iplayer HTTP/1.1
> Host: localhost:9090
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 13 Jan 2022 00:48:43 GMT
< Content-Type: text/html; charset=utf-8
* no chunk, no close, no size. Assume close to signal end
<
{ [103 bytes data]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><HEAD><TITLE>get_iplayer Web PVR Manager v3.28</TITLE>
[...]
Instead, run another instance without --baseurl on same machine but different port. However, neither approach is completely safe for multi-session access.
This fixes an issue I had running get_iplayer behind a reverse proxy. This only touches the inbuilt webserver, not the fetching part of get_iplayer.
Context
The get_iplayer web ui can sit behind a reverse proxy, in its own subpath, on a shared domain. (e.g. https://mydomain.com/get_iplayer).
To make this work the flag
--baseurl https://mydomain.com/get_iplayer
is used.However the problem arises as get_iplayer now redirects every link to the reverse proxy url - regardless if you're trying to access it locally via http://localhost:8080 say. This means if the reverse proxy is not functional interactions with get_iplayer are broken too.
I feel that being able to directly interact with get_iplayer, regardless if it's being fronted by a proxy, should be possible.
Solution
As an alternative to
--baseurl
,--basepath
allows get_iplayer to be accessed via the reverse proxy (on it's own/get_iplayer
path), and still locally viahttp://localhost:8080
.To maintain current behavior of browser directly to the get_iplayer port, if
--basepath
is defined, and someone requests/
it'll be redirected to/$basepath
, instead of just returning a 404.Testing
(All on linux)
./get_iplayer.cgi --port 9090
-> works per before./get_iplayer.cgi --port 9090 --basepath /get_iplayer
-> curl http://localhost:9090 redirects me to http://localhost:9090/get_iplayer