Good morning, On Fri, 2020-02-14 at 22:48 +0000, Chip wrote:> Thanks Marvin. > > On Fri, 14 Feb 2020 at 22:37, Marvin Scholz <epirat07 at gmail.com> wrote: > Does icecast 2.4.4 not have HEAD support ?No, official Icecast does not support HEAD requests as they are largely useless in Icecast context. HEAD requests are meant for cache validation. So they only apply to static files basically. For Icecast, beside a few boring files in web/ the answer to "is my copy still valid" is always "no". So by not supporting HEAD the client will retry with GET. Which... the client would need to do anyway IF we would reply with a positive status code for HEAD. Also (ab)using HEAD for monitoring is hardly useful: The stress to the server is the same for answering a non-stub* response to HEAD than to GET as in both cases the client must be attached to the source. Even a stub response ("endpoint exists" or "not found") would require most steps. It requires finding the endpoint, running its auth and applying its ACLs. That is more than half way thru the attach process. Hope that helps you. :) With best regards, * Non-stub results are hardly useful as HTTP is stateless anyway. The standard acknowledges that by making all information about the actual resource beside its existence optional. -- Philipp. (Rah of PH2)
Good morning On Sat, 15 Feb 2020 at 14:30, Philipp Schafft <lion at lion.leolix.org> wrote:> > No, official Icecast does not support HEAD requests as they are largely > useless in Icecast context. > > HEAD requests are meant for cache validation. So they only apply to > static files basically. For Icecast, beside a few boring files in web/ > the answer to "is my copy still valid" is always "no". So by not > supporting HEAD the client will retry with GET. Which... the client > would need to do anyway IF we would reply with a positive status code > for HEAD. > > Also (ab)using HEAD for monitoring is hardly useful: > The stress to the server is the same for answering a non-stub* response > to HEAD than to GET as in both cases the client must be attached to the > source. Even a stub response ("endpoint exists" or "not found") would > require most steps. It requires finding the endpoint, running its auth > and applying its ACLs. That is more than half way thru the attach > process. > > Hope that helps you. :) > > With best regards, > > * Non-stub results are hardly useful as HTTP is stateless anyway. The > standard acknowledges that by making all information about the actual > resource beside its existence optional. >Unfortunately, I don't yet understand most of that - but I will read and re-read. However using Icecast 2.4.4, is there an alternative method for my client to access status-json.xsl so that they can access "now playing" data? My client is using this for an Alexa skill which can positively respond to questions such as "Alexa, what is now playing on Radio Blah-Blah?" - which sounds pretty cool to me. They could have worked around this by uploading "now playing" data via FTP but status-json.xsl had been working fine previously. For the moment, I've implemented Icecast-KH and my client is happy but I'd like to explore the options using 'official Icecast'. Many thanks for the learning and best regards Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200216/7c60fc71/attachment.html>
Good afternoon, On Sun, 2020-02-16 at 07:58 +0000, Chip wrote:> On Sat, 15 Feb 2020 at 14:30, Philipp Schafft <lion at lion.leolix.org> wrote: > > No, official Icecast does not support HEAD requests as they are largely > > useless in Icecast context. > > > > HEAD requests are meant for cache validation. So they only apply to > > static files basically. For Icecast, beside a few boring files in web/ > > the answer to "is my copy still valid" is always "no". So by not > > supporting HEAD the client will retry with GET. Which... the client > > would need to do anyway IF we would reply with a positive status code > > for HEAD. > > > > Also (ab)using HEAD for monitoring is hardly useful: > > The stress to the server is the same for answering a non-stub* response > > to HEAD than to GET as in both cases the client must be attached to the > > source. Even a stub response ("endpoint exists" or "not found") would > > require most steps. It requires finding the endpoint, running its auth > > and applying its ACLs. That is more than half way thru the attach > > process. > > > > Hope that helps you. :) > > > > With best regards, > > > > * Non-stub results are hardly useful as HTTP is stateless anyway. The > > standard acknowledges that by making all information about the actual > > resource beside its existence optional. > > > > Unfortunately, I don't yet understand most of that - but I will read and > re-read. > > However using Icecast 2.4.4, is there an alternative method for my client > to access status-json.xsl so that they can access "now playing" data?HEAD is not the right method for this anyway. To get the data you must send a GET. HEAD will would never send the actual content of the resource.> My client is using this for an Alexa skill which can positively respond to > questions such as "Alexa, what is now playing on Radio Blah-Blah?" - which > sounds pretty cool to me. They could have worked around this by uploading > "now playing" data via FTP but status-json.xsl had been working fine > previously. > > For the moment, I've implemented Icecast-KH and my client is happy but I'd > like to explore the options using 'official Icecast'.Maybe it would be possible that we arrange a test session on IRC? That way could have a closer look at what is going on and why it doesn't work. I really don't see what the problem could be from what you describe here. With best regards, -- Philipp. (Rah of PH2)