Ver Mensaje Individual
  #1 (permalink)  
Antiguo 04/02/2008, 01:51
Avatar de PatomaS
PatomaS
Colaborador
 
Fecha de Ingreso: marzo-2004
Ubicación: En alguna otra parte
Mensajes: 4.656
Antigüedad: 20 años, 1 mes
Puntos: 63
Exclamación Validador del W3C no aporta encabezado Accept

Hola gente

Como el título indica, considero, al igual que otras personas, que el validador debería integrar en su mecánica de petición de páginas la preferencia de versiones que acepta. Es decir, enviar un encabezado Accept a fin de que los sevidores con capacidad de negociación de contenido o las páginas que mediante tecnologías de servidor como perl, php, etc pueden enviar una u otra versión lo hagan correctamente.

Un ejemplo de encabezado Accept:
Código:
.
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
.
Introducción:
Si queremos trabajar con páginas XHTML 1.1 de forma correcta, o integrar otras gramáticas y tecnologías en estos documentos, debemos usar alguno de los mime types correspondientes, siendo el más común el application/xhtml+xml.

Para eso tenemos varias opciones, a saber:
  1. Enviar por defecto el encabezado aplication/xhtml+xml.
  2. Enviar por defecto el encabezado text/html.
  3. Hacer algún tipo de negociación de contenido en el servidor.

Ahora veamos que pasa con esas opciones (asumimos que las páginas están siempre bien hechas desde el punto de vista sintáctico):
1. Si enviamos por defecto este encabezado, las páginas fallarán catastróficamente en los navegadores que no entienden este tipo de documentos, los cuales, son varios, pero el ejemplo más común y también el más extendido, es Internet Explorer 6. A esto hay que decir que ni siquiera para la versión 8 dicen que darán soporte.

2. Si usamos esta opción con documentos xhtml 1.1, estamos incumpliendo las normas. No es ni remotamente tan grave como la opción anterior, pero es importante. Por otro lado, los navegadores no pueden hacer uso del motor de interpretación de xml ni de las reglas del xhtml, con lo que cargan un motor y un conjunto de reglas más grandes y menos optimizados, aumentando el tiempo de renderizado de la página.

3. Esta opción ofrece lo mejor de dos mundos, enviar documentos que siempre funcionan. estrictos para quienes lo piden o soportan y laxos para quienes no saben que hacer con el tipo estricto.

Sin embargo, esta opción tienes al menos dos alternativas:
  1. Por defecto application/xhtml+xml
  2. Por defecto text/html

¿Por qué hay un estado por defecto?. Por varios motivos, entre ellos están que es una excelente forma de programar y segundo porque no sabemos si podemos realmente detectar todos los tipos de petición posibles, por lo tanto, consideramos una mecánica de detección, junto con esta, unas opciones de aceptación de documento y procedemos con ellas.

Ahora veamos que pasa con estas opciones:
1. Si un navegador no envía ningún tipo de accept, le enviaríamos los documentos con este tipo, l ocual, puede ser bueno o no, no lo sabemos. De hecho, volvemos al caso común del Explorer 6. Este navegador, dice aceptar unos pocos tipos de imagen y al final de la cadena, acepta */*, osea todo tipo de documentos. Sin embargo, no entiende application/xhtml+xml, entre otros.

¿es esta una opción eficiente en el mundo real? No desde mi punto de vista.

2. Si un navegador no dice que acepta application/xhtml+xml de forma explícita, no se le envía y se envían encabezados text/html, garantizando que aunque no se cumplan las reglas ni se disfruten de las ventajas, el documento será visible.

Esta opción, en mi opinión, es más que viable.

El problema:
Aunque los encabezados accept son parte del protocolo HTTP, estos pueden ser simulados o mejor dicho, enviados también por lenguajes de servidor como perl y php. Esto, justamente es lo que planteo como pregunta.


Referencias:
  1. XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)
  2. XHTML™ 1.1 - Module-based XHTML - Second Edition
  3. Modularization of XHTML
  4. XHTML™ 1.1 - Module-based XHTML - Second Edition
  5. http://www.ietf.org/rfc/rfc2616.txt - rfc2616
  6. Hypertext Transfer Protocol -- HTTP/1.1 - rfc2616 bis
  7. The 'text/html' Media Type
  8. The 'application/xhtml+xml' Media Type
  9. XHTML
    Media Types

Felicidad
__________________
¡ hey, hou, hou, hey !

Última edición por PatomaS; 04/02/2008 a las 22:09 Razón: Agregar referencias y mejorar contenido