Hello, Currently sending a HEAD request to an icecast2 server returns a 400. Are there plans to implement HEAD support, in order to simplify server status monitoring for example?
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 -- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20190107/6a6a1f33/attachment.sig>
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
>