[Icecast-dev] icecast2 HEAD method support

[Dingyuan Wang]

I need to monitor individual stream availability, and parsing XMLs is 
too much complex.

Currently I use:

curl -s --max-time 1 -w '%{http_code}' -o /dev/null 
http://somehost/stream.mp3 | grep -q 200

2019/1/7 17:19, Philipp Schafft:
> Good morning,
> 
> On Mon, 2019-01-07 at 15:17 +0800, Dingyuan Wang wrote:
>> Hello,
>>
>> Currently sending a HEAD request to an icecast2 server returns a 400.
> 
> Yes. This is correct for both 2.4.x and 2.5.x.
> 
> 
>> Are there plans to implement HEAD support, in order to simplify server
>> status monitoring for example?
> 
> There is some discussion on it. Both on IRC as well as on the ticket
> system. See e.g. here:
> https://gitlab.xiph.org/xiph/icecast-server/issues/2223
> 
> 
> Beside that HEAD would be nice for status checking HEAD has two big
> disadvantages in reality:
>        * People often argue that it would be less stress for the server
>          to answer a HEAD request on a sourced mountpoint than a GET
>          request. This is not exactly true. What causes most stress to
>          the server is attaching the client to the source. This is needed
>          in both cases.
>        * Because of the stateless nature of HTTP the response to a HEAD
>          request can become invalid even before it reached the client. So
>          the use of HEAD is very limited. Cache validation and server
>          monitoring are the only use cases I know of. The problem however
>          is that people often try to use it to find out about the
>          resource itself. E.g. it has been seen in the wild that people
>          try to use it to find out about the resource's size or
>          content-type to detect which part of their software should do
>          the GET request. This is invalid as per HTTP specs as well as
>          totally broken with anything but perfectly static files. The
>          correct solution for this is that software MUST NOT depend on
>          HEAD request (or the also often seen double-GET pattern).
> 
> While HEAD would be nice for checking the status of a stream it could
> get people into a sphere of implementing broken clients. This is why it
> has not yet been done. There is discussion on if it might be useful to
> implement HEAD without any source related data. Which would allow status
> checking but nothing else. There is also discussion on other
> alternatives:
>        * OPTIONS requests (maybe even OPTIONS requests to the *-resource)
>          (both implemented in current master/2.5.x),
>        * GET request with zero size byte range (someone want to test this
>          with me and document the results?),
>        * Using the old or new admin interface to query for the status of
>          a resource,
>        * Using the STATS interface to get *live* updates on the server's
>          status,
>        * Using events/URL auth to run code in case of a status change.
> 
> What is the best solution depends on your specific use case. I tried to
> answer as general as "HEAD request support".
> 
> I hope my answer will help you. Feel free to join us on IRC[0] or ask
> again here on the list about your specific problem so we can find a
> specific solution that works best for you.
> 
> 
> With best regards,
> 
> [0] #icecast on freenode, see https://icecast.org/contact/#contact-info
>