Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Icecast-Server Icecast-Server
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 103
    • Issues 103
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 5
    • Merge requests 5
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Xiph.OrgXiph.Org
  • Icecast-ServerIcecast-Server
  • Issues
  • #738
Closed
Open
Issue created Nov 11, 2005 by robe@robe

Errorcode when client wants to connect to "full" mountpoint should be changed

Hi,

the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same errorcode that gets returned when the requested mountpoint doesn't exist.

A possible solution to this would be returning 403 with a customized reason phrase like "Mountpoint full" (or similar) in the header (since this is the only thing (if any) that gets forwarded to the user with most clients). The HTTP 1.1 RFC (#2616) allows this:

6.1.1:

[..]

The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.

[..]

Edited Oct 24, 2018 by Philipp Schafft
Assignee
Assign to
Time tracking