This allows binary attachment without a more specific content type to be
supported for the enclosure element.
Adding "application/octet-stream" also covers the weird case of servers
sending multiple Content-Type headers, e.g.:
< HTTP/1.1 200 OK
< Server: Apache
< ETag: "
a46d495ba00c35580f83344dd523ece2:
1473631283"
< Last-Modified: Sun, 11 Sep 2016 22:01:22 GMT
< Accept-Ranges: bytes
< Content-Length:
14346711
< Content-Type: audio/mpeg
< Content-Type: application/octet-stream
< content-disposition: attachment
< Date: Mon, 26 Sep 2016 23:36:11 GMT
< Connection: keep-alive
< Content-Type: application/octet-stream
< content-disposition: attachment
In this case the ideal solution would be to use the more _specific_
content type, but CURL just remembers the _last_ one ad it's not really
worth parsing the HTTP headers in tweeper just for this rare scenario.
Reported-by: Torsten Grote
*/
public static function generateEnclosure($url) {
$supported_content_types = array(
*/
public static function generateEnclosure($url) {
$supported_content_types = array(
+ "application/octet-stream",
"application/ogg",
"audio/aac",
"audio/mp4",
"application/ogg",
"audio/aac",
"audio/mp4",