[Icecast-dev] icecast2 HEAD method support

[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

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