Project

General

Profile

Forums » General »

Last testing builds are not working through reverse-proxy [solved]

Added by Iam Nague over 8 years ago

Tvheadend 4.1 release works through reverse-proxy like a charm.

I'm now trying to run last testing build (4.1-1931~gc3eefc6~trusty), but the webgui doesn't open through reverse-proxy.

It's seem to be relate to “@import url()” tag in CSS templates that can’t be rewrite by reverse-proxy.

For example, get /redir/theme.css, returns:

HTTP/1.1 200 OK Server: HTS/tvheadend Cache-Control: no-cache Connection: Keep-Alive Location: /static/tvh.blue.css.gz Content-Type: text/css Content-Length: 41 @import url('/static/tvh.blue.css.gz');

Could we do something to change that ? Maybe using <link> tag instead ?

Thanks for your help.


Replies (3)

RE: Last testing builds are not working through reverse-proxy - Added by Man Oki over 8 years ago

workaround: you can change the webroot of tvheadend via

TVH_HTTP_ROOT="/tvheadend"

and set the proxy to http://localhost:9981/tvheadend instead of http://localhost:9981/.

in this case, tvheadend generates the correct relative urls, which does not have to be corrected by the proxy.

RE: Last testing builds are not working through reverse-proxy [solved] - Added by Man Oki over 8 years ago

another related issue, i just found out: set "ProxyPreserveHost On" in apache cause tvheadend use the 'correct' host seen by the client. especially when you use the "play program" button, which downloads an m3u file with an link to tvheadend.

my apache configuration for tvheadend:

<Location /tvheadend>
        SSLRequireSSL

        ProxyPass http://localhost:9981/tvheadend
        ProxyPassReverse http://localhost:9981/tvheadend
        ProxyPreserveHost On

        AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE audio/x-mpegurl
        Substitute "s|http://|https://|i" 
</Location>

update: the protocol (http/https) is not preserved, but can be substituted inside the response from apache with mod_substitute (see apache config). this is more secure than redirect to https as shown before.

    (1-3/3)