Funciones ocultas de HTTP

¿Qué características ocultas de HTTP cree que vale la pena mencionar?

Por características ocultas me refiero a características que ya forman parte del estándar pero que son bastante desconocidas o no se utilizan.

Solo una función por respuesta, por favor.

Tiene que ser el código de estado 418 I'm a teapot , que forma parte del Protocolo de control de cafetera Hyper Text (una extensión de HTTP). Me hace reír cada vez.

2.3.2 418 Soy una tetera

Cualquier intento de preparar café con una tetera debería resultar en el código de error "418 Soy una tetera". El cuerpo de la entidad resultante PUEDE ser corto y robusto.

El hecho de que el remitente estaba mal escrito y se decidió mantener el error ortográfico.

Respuesta obvia: métodos PUT, DELETE, TRACE, OPTIONS, CONNECT

La mayoría de las personas conocen los métodos GET y POST porque eso es lo que usan al crear formularios. Los navegadores también usan mucho HEAD. Los otros métodos son mucho menos conocidos; se utilizan principalmente para aplicaciones más específicas.

¿Alguien ha visto alguna vez el pago 402 requerido ?

204 Sin contenido

Pensé que 204 era solo si no tienes contenido para mostrar, pero la especificación parece que hay un comportamiento adicional de que el agente de usuario "no cambia la vista del documento".

Según HOWTO: Configure Apache para devolver un HTTP 204 (sin contenido) para AJAX

FWIW, Google en realidad hace algo similar. Cada vez que un usuario hace clic en un enlace en sus resultados de búsqueda, Google hace ping a sí mismo para registrar el clic; el código de respuesta del ping es un HTTP 204.

Además, 204 No Content propone que esta es una buena técnica para "errores web" o "balizas" si desea ahorrar hasta el último byte de tráfico de red que pueda.

Código de respuesta410 Gone :

(...) los propietarios de servidores desean que se eliminen los enlaces remotos a ese recurso. (...)

Las arañas web (sobre todo Google) desindexarán (normalmente en el siguiente rastreo) una página que comienza a devolver 410.

En contenido dinámico, use el encabezado Last_Modified o ETag

A veces, tiene contenido dinámico que puede ser grande y / o costoso de generar y que puede no cambiar de una solicitud a otra. Puede agregar un encabezado Last_Modified o ETag a la respuesta generada.

En la parte superior de su costoso código dinámico, puede usar If_Modified_Since o If_None_Match para determinar si el solicitante de contenido que ya tiene todavía está actualizado. Si es así, cambie el estado de respuesta a "304 Sin modificar" y finalice la solicitud.

Algunas tecnologías del lado del servidor proporcionan estas características formalmente, pero puede hacer lo anterior incluso en ASP-Classic humilde.

Tenga en cuenta que esto difiere de la configuración de Cache-Control, expira los encabezados en que garantiza que el cliente siempre tenga la información más reciente a pedido.

Puede solicitar reanudar una respuesta HTTP (grande) (por ejemplo, descarga de archivo) utilizando Rangey If-Rangesolicitar encabezados con el rango de bytes especificado y el identificador de archivo único o la marca de tiempo de modificación del archivo, respectivamente. Esto es posible si el servidor ha enviado los Accept-Ranges: bytesy ETago Last-Modifiedcabeceras de respuesta de la respuesta inicial con, respectivamente, la notificación de que las solicitudes de intervalo de bytes soporte el servidor, el identificador de archivo único y la fecha y hora de modificación del archivo.

La respuesta inicial puede verse así ( ETaggeneralmente se compone de nombre de archivo, tamaño y marca de tiempo de la última modificación):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

Cuando la descarga se cancela, por ejemplo, en 1 KB (1024 bytes), el cliente puede reanudarla de la siguiente manera:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

Que debería devolver esta respuesta con los bytes apropiados en el cuerpo:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

ReST intenta llevar HTTP a sus límites como protocolo de interfaz.

No es una característica oculta , pero al observar las API de ReST bien definidas, uno puede comprender cómo debe funcionar HTTP y encontrar ejemplos maravillosos de lo que se puede lograr con una combinación simple de métodos HTTP, códigos de estado y encabezados para y de un lado a otro.

Tráiler (en contraste con el encabezado)

El protocolo le permite definir sus propios campos personalizados. Estos pueden usarse para transportar otra información si no desea usar cookies para ello.

Estado HTTP 100 (Continuar)

Un cliente puede enviar un mensaje de solicitud con un cuerpo de solicitud para determinar si el servidor de origen está dispuesto a aceptar la solicitud.

En algunos casos, puede ser inapropiado o muy ineficiente que el cliente envíe el cuerpo si el servidor rechaza el mensaje sin mirar el cuerpo.

Podría usarse para evitar el tráfico de clientes deshonestos ... y / o donde el ancho de banda es un bien valioso.

Sin embargo, para el uso completo de esta función, existen algunos criterios para el cliente, servidores y proxies HTTP1.1. Consulte HTTP / 1.1 RFC 2616 para obtener más información sobre las conexiones HTTP.

Códigos de estado :

• Cuando se llama a URI http://www.domain.invalid/index.php?id=44 , si la consulta ( id=44) no puede devolver un recurso, ¿por qué no devolver un código de estado 404?
• Cuando se llama a URI http://www.domain.invalid/index.php?id=foo mientras que idsolo acepta números enteros, ¿por qué no devolver un código de estado 400?
• ¿Por qué, cuando ingresa el nombre de usuario / contraseña incorrecto, casi todas las aplicaciones web devuelven un mensaje como "200 Error de autenticación" con el código de estado (ok, no hay problema, lo hace bien) en lugar de 401?

Sí, los códigos de estado parecen ser una especie de funcionalidad secreta de HTTP para algunos desarrolladores web ... ¡Pero me pregunto si la más oculta de todas las "características" de este protocolo no es su RFC !