Заголовок довольной длины по сравнению с разделенным на блоки кодированием
Я пытаюсь взвесить за и против установки Content-Length HTTP-заголовок по сравнению с использованием разделенного на блоки кодирования для возврата [возможно] больших файлов из моего сервера. Один или другой необходим, чтобы быть совместимым со спецификациями HTTP 1.1 с помощью постоянных соединений. Я вижу преимущество Content-Length заголовок быть:
- Диалоговые окна загрузки могут показать точный индикатор выполнения
- Клиент знает заранее, если файл не может быть слишком большим, чтобы они поглотили
Оборотная сторона должна вычислить размер перед возвратом объекта, который не всегда практичен и мог добавить к использованию сервера/базы данных. Оборотная сторона разделенного на блоки кодирования является маленькими издержками добавления размера блока перед каждым блоком и индикатором выполнения загрузки. Какие-либо мысли? Какие-либо другие соображения HTTP для обоих методов, что я не мог думать?
2 ответа
Обязательно используйте Content-Length. Использование сервера от этого будет практически нулевым, а выгода для ваших пользователей будет большой.
Для динамического содержимого также довольно просто добавить поддержку сжатых ответов ( gzip ). Для этого требуется буферизация вывода, которая, в свою очередь, дает вам длину содержимого. (нецелесообразно при загрузке файлов или уже сжатом содержимом (звук, изображения)).
Рассмотрите также возможность добавления поддержки частичного контента / обслуживания диапазона байтов, то есть возможности перезапуска загрузок. См. Здесь пример диапазона байтов (пример на PHP, но применим на любом языке). При обслуживании частичного содержимого вам потребуется Content-Length.
Конечно, это не серебряные пули: для потокового мультимедиа бессмысленно использовать буферизацию вывода или размер ответа; для больших файлов буферизация вывода не имеет смысла, но обслуживание Content-Length и байтов имеет большой смысл (возможен перезапуск неудачной загрузки).
Лично я использую Content-Length всякий раз, когда знаю об этом; для загрузки файла проверка размера файла несущественна с точки зрения ресурсов. Результат: у пользователя есть определенный индикатор выполнения (а динамические страницы загружаются быстрее благодаря gzip).
Если длина контента известна заранее, то я определенно предпочитаю его отправку частями. Если есть средства статических файлов в файловой системе локального диска или в базе данных, то любой уважающий себя язык программирования и СУБД предоставляют способы заранее получить длину содержимого. Вы должны использовать это.
С другой стороны, если длина содержимого действительно непредсказуема заранее (например, когда вы намерены заархивировать несколько файлов вместе и отправить их как один), то отправка их частями может быть быстрее, чем буферизация в памяти сервера или запись сначала в файловую систему локального диска. Но это действительно негативно влияет на пользовательский опыт, потому что ход загрузки неизвестен. После этого нетерпеливый может прервать загрузку и продолжить работу.
Еще одно преимущество предварительного знания длины контента - это возможность возобновить загрузку. Из истории ваших сообщений я вижу, что ваш основной язык программирования - Java; вы можете найти здесь статью с дополнительной технической справочной информацией и пример Java Servlet, который делает это.