Элтекс

Словил веселый баг, версия софта revB-eltex-1.0.16-b25
Суть - накидал на php генератор плейлистов, отдает xml
В урл можно задавать разные параметры, чтобы получить на выходе разные плейлисты и т.п.
Так вот, если УРЛ плейлиста заканчивается на переменная=значение, то по логам апача и tcpdump видно, что плейлист отдается устройству, но устройство твердит что не смогло его загрузить. Стоит к парамерам приписать &всякая_фигня_без_знака_равно так сразу плейлист грузится без проблем.
Софт вроде крайний.
Примите к сведению.

На revB-eltex-1.0.11-b14 достаточно чтобы в URL был амперсанд.
т.е. http://iptv.server.dom/pl/?t=e не работает
а http://iptv.server.dom/pl/?t=e&someone=something работает
сервер левые параметры ингорирует

Еще один прикол.
после запроса и _успешного получения_ плейлиста по адресу ..../pl/?t=e&h
где "h" - имеющий значение параметр
устройство тут же запрашивает еще раз, только добавив отсебятины: ..../pl/?t=e&h?mac=....
получает от сервера плейлист в неверном формате.
обойти конечно можно: ..../pl/?t=e&h&querty

НО
уважаемые погромисты - научитесь элементарному анализу вводимых данных и адаптации к ним, если в УРЛ уже есть в файловой части знак вопросика, то наверное нужно как-то по другому дополнительные параметры добавлять?

Добрый день!
Для запроса плейлиста используется предопределенный формат строки, ввиде указания URL строки на конечный файл.
Какова практическая ценность в таком запросе что вы приводите?

"Конечный файл" это для слабаков. Сервер отдает плейлист в зависимости от параметров запроса. Кроме Eltex есть другие клиентские устройства, с другим форматом плейлиста. Плюс есть возможность абненту формировать плейлист персонально.
Плодить гору файлов для этого неразумно, не практично и не технологично.
Ну и вообще запрашивающему агенту должно быть все равно, файл там или CGI скрипт с блекждеком и шлюхами.

Если это не баг а фича, тогда конечно... хотя странно.

Как вы и сказали "Сервер отдает плейлист в зависимости от параметров запроса", ничего не мешает серверу анализировать источник запроса, формировать и отдавать верный плейлист, и тут URL строка никак не мешает. И главное если у вас на сети много приставок, просто не разумно и не рационаьлно в каждую вбивать индивидуальный адрес, это просто бесполезная рутина, что приведет к ошибкам и создаст проблемы при централизованном обновлении/управлении.

Т.е. вам виднее как клиент должен работать и наплевать на отраслевые стандарты?
Ваше право.

Нет, именно поддержка стандартов и на основе опытной эксплутации в крупных операторах связи, позволило нам выработать оптимальное решение и применить его в продукте.
Если вас не устраивает какой-либо функционал и есть предложения по доработке, просьба обращаться в коммерческий отдел, где все детально будет рассмотрено.

Ознакомьтесь внимательнее со стандартом описывающим формат URL. Вы противоречите сами себе.

sau писал(а):Нет, именно поддержка стандартов и на основе опытной эксплутации в крупных операторах связи, позволило нам выработать оптимальное решение и применить его в продукте.
Если вас не устраивает какой-либо функционал и есть предложения по доработке, просьба обращаться в коммерческий отдел, где все детально будет рассмотрено.

причем тут коммерческий отдел?

Уважаемый, ShyLion.
Мы не в коем случае не отмахиваемся от багов и замечаний по работе ПО. Обязательно проверим Вашу претензию и устраним, если проблема подтвердится.

P.S. Если Вы являетесь представителем заказчика или нашим прямым заказчиком рекомендую Вам пройти регистрацию в нашей системе поддержки клиентов (регистрация провоизводится через коммерческий отдел-таков порядок). Это будет удобнее и Вам и нам.

Добрый день!

Попробовали воспроизвести данную проблему, ошибок не выявлено. Пробовал задавать в обоих вариантах:

и

загрузка плейлиста выполняется.
Уточните версию IPTV, скорее всего его нужно обновить, можете через наш магазин.

Позже попроверяю еще. Возможно причина была как раз во втором запросе с добавлением к URL плейлиста ?mac...., поскольку он ломал параметры оригинального запроса, сервер возвращал плейлист повторно в неверном формате.