[Icecast] Possible CORS issue
Chip
chiapas at aktivix.org
Fri Feb 14 20:46:40 UTC 2020
> ---------- 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.htm>
More information about the Icecast
mailing list