SHOUTcast служит его административный интерфейс с точно такой же порт и путь, что и поток. Например, предположим, что у меня есть сервер SHOUTcast, работающий на порту 8000 по адресу 198.51.100.100. Если я иду к следующему в моем браузере ...
http:///198.51.100.100:8000/
... Я буду видеть страницу SHOUTcast администратора, где я могу войти, и падение соединения, а что нет. Однако, если я перейду на тот же URL-адрес с медиаплеером (например, VLC или Winamp), я услышу поток.
SHOUTcast знает, что мне дать на основе заголовка запроса User-Agent. Этот заголовок указывает, какой клиент пытается подключиться к серверу. При подключении с моим браузером, это может выглядеть примерно так:
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Если я связываю с VLC, водосборник User-Agent запроса может выглядеть следующим образом:
NSPlayer/7.10.0.3059
SHOUTcast не имеет списка всех браузеров. Вместо этого он ищет только одно ключевое слово ... Mozilla. Это можно найти в большинстве строк операторов браузеров по историческим причинам. Если Mozilla находится в заголовке запроса User-Agent, тогда SHOUTcast отправляет страницу администратора. Для всех остальных он отправляет поток.
Это создает массу проблем. В частности, это означает, что вы не можете слушать поток в браузере. Если вы загружаете этот поток на веб-страницу, строка User-Agent будет содержать Mozilla, а сервер SHOUTcast отправит страницу администратора, вызывая ошибку с проигрывателем.
Существует способ обойти это. Если на пути запроса вы добавляете точку с запятой ;, SHOUTcast игнорирует фактический User-Agent и заменяет его MPEG OVERRIDE. (Это можно увидеть в журналах сервера SHOUTcast.) Это приводит к тому, что сервер отправляет фактический радиопоток.
Из-за этого обычно встречается точка с запятой ; в пути для потоков SHOUTcast. Но, а как насчет ;stream.mp3? Кто-то сделал это в один прекрасный день, и все остальные скопировали и вставили его. Просто как тот. Сервер SHOUTcast игнорирует все после этой точки с запятой, поэтому вы можете поместить туда, где хотите.
Иногда может быть причина для .mp3. При загрузке через HTTP вы должны быть в состоянии определить, какой тип есть в заголовке ответа Content-Type. «Имя файла» совершенно бессмысленно. Вы можете настроить веб-сервер, чтобы назвать что-то, что угодно, с любым расширением имени файла, и до тех пор, пока вы отправили правильный ответный ответ Content-Type, все хорошо. Однажды, за последние 15 лет, я наткнулся на software that assumed file name extensions were valid and required. Это был очень сложный способ сделать что-то. К счастью, они исправили это, и все было хорошо. Это очень редкая проблема, и вам не о чем беспокоиться.
Теперь, когда SHOUTcast-хаки объясняются ... на другие ваши вопросы.
/stream [Из этого получилось только поток, и все. [Нет никаких ; точка с запятой после/slash и нет потока.mp3?
Те, кто работает на серверах, могут делать все, что захотят. Это обычный HTTP. Пути могут быть любыми. В этом случае кто-то решил назвать все, что там работает /stream. Вероятно, они также не используют SHOUTcast. (Опять же, SHOUTcast является нестандартным и не является нормальным.)
Почему один поток может работать без точки с запятой, и для чего нужен один поток?
Только SHOUTcast требует, чтобы точка с запятой ; работала должным образом. Другие серверы не требуют этого взлома.
http://91.223.18.205:8000/c11_4? [icecast] Почему у этого есть? знак вопроса в конце [и что же это означает?]
вопросительные знаки ? в URL, отделить путь от query string. Строку запроса можно использовать для предоставления списка параметров, обычно для скрипта на пути. В этом случае знак вопроса не имеет значения, поскольку после него нет параметров.
Старый IE (4, я думаю), используемый для чрезмерного кеширования вещей, но часто бы не возникало, если бы была строка запроса. Иногда люди добавляли строки запроса со случайным числом, чтобы гарантировать, что они получили новую копию с сервера. Это хак, который не нужен в течение очень долгого времени. IE 4 вышел почти 20 лет назад. В наши дни мы используем правильные заголовки кеша. SHOUTcast, Icecast и другие, все делают это правильно.
Печально существующие браузеры игнорируют правильные заголовки HTTP из-за того, что я назвал бы «лазейкой» в RFC. Поэтому, к сожалению, использование строки запроса с четными случайными данными для обеспечения чистой перезагрузки может оказаться необходимым. – TBR
@TBR Можете ли вы рассказать о проблемах с кешированием, с которыми столкнулись? У меня не было никаких проблем за долгое время. – Brad
Именно поэтому для того, чтобы ссылка icecast работала в jwplayer, знак вопроса требуется в конце ссылки? http://91.223.18.205:8000/c11_4? , Который отличается от крика, который требует косой черты; с точкой с запятой. –