tabla - Qué encabezados de respuesta HTTP se requieren
tabla con header fijo y scroll(horizontal y vertical) (2)
¿Qué encabezados de respuesta HTTP deben enviarse desde el servidor al cliente?
Estoy trabajando para optimizar los encabezados de respuesta HTTP para minimizar la sobrecarga de respuesta HTTP. Sé que la "sobrecarga" es algo exagerada, pero me gusta una salida limpia.
Veo muchos sitios web, que envían encabezados de caché redundantes.
p.ej
Es redundante especificar Expires y Cache-Control: max-age , o especificar Last-Modified y ETag .
- Source
- HTTP / 1.1: Definiciones de campo de encabezado
Depende de lo que defina que se requiere: no hay campos de encabezado que deben enviarse con cada respuesta, independientemente de las circunstancias, pero hay campos de encabezado que realmente debe enviar. El único campo de encabezado que se cierra es Date , pero incluso tiene circunstancias en las que no es necesario.
En el lenguaje de RFC 2119 , el término DEBE significar que algo es un requisito de la especificación y no cumplir con el requisito sería inválido. No hay campos de encabezado definidos por los RFC 7230 , 7231 , 7232 , 7233 , 7234 o 7235 que DEBEN ser enviados por un servidor de origen en todos los casos .
Los siguientes encabezados, por ejemplo, se pueden omitir (aunque probablemente debería enviarlos):
7.1.1.2. Fecha
Un servidor de origen NO DEBE enviar un campo de encabezado de
Datesi no tiene un reloj capaz de proporcionar una aproximación razonable de la instancia actual en el Tiempo Universal Coordinado. Un servidor de origen PUEDE enviar un campo de encabezado deDatesi 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 deDateen todos los demás casos.
Tenga en cuenta la última frase de la cita. El campo del encabezado de la 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 de
Serveren sus respuestas.
3.3.2. Largancia de contenido
Aparte de [un número finito de casos predefinidos], en ausencia de
Transfer-Encoding, un servidor de origen DEBE enviar un campo de encabezado deContent-Lengthcuando se conoce el tamaño del cuerpo de la carga útil antes de enviar la sección de encabezado completa.
Sobre el tema de Content-Length de Content-Length y Transfer-Encoding , tenga en cuenta que no se puede enviar ninguno, en cuyo caso la longitud de la respuesta está "determinada por el número de octetos recibidos antes de que el servidor cierre la conexión".
3.1.1.5. Tipo de contenido
Si un campo de encabezado de
Content-Typeno está presente, el receptor PUEDE asumir un tipo de medio deapplication/octet-stream(RFC2046, Sección 4.5.1) o examinar los datos para determinar su tipo.
Hay circunstancias en las que se pueden requerir encabezados particulares, por ejemplo:
- Un servidor de origen que no admita conexiones persistentes DEBE enviar la
Connection: closeen cada respuesta que no tenga un código de estado 1xx. - Un servidor de origen DEBE generar un encabezado
Allowen una respuesta 405 (Método no permitido). - Un servidor de origen que genere una respuesta 401 (no autorizada) DEBE enviar un campo de encabezado
WWW-Authenticatecontenga al menos un desafío.
Depende de los aspectos específicos 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: close.
Si desea realizar el almacenamiento en caché, agregue Cache-Control (por ejemplo, con max-age); El vencimiento ya no es generalmente necesario. Si desea que los clientes puedan validar, agregue Last-Modified o ETag.