Foros del Web » Creando para Internet » Diseño web »

Validador del W3C no aporta encabezado Accept

Estas en el tema de Validador del W3C no aporta encabezado Accept en el foro de Diseño web en Foros del Web. 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 ...
  #1 (permalink)  
Antiguo 04/02/2008, 01:51
Avatar de 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
  #2 (permalink)  
Antiguo 04/02/2008, 09:49
Avatar de j_aroche
Server Ninja
 
Fecha de Ingreso: agosto-2006
Ubicación: iPhone: 14.624481,-90.487457
Mensajes: 2.066
Antigüedad: 17 años, 8 meses
Puntos: 223
Re: Validador del W3C no aporta encabezado Accept

ehmmm, pero lo que pides es una validación nivel del HTTP (el protocolo) no a nivel del lenguaje de marcado (el contenido) que es de lo que se encarga la W3C no?

Mejor dicho, sería mejor tener otro validador para las peticiones y respuestas HTTP, que verifique la negociación de contenidos, expires, etag, cache, content-type y todo lo demás; que integrarlo al validador del lenguaje de marcado, o eso es lo que pienso ;)
__________________
Blog: JavierAroche.com - Twitter: @j_aroche
  #3 (permalink)  
Antiguo 05/02/2008, 00:40
Avatar de 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
Re: Validador del W3C no aporta encabezado Accept

Hola j_aroche

Bueno, primero disculparme porque el mensaje original lo escribí con un poco de prisa y faltaron elementos importantes.

Segundo, disculparme nuevamente porque al arreglarlo hice un mensaje super largo.

Tercero, ya puesto, me disuclpo una vz más, porque al final me distraje y rematé el tema sin plantear la pregunta adecuadamente y aun ahora sigo distraido. Pero en cuanto pueda, lo arreglo.

Sobre lo que mencionas, ciertamente lo podemos ver de esa forma, es decir, como una validación del protocolo, sin embargo, como la detección de navegador es algo común y práctico y en teoría una de las maneras más eficientes es usar sus capacidades y no sus nombres, la detección de dicho encabezado creo que es importante. Básicamente es lo que plantea ahora mismo en la reescritura del tema.

Sobre la idea de tener un validador que analice todos esos elementos de las cabeceras, sería ciertamente interesante.

Personalmente, suelo usar las características de los navegadores para generar determinadas partes de las páginas o enviar determinadas cabeceras. Igualmente, trato de aportar la mayor cantidad de información posible desde mis servidores a fin de facilitar el trabajo de los proxies y navegadores. A lo mejor me apunto a intentar hacer un validador de ese tipo. Se que ya hay códigos por ahí que hacen eso, así que a lo mejor hacerlo yo es una pérdida de tiempo, pero bueno, algo más aprenderé...

;)

Felicidad
__________________
¡ hey, hou, hou, hey !
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 22:12.