ArtyShock пишет:К тому что кроме заголовков прокладкой придется запрашивать и сами данные (часть их) и переотдавать их клиенту выше приведённая функция всё это уже делает.
Прокомментирую логику, чтобы стало ясно.
1. Получаем заголовки от клиента
2. Открываем поток с нужными опциями (заголовки и.д.)
3. Читаем/отдаём полученные заголовки
4. Читаем файл в контексте этого потока
и отдаём клиенту.
Чтение файла происходит с нужной позиции, т.к. уже передали необходимые заголовки (Range).
Потому для поддержания функционала перемотки/переходов и требуется гонять туда-сюда заголовки.
Когда мы кликаем по time line плеера, чтобы промотать ролик, выполняется запрос браузером к серверу, который отдаёт видео-файл с позиции, указанной в Range.
Ведь, по сути, происходит неявное скачивание файла при просмотре видео в браузере.
Соответственно нам надо всё это дело обработать в "прокладке" и вернуть то, что запросил клиент (браузер).
А так как мы уже указали в первых заголовках тип контента, то браузер начал работать с "прокладкой" как с видео-контентом.
Всё.
ArtyShock пишет:Но изначально задача прокладки была кроме этого в том что бы обмануть клиента который слишком часто запрашивает и эмулировать ему ответы сервера так как хочет клиент, а у самого сервера запрашивать данные не так часто
У плеера есть буферизация.(Отредактировано автором: 29 Июня, 2015 - 05:36:31)
|