Vincular encabezados
Objeto de enlace
Tenga en cuenta que cualquier parámetro de enlace puede generarse con valores que utilicen tanto la sintaxis de token como la de cadena citada; por lo tanto, los destinatarios DEBEN ser capaces de analizar ambas formas. En otras palabras, los siguientes parámetros son equivalentes:
La aplicación de enlaces puede optar por ignorar los enlaces con un parámetro de anclaje. Por ejemplo, la aplicación en uso puede no permitir que el contexto del enlace se asigne a un recurso diferente. En tales casos, se debe ignorar todo el enlace; las aplicaciones de enlace NO DEBEN procesar el enlace sin aplicar el ancla.Tenga en cuenta que, dependiendo del código de estado HTTP y de las cabeceras de respuesta, el contexto de enlace podría ser “anónimo” (es decir, no hay ningún contexto de enlace disponible). Por ejemplo, este es el caso de una respuesta 404 a una solicitud GET.3.3. Tipo de relación El tipo de relación de un enlace transmitido en el campo de cabecera Link se transmite en el valor del parámetro “rel”. El parámetro rel DEBE estar presente pero NO DEBE aparecer más de una vez en un valor de enlace dado; las apariciones después de la primera DEBEN ser ignoradas por los analizadores sintácticos.El parámetro rel puede, sin embargo, contener múltiples tipos de relación de enlace. Sin embargo, el parámetro rel puede contener varios tipos de relación de enlace. Cuando esto ocurre, se establecen múltiples enlaces que comparten el mismo contexto, el mismo objetivo y los mismos atributos.El parámetro “rev” se ha utilizado en el pasado para indicar que la semántica de la relación es en sentido inverso. Es decir, un enlace de A a B con REL=”X” expresa la misma relación que un enlace de B a A con REV=”X”. rev está obviado en esta especificación porque a menudo confunde a los autores y lectores; en la mayoría de los casos, es preferible utilizar un tipo de relación independiente.El ABNF para los valores de los parámetros rel y rev es:
Ejemplo de cabecera de enlace
La cabecera de enlace HTTP permite dar metadatos sin tocar realmente el recurso en cuestión, aunque sea una película o una fotografía. Los usos típicos del archivo de metadatos enlazado pueden ser expresar:
Connolly y Hixie en 1999 y por Mark Nottingham y otros más recientemente. La idea es que los parámetros de estilo de la cabecera RDF822 se utilicen de la misma manera que los atributos XML en el HTML <link rel=”…” href=”..”/> excepto el atributo href= que es el argumento principal de la cabecera HTTP. La estandarización y experimentación de la cabecera Link: se haría, por tanto, con la especificación HTML.
El Tabulador implementa esto en su biblioteca ‘AJAR’ RDF AJAX, en el sentido de que cuando una petición de x devuelve una cabecera Link: y; rel=meta, la toma como si tuviera la semántica (en n3) x rdfs:seeAlso y. Esto es lo mismo que la semántica de <link rel=”meta” href=”y”> en el cuerpo del HTML devuelto. En cada caso, si se ha realizado una consulta para x, también se buscará y en la web. (La procedencia del triple no se considera el documento, sino la respuesta HTTP del servidor. El triple no aparecerá como parte de la semántica RDF del documento).
Enlace de la cabeza
Cabeceras HTTPLas cabeceras HTTP permiten al cliente y al servidor pasar información adicional con una petición o respuesta HTTP. Una cabecera HTTP está formada por su nombre, que no distingue entre mayúsculas y minúsculas, seguido de dos puntos (:) y de su valor. Los espacios en blanco antes del valor se ignoran.
Las cabeceras propietarias personalizadas se han utilizado históricamente con un prefijo X-, pero esta convención fue desaprobada en junio de 2012 debido a los inconvenientes que causó cuando los campos no estándar se convirtieron en estándar en el RFC 6648; otros se enumeran en un registro de la IANA, cuyo contenido original se definió en el RFC 4229. IANA también mantiene un registro de nuevas cabeceras HTTP propuestas.
Estas cabeceras deben ser transmitidas al destinatario final del mensaje: el servidor para una petición, o el cliente para una respuesta. Los proxies intermedios deben retransmitir estas cabeceras sin modificarlas y las cachés deben almacenarlas.
Estas cabeceras sólo son significativas para una única conexión a nivel de transporte, y no deben ser retransmitidas por los proxies ni almacenadas en la caché. Tenga en cuenta que sólo se pueden establecer cabeceras hop-by-hop utilizando la cabecera Connection.
Paginación de la cabecera del enlace
La cabecera de enlace HTTP permite dar metadatos sin tocar realmente el recurso en cuestión, aunque sea una película o una fotografía. Los usos típicos del archivo de metadatos enlazado pueden ser expresar:
Connolly y Hixie en 1999 y por Mark Nottingham y otros más recientemente. La idea es que los parámetros de estilo de la cabecera RDF822 se utilicen de la misma manera que los atributos XML en el HTML <link rel=”…” href=”..”/> excepto el atributo href= que es el argumento principal de la cabecera HTTP. La estandarización y experimentación de la cabecera Link: se haría, por tanto, con la especificación HTML.
El Tabulador implementa esto en su biblioteca ‘AJAR’ RDF AJAX, en el sentido de que cuando una petición de x devuelve una cabecera Link: y; rel=meta, la toma como si tuviera la semántica (en n3) x rdfs:seeAlso y. Esto es lo mismo que la semántica de <link rel=”meta” href=”y”> en el cuerpo del HTML devuelto. En cada caso, si se ha realizado una consulta para x, también se buscará y en la web. (La procedencia del triple no se considera el documento, sino la respuesta HTTP del servidor. El triple no aparecerá como parte de la semántica RDF del documento).