Использование заголовка диапазона HTTP с спецификатором диапазона, отличным от байтов?

Основной вопрос заключается в использовании заголовков HTTP, в том числе Range, If-Range, Accept-Ranges и определяемый пользователем спецификатор диапазона.

Вот пример производства, который поможет проиллюстрировать мой вопрос. Предположим, у меня есть приложение стиля Web 2.0, которое отображает какие-то человекочитаемые документы. Эти документы редакционно разбиты на страницы (похожие на статьи, которые вы видите на новостных сайтах). Для этого примера предположим:

Существует документ под названием "HTTP Range Question", разбитый на три страницы.
Страница оболочки (/document/shell/http-range-question) знает метаинформацию о документе, включая количество страниц.
Первая читаемая страница документа загружается во время события загрузки страницы через ajax GET и вставлена на страницу.
Элемент управления пользовательским интерфейсом, который выглядит как [1 2 3 Все], находится внизу страницы, и нажатие на номер отобразит эту читаемую страницу (также загруженную через ajax) и нажав кнопку "Все" отобразит весь документ. Предположим, что эти URLS для 1, 2, 3 и всех вариантов использования:
- /document/content/http-range-question?page=1
- /document/content/http-range-question?page=2
- /document/content/http-range-question?page=3
- /document/content/http-range-question

Теперь на вопрос. Могу ли я использовать заголовки HTTP Range вместо части URL (например, параметр querystring)? Возможно, что-то вроде этого в запросе GET /document/content/http-range-question:

Range: page=1

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

Range: bytes=0-499

Любые мнения или примеры реальных пользовательских спецификаторов диапазона?

Обновление. Я нашел аналогичный вопрос о заголовке Range (Paging в коллекции отдыха), где упоминается, что Dojo JsonRestStore использует собственное значение заголовка диапазона.

Range: items=0-24

Ответ 1

Абсолютно - вы можете указать любые единицы измерения, которые вам нравятся.

Из RFC 2616:

3.12 Единицы диапазона

HTTP/1.1 позволяет клиенту запрашивать что только часть (диапазон)
объект ответа должен быть включен в ответ. HTTP/1.1 использует единицы измерения диапазона в области (раздел 14.35) и Контент-диапазон (раздел 14.16)
заголовков. Сущность может быть нарушена вниз в поддиапазоны в соответствии с различных структурных единиц.
  range-unit       = bytes-unit | other-range-unit
  bytes-unit       = "bytes"
  other-range-unit = token
Единственный диапазон, определенный HTTP/1.1 - это "байты". HTTP/1.1
реализации МОГУТ игнорировать диапазоны с использованием других единиц.

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

Выполнение собственных спецификаторов Range означает, что вы должны иметь контроль над кодом клиента и сервера, который использует этот спецификатор. Итак, если вы владеете частью бэкэнда, которая предоставляет URI "/document/content/http-range-question", вам хорошо идти; предположительно, вы используете современную веб-инфраструктуру, которая позволяет вам проверять входящие заголовки запросов. Затем вы можете посмотреть значения диапазона, чтобы правильно выполнить запрос на резервное копирование.

Кроме того, если вы управляете кодом AJAX, который делает запросы к серверу, вы должны сами установить заголовок диапазона.

Однако есть потенциальный недостаток, который вы ожидаете в своем вопросе: потенциал для выхода из кэширования. Если вы используете настраиваемый блок Range, любые кеши между вашим клиентом и серверами происхождения "МОЖЕТ игнорировать диапазоны, указанные с помощью [единиц, отличных от" байтов "]". Например, если у вас есть кеш Squid/Varnish между фронтом и бэкэнд, нет гарантии, что результаты, на которые вы надеетесь, будут отправлены из кеша!

Вы также можете рассмотреть альтернативную реализацию, где вместо использования строки запроса вы сделаете страницу "параметром" URI; например:/document/content/http-range-question/page/1. Вероятно, это будет немного больше для вас на стороне сервера, но он совместим с HTTP/1.1 и кэшами.

Надеюсь, что это поможет.

Ответ 2

Диапазон HTTP обычно используется для восстановления прерванных загрузок, не начиная с самого начала.

То, что вы пытаетесь сделать, будет лучше обработано OAI-ORE, которое позволяет вам определять отношения между несколькими документами. (альтернативные форматы, компоненты целого и т.д.)

К сожалению, это относительно новый формат метаданных, и я не знаю каких-либо веб-браузеров, которые поставляют с собственной поддержкой.

Ответ 3

байты - это единственный модуль, поддерживаемый спецификацией HTTP 1.1.

Ответ 4

Похоже, вы хотите изменить спецификацию HTTP только для удаления параметра querystring. Для этого вам нужно будет изменить код на клиенте, чтобы отправить измененный заголовок и сервер для чтения из заголовка "Range" вместо запроса.

В конечном итоге это будет работать, но вы нарушаете все стандарты и существующие инструменты для этого.