headers - ¿Cuál es el propósito del campo de encabezado HTTP "Content-Location"?
http request (4)
Confundido / inspirado por un comentario a mi pregunta ¿Los motores de búsqueda respetan el campo de encabezado HTTP "Ubicación del contenido"? , Me gustaría saber cuál es el objetivo exacto del campo de encabezado Content-Location
en HTTP y cómo se puede usar.
echa un vistazo a RFC2557 en: http://www.faqs.org/rfcs/rfc2557.html para una explicación más profunda si estás interesado. Actualmente estoy escribiendo sobre esto para una clase. Es un poco viejo pero sigue siendo relevante.
Content-Location El encabezado HTTP debe declarar la ubicación única del recurso que se usó para una respuesta a HTTP GET (por ejemplo, la solicitud fue GET /frontpage HTTP/1.1
, el servidor puede agregar encabezado HTTP Content-Location: http://domain.com/frontpage.english.msie-optimized
informando al agente de usuario que si esta respuesta específica es necesaria más tarde, la ubicación provista debe ser utilizada porque la ubicación original puede depender de varias cosas, que luego deben explicarse mediante el encabezado " Vary
") .
Sin embargo, tenga en cuenta que el encabezado HTTP Content-Location es problemático en el uso del mundo real porque diferentes navegadores (agentes de usuario) lo manejan de manera diferente: http://mail.python.org/pipermail/web-sig/2004-October/000985.html
Esto se debe a RFC 2616 sección 14.14 que dice que "El valor de Content-Location también define el URI base para la entidad". En resumen, un agente de usuario responsable calculará la URL BASE para el documento obtenido utilizando el encabezado Content-Location que puede dar como resultado que se usen URLs diferentes si el documento recuperado no define la URL BASE y la URL real y Content-Location difieren lo suficiente (la parte "directorio" / "ruta" de la URL es diferente).
Además, aún no veo ninguna ventaja para usar HTTP Content-Location (una vez esperé que esto se pudiera usar para dar pistas sobre la ubicación permanente de los marcadores en caso de que la URL actualmente vista sea volátil, como domain.com/news/latest pero ese no parece ser el caso).
Mi consejo actual es olvidarse de Content-Location para HTTP, pero puede usarlo para correo electrónico MIME.
Content-Location en HTTP se puede usar cuando un recurso solicitado tiene múltiples representaciones disponibles, por ejemplo, varios idiomas. La selección del recurso devuelto dependerá de los encabezados Aceptar en la solicitud GET original.
Por lo general, la ubicación especificada en el encabezado Content-Location es diferente a la ubicación especificada en el URI de la solicitud original.
No creo que Content_Location tenga un comportamiento definido en respuesta a una solicitud PUT o POST.
La sección 14.14 de RFC 2616 establece:
El campo de encabezado de entidad Content-Location PUEDE utilizarse para proporcionar la ubicación del recurso para la entidad incluida en el mensaje cuando se puede acceder a esa entidad desde una ubicación separada del URI del recurso solicitado ...
Esto se usa en AtomPub (RFC 5023, sección 9.2) :
Si la solicitud de creación contenía un documento de entrada Atom, y la respuesta posterior del servidor contiene un encabezado de ubicación de contenido que coincide con el carácter de encabezado de ubicación por carácter, entonces el cliente está autorizado a interpretar la entidad de respuesta como una representación completa de la entrada recién creada. Sin un encabezado de Content-Location coincidente, el cliente NO DEBE asumir que la entidad devuelta es una representación completa del Recurso creado.