Hello,
Correct me if I'm wrong, but what you get from Icecast *is* HTTP.
Anyway, we use proxying because on our server, some of our clients
cannot connect to port 8000 without bypassing their company firewall,
and we don't have the possibility to add another public IP. So with
Apache, here is what we do :
########################################################################
#
# VirtualHost for live.radiom.fr proxying on port 80
#
########################################################################
<VirtualHost [::]:80>
CustomLog /var/log/httpd/sites/radiom.fr/stream_access.log combined
ErrorLog /var/log/httpd/sites/radiom.fr/stream_error.log
ServerName live.radiom.fr
SetEnv downgrade-1.0 1
SetEnv force-response-1.0 1
ProxyRequests Off
ProxyPass / http://localhost:8800/
ProxyPassReverse / http://localhost:8800/
ExtFilterDefine fixplaylistport mode=output cmd="/usr/bin/sed -e
's/localhost:8800/live.radiom.fr/g' -e
's/live.radiom.fr:8800/live.radiom.fr/g'"
<Location />
Order allow,deny
Allow from all
ExtFilterOptions LogStdErr Onfail=remove
SetOutputFilter fixplaylistport
</Location>
</VirtualHost>
And it works like a charm, and allows us to benefit from the HTTP 1.1
"Host" header, and use it in a virtual host.
The filter simply rewrites the listening URL served by the Icecast pages
to routable addresses and routable ports.
I would agree this is not the most elegant way to do, but we don't have
a choice here.
Cheers !
Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit
:> On 05/21/2014 10:51 PM, David Hendry wrote:
>> Ezstream is working well locally with Icecast2 on port 8000 on a Debian
Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests
from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2
server.
> The short answer is: don't put Icecast behind a reverse proxy.
>
>> This works fine, i.e. x.mysite.com brings up the Icecast2 Status page.
My problem is with the ezstream xml configuration <url></url>
setting which must have a port number, and if I put
<url>x.mysite.com:8000</url> icecast2 does not get the stream. If I
use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes
straight to Icecast2 and everything works; but I don't want to do it this
way. Do you have any ideas as to what I can do to get ezstream working with
icecast2 and my reverse proxy?
> You are trying to put non-HTTP traffic through a HTTP reverse proxy,
I'm
> not the least surprised that this fails.
> There /might/ be a slim chance to get things working better if you
> switch to Icecast 2.4.0 AND use a source client that uses PUT instead of
> SOURCE. But only if the reverse proxy supports PUT.
>
> Your reverse proxy might still have problems with the long-lived TCP
> connections and other things specific to Icecast.
>
> Cheers
>
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
Hi, On 05/23/2014 09:34 AM, Hoggins! wrote:> Hello, > > Correct me if I'm wrong, but what you get from Icecast *is* HTTP.For a listener, Icecast is just an ordinary HTTP 1.0 server. For a source client Icecast used to be a non-standard extension and used the SOURCE method. We've deprecated this in 2.4.0 and now support PUT. He's trying to connect a source through a reverse proxy.> Anyway, we use proxying because on our server, some of our clients > cannot connect to port 8000 without bypassing their company firewall,The preferred method here is to make icecast bind to port 80.> and we don't have the possibility to add another public IP.That sucks, but is not an Icecast problem, dirty workarounds ensue.> So with > Apache, here is what we do :<snip /> Make sure you have a _high_ number of MaxClients or your Apache will throw a fit after the first few listeners connect and not serve your websites anymore. Also Apache is not that great at handling many long-lived connections. If you really know how to set up an high performance reverse proxy, you won't have to ask how to handle Icecast, everyone else should really avoid this kind of setup.> And it works like a charm, and allows us to benefit from the HTTP 1.1 > "Host" header, and use it in a virtual host. > The filter simply rewrites the listening URL served by the Icecast pages > to routable addresses and routable ports.It will break some features of the web interface, unless you start messing with the replies on the fly. Also your Icecast logs will be mostly worthless.> I would agree this is not the most elegant way to do, but we don't have > a choice here.You have a choice, but decided to accept the trade-off. You always have a choice. Cheers Thomas> > Cheers ! > > Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit : >> On 05/21/2014 10:51 PM, David Hendry wrote: >>> Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server. >> The short answer is: don't put Icecast behind a reverse proxy. >> >>> This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get ezstream working with icecast2 and my reverse proxy? >> You are trying to put non-HTTP traffic through a HTTP reverse proxy, I'm >> not the least surprised that this fails. >> There /might/ be a slim chance to get things working better if you >> switch to Icecast 2.4.0 AND use a source client that uses PUT instead of >> SOURCE. But only if the reverse proxy supports PUT. >> >> Your reverse proxy might still have problems with the long-lived TCP >> connections and other things specific to Icecast. >> >> Cheers >> >> Thomas >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >
Hi, I use a rule in iptables and solves iptables -A PREROUTING -t nat -p tcp -d 192.168.2.32 --dport 80 -j REDIRECT --to-port 8000 iptables-save > /etc/iptables.up.rules echo 'pre-up iptables-restore < /etc/iptables.up.rules' >> /etc/network/interfaces Regards, Rafael Gomes Em 2014-05-23 07:44, Thomas B. R?cker escreveu:> Hi, > > On 05/23/2014 09:34 AM, Hoggins! wrote: >> Hello, >> >> Correct me if I'm wrong, but what you get from Icecast *is* HTTP. > > For a listener, Icecast is just an ordinary HTTP 1.0 server. > For a source client Icecast used to be a non-standard extension and > used > the SOURCE method. We've deprecated this in 2.4.0 and now support PUT. > He's trying to connect a source through a reverse proxy. > >> Anyway, we use proxying because on our server, some of our clients >> cannot connect to port 8000 without bypassing their company firewall, > The preferred method here is to make icecast bind to port 80. > >> and we don't have the possibility to add another public IP. > > That sucks, but is not an Icecast problem, dirty workarounds ensue. > >> So with >> Apache, here is what we do : > <snip /> > Make sure you have a _high_ number of MaxClients or your Apache will > throw a fit after the first few listeners connect and not serve your > websites anymore. > Also Apache is not that great at handling many long-lived connections. > If you really know how to set up an high performance reverse proxy, you > won't have to ask how to handle Icecast, everyone else should really > avoid this kind of setup. > >> And it works like a charm, and allows us to benefit from the HTTP 1.1 >> "Host" header, and use it in a virtual host. >> The filter simply rewrites the listening URL served by the Icecast >> pages >> to routable addresses and routable ports. > > It will break some features of the web interface, unless you start > messing with the replies on the fly. > Also your Icecast logs will be mostly worthless. > >> I would agree this is not the most elegant way to do, but we don't >> have >> a choice here. > > You have a choice, but decided to accept the trade-off. You always have > a choice. > > > Cheers > > Thomas > >> >> Cheers ! >> >> Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit : >>> On 05/21/2014 10:51 PM, David Hendry wrote: >>>> Ezstream is working well locally with Icecast2 on port 8000 on a >>>> Debian Wheezy platform. However, I use a reverse proxy (Pound) to >>>> pass all requests from the Internet for x.mysite.com to backend >>>> localhost:8000 i.e. my Icecast2 server. >>> The short answer is: don't put Icecast behind a reverse proxy. >>> >>>> This works fine, i.e. x.mysite.com brings up the Icecast2 Status >>>> page. My problem is with the ezstream xml configuration <url></url> >>>> setting which must have a port number, and if I put >>>> <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I >>>> use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 >>>> goes straight to Icecast2 and everything works; but I don't want to >>>> do it this way. Do you have any ideas as to what I can do to get >>>> ezstream working with icecast2 and my reverse proxy? >>> You are trying to put non-HTTP traffic through a HTTP reverse proxy, >>> I'm >>> not the least surprised that this fails. >>> There /might/ be a slim chance to get things working better if you >>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead >>> of >>> SOURCE. But only if the reverse proxy supports PUT. >>> >>> Your reverse proxy might still have problems with the long-lived TCP >>> connections and other things specific to Icecast. >>> >>> Cheers >>> >>> Thomas >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >>> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast
Le 23/05/2014 12:44, "Thomas B. R?cker" a ?crit :> Hi, > > On 05/23/2014 09:34 AM, Hoggins! wrote: >> Hello, >> >> Correct me if I'm wrong, but what you get from Icecast *is* HTTP. > For a listener, Icecast is just an ordinary HTTP 1.0 server. > For a source client Icecast used to be a non-standard extension and used > the SOURCE method. We've deprecated this in 2.4.0 and now support PUT. > He's trying to connect a source through a reverse proxy.Sorry, my bad. I should read posts more carefully.> >> Anyway, we use proxying because on our server, some of our clients >> cannot connect to port 8000 without bypassing their company firewall, > The preferred method here is to make icecast bind to port 80.Of course. It's just that this server already has a service on port 80.> >> and we don't have the possibility to add another public IP. > That sucks, but is not an Icecast problem, dirty workarounds ensue.It's true. I never said it was an Icecast problem. This is just a recipe for a dirty workaround.> >> So with >> Apache, here is what we do : > <snip /> > Make sure you have a _high_ number of MaxClients or your Apache will > throw a fit after the first few listeners connect and not serve your > websites anymore. > Also Apache is not that great at handling many long-lived connections. > If you really know how to set up an high performance reverse proxy, you > won't have to ask how to handle Icecast, everyone else should really > avoid this kind of setup.We will, I promise. Right now, adding another public IP to this virtual server is simply not possible, and that is the only solution as port 80 is already bound.> >> And it works like a charm, and allows us to benefit from the HTTP 1.1 >> "Host" header, and use it in a virtual host. >> The filter simply rewrites the listening URL served by the Icecast pages >> to routable addresses and routable ports. > It will break some features of the web interface, unless you start > messing with the replies on the fly. > Also your Icecast logs will be mostly worthless.True here also. It makes me think that I though I had read somewhere that Icecast would correctly interpret the X-Forwarded-For headers, and print the client information accordingly. Here, we only have a bunch of localhost clients.> >> I would agree this is not the most elegant way to do, but we don't have >> a choice here. > You have a choice, but decided to accept the trade-off. You always have > a choice.In our case, more money will allow us to make more choices. Right now, we have neither of them.> > > Cheers > > Thomas > >> Cheers ! >> >> Le 23/05/2014 10:59, "Thomas B. R?cker" a ?crit : >>> On 05/21/2014 10:51 PM, David Hendry wrote: >>>> Ezstream is working well locally with Icecast2 on port 8000 on a Debian Wheezy platform. However, I use a reverse proxy (Pound) to pass all requests from the Internet for x.mysite.com to backend localhost:8000 i.e. my Icecast2 server. >>> The short answer is: don't put Icecast behind a reverse proxy. >>> >>>> This works fine, i.e. x.mysite.com brings up the Icecast2 Status page. My problem is with the ezstream xml configuration <url></url> setting which must have a port number, and if I put <url>x.mysite.com:8000</url> icecast2 does not get the stream. If I use NAT on my router to bypass the reverse proxy, x.mysite.com:8000 goes straight to Icecast2 and everything works; but I don't want to do it this way. Do you have any ideas as to what I can do to get ezstream working with icecast2 and my reverse proxy? >>> You are trying to put non-HTTP traffic through a HTTP reverse proxy, I'm >>> not the least surprised that this fails. >>> There /might/ be a slim chance to get things working better if you >>> switch to Icecast 2.4.0 AND use a source client that uses PUT instead of >>> SOURCE. But only if the reverse proxy supports PUT. >>> >>> Your reverse proxy might still have problems with the long-lived TCP >>> connections and other things specific to Icecast. >>> >>> Cheers >>> >>> Thomas >>> _______________________________________________ >>> Icecast mailing list >>> Icecast at xiph.org >>> http://lists.xiph.org/mailman/listinfo/icecast >>> >> _______________________________________________ >> Icecast mailing list >> Icecast at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >