Заголовок Content-Range - разрешенные единицы?

Question

Это связано с: Как мне реализовать глагол COUNT в моем веб-сервисе RESTful? , Пейджинг в коллекции отдыха и Использование заголовка диапазона HTTP с указателем диапазона, отличным от байтов?

На самом деле я думаю, что рейтинг -1 здесь правильный https://stackoverflow.com/a/1434701/1237617

Как правило, anwsers говорят, что вы можете использовать пользовательские юниты, ссылаясь на сек 3.12

  range-unit       = bytes-unit | other-range-unit
  bytes-unit       = "bytes"
  other-range-unit = token

Однако, когда вы читаете спецификацию HTTP, обратите внимание, что производственные правила таковы:

   Content-Range = "Content-Range" ":" content-range-spec
   content-range-spec      = byte-content-range-spec
   byte-content-range-spec = bytes-unit SP
                             byte-range-resp-spec "/"
                             ( instance-length | "*" )

Спецификация заголовка ссылается только на единицу измерения байтов из раздела 3.12, а не на единицы измерения дальности, поэтому я думаю, что на самом деле использование здесь специальных единиц измерения противоречит спецификации.

Я что-то упустил или популярный ответ не так?

РЕДАКТИРОВАТЬ: Поскольку это, вероятно, не ясно, суть моего вопроса: rfc2616 sec14.16 только ссылается на единицу байта. В нем никогда не упоминается единица измерения диапазона, поэтому производство единиц измерения измерения не относится к Content-Range, и поэтому могут использоваться только байтовые единицы измерения.

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

Это отражает тот факт, что, по-видимому, первый набор правил грамматики был специально создан для синтаксического анализа, а второй - для генерации HTTP-запросов

благодаря Элгатону

Answer 1

Спецификация, в пересмотренном виде, позволяет настраивать единицы измерения. См. HTTPbis Часть 5, Раздел 2 .

Answer 2

Если вы прочитаете HTTP / 1.1 RFC, раздел 3.12 , вы увидите, что:

Единственная единица измерения диапазона, определенная в HTTP / 1.1, - это "байты".Реализации HTTP / 1.1 МОГУТ игнорировать диапазоны, указанные с использованием других модулей.

Итак, токен other-range-unit введен только для того, чтобы сделать серверы более «либеральными» при принятии.Это отражает тот факт, что, по-видимому, первый набор правил грамматики был специально создан для синтаксического анализа, а второй - для создания HTTP-запросов, чтобы серверы могли принимать даже недопустимые запросы (они будут просто игнорироваться), а клиенты использовали бы толькообщепринятая единица bytes.

Поэтому я лично рекомендую:

1. использовать только единицу bytes при работе в качестве клиента и
2. принимать другие единицы (отбрасывая заголовок Content-Range, если они недействительны) при работе в качестве сервера.

Answer 3

Это сугубо личное мнение, но я думаю, что оно вполне соответствует тому, как используются другие расширения HTTP (пользовательские методы или заголовки). Вот как я это прочитал: Да, я могу использовать настраиваемые единицы измерения диапазона, и нет, я не должен отправлять отчет об ошибках, когда он игнорируется при прохождении через брандмауэры, веб-прокси и другие посредники. Я отвечаю спецификации HTTP при отправке, а они соответствуют HTTP, когда игнорируют ее. WebDAV правильно использует расширения HTTP, IMO, но редко работает по Интернету именно по этой причине. Как я уже сказал, только личное мнение.

Answer 4

Очевидно, можно использовать пользовательские единицы, потому что:

Это отражает тот факт, что, по-видимому, первый набор грамматики правила были специально сделаны для разбора и второй для выдача HTTP-запросов