Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Icecast-Server
Icecast-Server
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 102
    • Issues 102
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Packages
    • Packages
    • Container Registry
  • Wiki
    • Wiki
  • External Wiki
    • External Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Xiph.Org
  • Icecast-ServerIcecast-Server
  • Issues
  • #1851

Closed
Open
Opened Dec 10, 2011 by Thomas B. Rücker@tbr😊
  • Report abuse
  • New issue
Report abuse New issue

Should Icecast use $hostname instead of the value from the GET request for replies?

Icecast uses the hostname supplied by the client in HTTP headers for replies. Should it use the hostname set in the config instead?

Target is 2.4.0

after some discussion on IRC:

It is apparent that the current behaviour is well suited as general purpose default. (This e.g. prevents breaking in LAN/NAT/Internet setups or when the server is being accessed on different IPs and or different host names)

I am still of the opinion that there are several cases where being able to optionally override the hostname used in dynamic replies by the one set in the config does make sense.

  • reverse proxies (although not recommended) might access the icecast server by only internally resolving host-names. This would deliver the client a broken generated playlist file.
  • some server admins want to force a single and specific host name to be returned by the server (e.g. to ensure RRDNS, to avoid unauthorized 3rd parties defining FQDN for the server and having the server return that unauthorized FQDN in dynamic playlists)
  • http vs. https scenarios might break things too (e.g. different server/proxy/request-routing per port). listenurl is always http
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
1
Labels
Web
Assign labels
  • View project labels
Reference: xiph/icecast-server#1851