Qué encabezados de respuesta HTTP se requieren

¿Qué encabezados de respuesta HTTP se deben enviar desde el servidor al cliente?

Estoy trabajando para optimizar los encabezados de respuesta HTTP para minimizar la sobrecarga de respuesta HTTP. Sé que “sobrecarga” es algo exagerado, pero me gusta una salida limpia.

Veo muchos sitios web, que envía encabezados de caché redundantes.

p.ej

Es redundante especificar Expires y Cache-Control: max-age , o para especificar Last-Modified y ETag .

  • Fuente
  • HTTP / 1.1: Definiciones de campo de encabezado

Depende de lo que defina como obligatorio: no hay campos de encabezado que se deben enviar con cada respuesta, independientemente de las circunstancias, pero hay campos de encabezado que realmente debe enviar. El único campo de encabezado que se acerca es Date , pero incluso tiene circunstancias bajo las cuales no es necesario.

En el lenguaje de RFC 2119 , el término DEBE significa que algo es un requisito de la especificación y no cumplir el requisito sería inválido. No hay campos de encabezado definidos por las RFC 7230 , 7231 , 7232 , 7233 , 7234 o 7235 que DEBEN enviarse por un servidor de origen en todos los casos .


Los siguientes encabezados, por ejemplo, pueden omitirse (aunque probablemente deba enviarlos):

7.1.1.2. Fecha

Un servidor de origen NO DEBE enviar un campo de encabezado Date si no tiene un reloj capaz de proporcionar una aproximación razonable de la instancia actual en Tiempo Universal Coordinado. Un servidor de origen PUEDE enviar un campo de encabezado Date si la respuesta está en la clase de códigos de estado 1xx (Informativo) o 5xx (Error de servidor). Un servidor de origen DEBE enviar un campo de encabezado de Date en todos los demás casos.

Tenga en cuenta la última frase de la cita. El campo del encabezado Date DEBE enviarse si el servidor de origen es capaz de proporcionar una “aproximación razonable” de la fecha en UTC, pero no hay nada que impida que un servidor se tergiverse.

7.4.2. Servidor

Un servidor de origen PUEDE generar un campo Server en sus respuestas.

3.3.2. Largancia de contenido

Además de [un número finito de casos predefinidos], en ausencia de Transfer-Encoding de Transfer-Encoding , un servidor de origen DEBERÍA enviar un campo de encabezado Content-Length cuando se conozca el tamaño del cuerpo de la carga antes de enviar la sección completa del encabezado.

En el tema de Content-Length y Transfer-Encoding , tenga en cuenta que ninguno puede enviarse, en cuyo caso la duración de la respuesta está “determinada por la cantidad de octetos recibidos antes de que el servidor cierre la conexión”.

3.1.1.5. Tipo de contenido

Si un campo de encabezado Content-Type no está presente, el destinatario PUEDE asumir un tipo de medio de application/octet-stream (RFC2046, Sección 4.5.1) o examinar los datos para determinar su tipo.


Hay circunstancias bajo las cuales se pueden requerir encabezados particulares, por ejemplo:

  • Un servidor de origen que no admite conexiones persistentes DEBE enviar la Connection: close en cada respuesta que no tenga un código de estado 1xx.
  • Un servidor de origen DEBE generar un encabezado de Allow en una respuesta 405 (Método no permitido).
  • Un servidor de origen que genera una respuesta 401 (no autorizada) DEBE enviar un campo de encabezado WWW-Authenticate contenga al menos un desafío.

Depende de los detalles de la respuesta, pero en general, una respuesta de un servidor de origen debe tener:

  • Fecha
  • Tipo de contenido
  • Servidor

y ya sea Content-Length, Transfer-Encoding o Connection: cerrar.

Si desea almacenar en caché, agregue Cache-Control (p. Ej., Con max-age); Expira ya no es necesario en general. Si desea que los clientes puedan validar, agregue Last-Modified o ETag.

Intereting Posts