Hi I'm clutching at straws here. I have a user who requires access to a status-json.xsl to publish now playing data for an Alexa skill and this can be accessed via a browser at: - http://example.com:8000/status-json.xsl He says that now his PHP script cannot access the file. I know that Alexa requires *streams* to be served over https but this has previously worked and his skill is curerently failing at accessing the status-json.xsl file. This is successful: curl http://example.com:8000/status-json.xsl But this: curl -I http://example.com:8000/status-json.xsl gives a Bad Request: HTTP/1.0 400 Bad Request I'm wondering if this might be a CORS issue: - https://enable-cors.org/server.html If that is so, what would be the appropriate solution from the above to remedy the problem? With many thanks in advance Chip Scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200213/49e62c14/attachment.html>
On 13 Feb 2020, at 23:44, Chip wrote:> Hi > > I'm clutching at straws here. > > I have a user who requires access to a status-json.xsl to publish now > playing data for an Alexa skill and this can be accessed via a browser at: > > - http://example.com:8000/status-json.xsl > > He says that now his PHP script cannot access the file. > > I know that Alexa requires *streams* to be served over https but this has > previously worked and his skill is curerently failing at accessing the > status-json.xsl file. > > This is successful: > > curl http://example.com:8000/status-json.xsl > > But this: > > curl -I http://example.com:8000/status-json.xsl > > gives a Bad Request: > > HTTP/1.0 400 Bad Request > > I'm wondering if this might be a CORS issue: > > - https://enable-cors.org/server.html >Hi, If they are using a PHP script I fail to see how CORS would involved here as that would be only relevant with JavaScript. The reason curl -I fails is because it does a HEAD request which is not supported.> If that is so, what would be the appropriate solution from the above to > remedy the problem? >You can add additional headers in the Icecast config: <http-headers> <header name="Access-Control-Allow-Origin" value="*" /> </http-headers> See the documentation for more info: http://icecast.org/docs/icecast-2.4.1/config-file.html#global-headers In Icecast 2.5 more advanced CORS handling will be possible.> With many thanks in advance > > Chip Scooter > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast
> ---------- Marvin wrote --------- > From: Marvin Scholz <epirat07 at gmail.com> > Date: Thu, 13 Feb 2020 at 22:51 > > On 13 Feb 2020, at 23:44, Chip wrote: > > > > This is successful: > > > > curl http://example.com:8000/status-json.xsl > > > > But this: > > > > curl -I http://example.com:8000/status-json.xsl > > > > gives a Bad Request: > > > > HTTP/1.0 400 Bad Request > > Hi, > > If they are using a PHP script I fail to see how CORS would involved here > as that would be only relevant with JavaScript. > > The reason curl -I fails is because it does a HEAD request which is not > supported. > > > If that is so, what would be the appropriate solution from the above to > > remedy the problem? > > > > You can add additional headers in the Icecast config: > > <http-headers> > <header name="Access-Control-Allow-Origin" value="*" /> > </http-headers> > > See the documentation for more info: > > http://icecast.org/docs/icecast-2.4.1/config-file.html#global-headers > > In Icecast 2.5 more advanced CORS handling will be possible. >Thanks. Perhaps it's not a CORS issue. I'm drowning and catching hold of anything to try to stay afloat. Forget CORS then. It appears that Icecast might be mangling the headers of the status-json.xslt file. Curiously, if I serve the file over https from another Icecast server, I do not get a 400 Bad Request error: [chip at machine ~]# curl -I https://example2.com:8001/status-json.xsl HTTP/1.0 200 OK Content-Type: application/json Content-Length: 983 Content-Disposition: attachment; filename="file.json" Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Connection: Keep-Alive Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type Access-Control-Allow-Methods: GET, OPTIONS, HEAD The above appears to add some Access-Control elements. Serving over https is actually irrelevant: [chip at machine ~]# curl -I http://example2.com:8000/status-json.xsl HTTP/1.0 200 OK Content-Type: application/json Content-Length: 1010 Content-Disposition: attachment; filename="file.json" Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Connection: Keep-Alive Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type Access-Control-Allow-Methods: GET, OPTIONS, HEAD The second version above works because Icecast is configured differently to the first example - indeed, they're different versions: This doesn't work: [chip at machine]# icecast -v Icecast 2.3.3-kh11-20150225150031 This one works with curl nicely: [chip at machine2]# icecast -v Icecast 2.4.0-kh12-8-gc6e5d83 How easy is it to upgrade Icecast mid-flight on a production server? Can it be done seamlessly or what sort of downtime am I looking at? Many thanks for your help Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200214/7ac99e46/attachment.html>
On 14 Feb 2020, at 21:46, Chip wrote:> > […] > > The second version above works because Icecast is configured > differently to > the first example - indeed, they're different versions: > > This doesn't work: > > [chip at machine]# icecast -v > Icecast 2.3.3-kh11-20150225150031Hi, you are using Icecast-kh, this is quite different from the „normal“ Icecast and we can not offer help for it, as we are no familiar with it. You might want to either switch to the „official“ Icecast or maybe file a bug with the Icecast-kh project instead.> > This one works with curl nicely: > > [chip at machine2]# icecast -v > Icecast 2.4.0-kh12-8-gc6e5d83 >I assume thats probably because Icecast-kh 2.4 might have added HEAD support?> How easy is it to upgrade Icecast mid-flight on a production server? > Can it > be done seamlessly or what sort of downtime am I looking at? >You will eventually need to restart the Icecast server (or rather, stop the „old“ one and start the „new“ one) so there will be a short downtime.> Many thanks for your help > > Chip