Add crossdomain support in http_remux and hls for HTML5 playback

[xqq]

For flv.js or hls.js HTML5 playback,
CORS header (Access-Control-Allow-Origin) is necessary for ajax stream fetching.

This pull request adds crossdomain on; config support in http_remux and hls block,
which will emit Access-Control-Allow-Origin: * header in http-flv stream or hls m3u8/ts GET request.

CORS header will not affect exisiting service, so it is turned on by default for now.

Changes may be inappropriate, suggestion or modification please!

[winlinvip]

Crossdomain should not be specified through configuration. It can be determined based on the request. If a crossdomain request is made, it should be included in the response. Additionally, the headers should not only include ALLOW ORIGIN, but also specify the allowed methods using ALLOW METHODS. You can refer to the handling of HTTP APIs for guidance.

TRANS_BY_GPT3

[winlinvip]

In addition, if it can be achieved through an HTTP proxy, such as using ORYXY's HTTPLB proxy once, with cross-origin support, it will be much simpler.

TRANS_BY_GPT3

[xqq]

Because OPTIONS is not necessary in normal live streaming scenarios, Allow Methods should be unnecessary.

TRANS_BY_GPT3

[winlinvip]

I made a GET request for http-flv using JavaScript, which should require ALLOW: GET request. Additionally, it seems that JavaScript cannot directly access this type of long connection http-flv. Is there a new standard that supports it?

Access-Control-Request-Headers:content-type
Access-Control-Request-Method:GET
Origin:http://ossrs.net
Referer:http://ossrs.net/srs.release/http-rest/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

HTTP Request Tool:
http://ossrs.net/srs.release/http-rest/

TRANS_BY_GPT3

[winlinvip]

In addition, this belongs to the functionality and will definitely not be added in SRS2. I will include this feature in the develop.

TRANS_BY_GPT3

[winlinvip]

f30b307

I first improved part of the HTTP-API and made changes to conveniently support CORS for HTTP-FLV.

TRANS_BY_GPT3

[winlinvip]

In addition, we are planning to remove HLS RAM as it does not support memory distribution for HLS. It can be achieved using memory disks, which unnecessarily adds a lot of complexity.

TRANS_BY_GPT3

[winlinvip]

Already supported, but I couldn't make it work in chrome54. I guess it's because I'm not using the correct way to initiate the xhr request. You can give it a try, it's added in 3.0.9.

TRANS_BY_GPT3

[xqq]

1. To play a live stream, simply use a GET request without adding the Content-Type header in the request. Therefore, it will not initiate an OPTIONS request, and there is no need for the server to respond with Access-Control-Allow-Methods and Access-Control-Allow-Headers.

2. The xhr standard specification will not add streaming functionality anymore. Currently, the fetch and stream standard APIs support streaming.
   Refer to https://github.com/Bilibili/flv.js/blob/master/src/io/fetch-stream-loader.js
   Fetch+stream is the future trend (although currently only Chrome has fully implemented this), while other browsers are in an incomplete implementation state. However, FireFox can use Mozilla's xhr extension responseType = 'moz-chunked-arraybuffer'.

3. You can directly test HTTP-FLV live streaming using flv.js.

TRANS_BY_GPT3

[winlinvip]

Understood, it's not xhr, it's a new JS API.
So, is the current solution problematic? Do we need to make any modifications?

TRANS_BY_GPT3

[winlinvip]

Long time no response, create a new #798 memo.

TRANS_BY_GPT3

[LF-DevJourney]

When using flv.js to play FLV, there may be a cross-origin issue. To solve this, add w->header()->set("Access-Control-Allow-Origin", "*"); after srs_app_http_stream.cpp to set Access-Control-Allow-Origin. For security reasons, * can be replaced with a specific value.

TRANS_BY_GPT3