[Icecast-dev] icecast2 HEAD method support

[Thomas B. Rücker]

Hi,

On 1/7/19 12:13 PM, Dingyuan Wang wrote:
> 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


I won't comment on the quality of the above, but how about something
like this:

curl -s
"http://stream.example.org:80/status-json.xsl?mount=/source1.ogg" | jq
.icestats.source


It's very simple and 'jq' is an extremely powerful yet simple tool. In
the above example it will either return the mount information specific
JSON *or* 'null' - depending on if the mount is currently running or not.



>
> 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
>>
>

Cheers,


Thomas