Зацикливание видео в CefSharp

Этот вопрос немного устарел, но он все еще появляется в поиске Google, поэтому я решил дать на него ответ. Пожалуйста, будьте нежны, я не профессиональный программист, поэтому, надеюсь, мой ответ будет уточнен или разъяснен кем-то, чей код не читается как мультфильм XKCD.

Прежде всего, ознакомьтесь с этим ответом, который указал мне правильное направление HTML Video не будет зацикливаться -- Вывод таков: если вы перегружаете GetResponseHeaders в своем приложении CEF, вам нужно быть очень осторожным при создании убедительных фальшивых заголовков ответов, иначе видео не будет зацикливаться, и это видно из связанного вопроса. и мои собственные тесты показывают, что зацикливание видео в CEF требует ответа статуса 206 (частичные данные) вместо 200 (ОК).

В моем случае я перенаправлял видеоссылки на локальный видеофайл, упакованный с приложением CEF, с помощью CefShemeHandler. Итак, мне пришлось создать свой собственный общий ответ с помощью GetResponseHeaders, чтобы ответить со статусом 200 OK (из вопроса не ясно, подходит ли это именно для OP, но даже если это не мое решение должно работать). Все работало нормально, кроме зацикливания. Когда я понял, что мне нужно ответить 206, это также означало, что мне нужно добавить несколько дополнительных заголовков.

Несомненно, самый простой способ выяснить, чего ожидал хром в поворотах успешного заголовка ответа, — это просто загрузить его в Chrome (обратите внимание на заявление ОП о том, что страница отлично работала в хроме как обычная веб-страница), откройте консоль, нажмите «Сеть», затем нажмите на название видеофайла, затем нажмите «заголовки». Теперь вы можете точно видеть, какие заголовки Response и Request используются, когда цикл работает успешно.

Самое важное здесь то, что вы увидите, что Chrome инициирует запрос/ответ с полными заголовками в КАЖДОМ цикле, даже если он извлекается из кеша! (вы увидите, что в представлении «Сеть» написано «Из кэша» для каждого цикла, кроме первого). Это означает, что ваша перегрузка GetResponseHeaders должна будет не только предоставлять информацию, имеющую смысл в первом цикле, она будет предоставлять информацию, которая имеет смысл в КАЖДОМ цикле.

Может быть, кто-то, кто лучше разбирается в http, может объяснить нам, какие именно части заголовка абсолютно необходимы, но, поскольку я не был уверен, я просто подделал все, что видел, под заголовками ответа. В моем случае это выглядело так -

  Accept-Ranges:bytes
Content-Length:4470009
Content-Range:bytes 0-4470008/4470009
Content-Type: video/webm .webm
Date:Thu, 23 Jun 2016 04:12:41 GMT
Etag:"****************"
Last-Modified:Fri, 06 May 2016 06:04:57 GMT

Я думаю, что дата Etag и Last-Modified должны быть одинаковыми для всех запросов к одному и тому же файлу, но я не проверял это подробно. В целом, несколько тестов привели меня к мысли, что важными частями были Content-Range и Content-Length. Чтобы получить общее количество байтов, я просто подсчитал байты в своем файле, и мне показалось достаточно просто использовать его для Content-Length и использовать «bytes 0-(contentLength -1)/(contentLength)» для диапазона. Однако это НЕ РАБОТАЕТ!

Возвращаясь к Chrome, я заметил, что после первоначального запроса, как я вставил выше, ответы и запросы стали выглядеть немного иначе. Под заголовком запроса в диапазоне указано «байты = 0-» в первый раз и «байты = 442-» каждый раз (цикл) после этого. Как и следовало ожидать, под заголовком Response диапазон содержимого также выглядел по-разному в циклах, он говорил «байты 442-4470008/4470009», а длина содержимого составляла 4469567, что на 442 байта меньше, чем общее количество.

Поэтому я просто проанализировал строку Range в заголовке запроса, чтобы найти начальную точку, то есть 0 в случае первого цикла и 442 в случае циклов в моем примере, и использовал это для изменения заголовков ответов. Content-Range стал "bytes (startingPoint)-(contentLength -1)/(contentLength)", а Content-Length стал contentLength - startPoint. После этого он зацикливается нормально - как чудо, из локального файла и без пробелов!