Какие заголовки ответа HTTP требуются

Question

Какие заголовки ответа HTTP необходимо отправить с сервера на клиент?

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

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

например

Излишне указывать оба Expires а также Cache-Control: max-ageили указать оба Last-Modified а также ETag,

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

Answer 1

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

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

---

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

7.1.1.2. Дата

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

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

7.4.2. сервер

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

3.3.2. Content-Length

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

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

3.1.1.5. Тип содержимого

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

---

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

• Исходный сервер, который не поддерживает постоянные соединения, ДОЛЖЕН отправить Connection: close в каждом ответе, который не имеет кода состояния 1xx.
• Сервер происхождения ДОЛЖЕН генерировать Allow заголовок в ответе 405 (метод не разрешен).
• Сервер происхождения, генерирующий 401 (неавторизованный) ответ, ДОЛЖЕН отправить WWW-Authenticate поле заголовка, содержащее хотя бы одну задачу.

Answer 2

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

• Дата
• Тип содержимого
• сервер

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

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