¿Cuáles son los problemas asociados al servicio de páginas con contenido: application/xhtml + xml

Question

Recientemente, algunas de mis nuevas páginas web (XHTML 1.1) están configuradas para hacer una expresión regular del encabezado de solicitud Accept y enviar los encabezados de respuesta HTTP correctos si el agente de usuario acepta XML (Firefox y Safari lo hacen).

IE (o cualquier otro navegador que no lo acepte) obtendrá el tipo de contenido simple text/html.

¿El bot de Google (o cualquier otro bot de búsqueda) tendrá algún problema con esto? ¿Hay algún aspecto negativo de mi enfoque que he revisado? ¿Creerías que este detector de encabezado tendría mucho efecto en el rendimiento?

Answer 1

Uso la negociación de contenido para cambiar entre application/xhtml+xml y text/html tal como lo describe, sin notar ningún problema con los robots de búsqueda. Estrictamente, sin embargo, debe tener en cuenta los valores q en el encabezado accept que indica la preferencia del agente de usuario para cada tipo de contenido. Si un agente de usuario prefiere aceptar text/html pero aceptará application/xhtml+xml como alternativa, para mayor seguridad debe tener la página servida como text/html.

Answer 2

El único problema real es que los navegadores mostrarán xml parse errors si su página contiene código no válido, mientras que en text/html mostrarán al menos algo visible.

No hay ningún beneficio de enviar xml a menos que desee incrustar svg o hacer el procesamiento xml de la página.

Answer 3

Un problema con la negociación de contenido (y con la presentación de diferentes contenidos/encabezados para diferentes agentes de usuario) son los servidores proxy. Considerando lo siguiente; Me encontré con esto en los 4 días de Netscape y desde entonces no me gustó nada.

Usuario A descarga su página con Firefox y obtiene un tipo de contenido XHTML/XML. El ISP del usuario tiene un servidor proxy entre el usuario y su sitio, por lo que esta página ahora está en caché.

Usuario B, mismo ISP, solicita su página utilizando Internet Explorer. La solicitud golpea primero al proxy, el proxy dice "hey, tengo esa página, aquí está; como application/xhtml + xml". El usuario B se le pide que descargue el archivo (como IE descargará nada enviados como application/xhtml + xml.

Usted puede conseguir alrededor de este tema en particular mediante el uso de la Vary Header, tal como se describe en este 456 Berea Street artículo. También asumen ese proxy los servidores se han vuelto un poco más inteligentes sobre la detección automática de estas cosas.

Aquí es donde empieza a aparecer CF that is HTML/XHTML. Cuando utiliza la negociación de contenido para servir application/xhtml + xml a un conjunto de user-agents, y text/html a otro conjunto de agentes de usuario, confía en que todos los proxies entre su servidor y sus usuarios se comporten bien.

Par si todos los servidores proxy en el mundo fueran lo suficientemente inteligentes como para reconocer el encabezado Vary (no lo son), todavía tiene que contender con los conserjes de computadora del mundo. Hay muchos profesionales de TI inteligentes, talentosos y dedicados en el mundo. Hay más personas no tan inteligentes que se pasan el día haciendo doble clic en las aplicaciones del instalador y pensando que "Internet" es esa E azul en su menú. Un proxy mal configurado aún podría cachear indebidamente páginas y encabezados, dejándolo sin suerte.

Answer 4

El problema es que debe limitar su marcado a un subconjunto de HTML y XHTML.

• No se pueden utilizar las funciones de XHTML (espacios de nombres, sintaxis de cierre automático en todos los elementos), porque van a romper en HTML (por ejemplo <script/> es sin cerrar a text/html analizador y matará a documentar hasta el próximo </script>).
• No puede utilizar serializador XML, ya que podría romper text/html modo (puede usar XML de sólo características mencionadas en el punto anterior, puede añadir prefijos tagName (PHP DOM veces hace <default:h1>). <script> es CDATA en HTML, pero serializador XML puede dar salida a <script>if (a &amp;&amp; b)</script>).
• No se puede usar la sintaxis compacta de HTML (etiquetas implícitas, comillas opcionales), ya que no se analizará como XML.
• Es arriesgado utilizar herramientas usar HTML (incluyendo la mayoría de los motores de plantilla), debido a que no se preocupan por la buena formación (una sola sin escapar & en href o <br> va a romper por completo XML, y hacer que su sitio aparezca a obra sólo en IE!)

He probado la indexación de mi sitio web solo XML. Se ha indexado a pesar de que he usado application/xml tipo MIME, pero al parecer se analizó como HTML de todos modos (Google no indexó el texto que estaba en las secciones <[CDATA[ ]]>).

Answer 5

Dado que IE no admite xhtml como application/xhtml + xml, la única forma de obtener compatibilidad con navegadores cruzados es usar la negociación de contenido. De acuerdo con Web Devout, la negociación de contenido es difícil debido al uso indebido de comodines donde los navegadores web afirman que admiten todo tipo de contenido existente. Safari y Konquer admiten xhtml, pero solo implican este soporte mediante un comodín, mientras que IE no lo admite, pero también implica soporte.

W3C recommends only sending xhtml to browsers that specifically declare support en el encabezado HTTP Accept e ignorando los navegadores que no declaran específicamente compatibilidad. Sin embargo, tenga en cuenta que los encabezados no siempre son confiables y se sabe que causan problemas con el almacenamiento en caché. Incluso si pudieras hacerlo funcionar, tener que mantener dos versiones similares, pero diferentes sería un dolor.

Teniendo en cuenta todos estos problemas, estoy a favor de dejar de lado xhtml, cuando sus herramientas y bibliotecas le permiten, por supuesto.