Какие заголовки HTTP-ответа необходимы

Какие заголовки HTTP-ответа должны быть отправлены с сервера клиенту?

Я работаю над оптимизацией заголовков ответов HTTP, чтобы минимизировать накладные расходы HTTP-ответа. Я знаю, что "накладные расходы" несколько преувеличены, но мне нравится чистый выход.

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

например.

Слишком сложно указывать как Expires, так и Cache-Control: max-age, или указать как Last-Modified, так и ETag.

  • Источник
  • HTTP/1.1: Определения полей заголовка

ОТВЕТЫ

Ответ 1

Это зависит от того, что вы определяете как требуемого: нет полей заголовка, которые должны быть отправлены с каждым ответом независимо от обстоятельств, но есть поля заголовков, которые вы действительно должны отправлять. Единственное заголовочное поле, которое близко, Date, но даже имеет обстоятельства, при которых это не требуется.

В выражении RFC 2119 термин ДОЛЖЕН означает, что что-то является требованием спецификации, а не выполнение этого требования будет недействительным. Нет полей заголовка, определенных RFC 7230, 7231, 7232, 7233, 7234 или 7235, что MUST должен быть отправлен сервером происхождения во всех случаях.

Следующие заголовки, например, могут быть опущены (хотя вы, вероятно, должны их отправить):

7.1.1.2. Дата

Исходный сервер НЕ ДОЛЖЕН отправлять поле заголовка Date, если оно не имеют часы, способные обеспечить разумную аппроксимацию текущий экземпляр в скоординированном универсальном времени. Сервер происхождения MAY отправьте поле заголовка Date, если ответ находится в 1xx (Информационный) или 5xx (серверная ошибка) класса кодов состояния. исходный сервер ДОЛЖЕН отправить поле заголовка Date во всех других случаях.

Обратите внимание на последнее предложение цитаты. Поле заголовка Date MUST должно быть отправлено, если исходный сервер способен обеспечить "разумную аппроксимацию" даты в UTC, но нет ничего, что помешало бы серверу исказить себя.

7.4.2. Сервер

Исходный сервер МОЖЕТ генерировать поле Server в своих ответах.

3.3.2. Content-Length

Помимо [конечного числа предопределенных случаев], в отсутствие Transfer-Encoding, сервер происхождения СЛЕДУЕТ отправить a Content-Lengthзаголовок, когда размер тела полезной нагрузки известен до отправки полная секция заголовка.

В отношении Content-Length и Transfer-Encoding обратите внимание, что ни одно из них не может быть отправлено, и в этом случае длина ответа "определяется количеством октетов, полученных до сервера, закрывающего соединение".

3.1.1.5. Content-Type

Если поле заголовка Content-Type отсутствует, получатель МОЖЕТ либо предположить тип носителя application/octet-stream(RFC2046, раздел 4.5.1) или проанализировать данные для определения его типа.

Существуют обстоятельства, при которых могут потребоваться определенные заголовки, например:

Ответ 2

Это зависит от специфики ответа, но обычно ответ от сервера происхождения должен иметь:

  • Дата
  • Content-Type
  • Сервер

и либо Content-Length, Transfer-Encoding или Connection: close.

Если вы хотите сделать кеширование, добавьте Cache-Control (например, с max-age); Истекает, как правило, не требуется. Если вы хотите, чтобы клиенты могли проверять, добавьте Last-Modified или ETag.