Respuestas:
La diferencia entre text / xml y application / xml es la codificación de caracteres predeterminada si se omite el parámetro charset :
Text / xml y application / xml se comportan de manera diferente cuando el parámetro charset no se especifica explícitamente. Si el juego de caracteres predeterminado (es decir, US-ASCII) para text / xml es inconveniente por alguna razón (p. Ej., Servidores web defectuosos), application / xml ofrece una alternativa (consulte "Parámetros opcionales" del registro de la aplicación / xml en la Sección 3.2).
Para texto / xml :
De conformidad con [RFC2046], si se recibe una entidad text / xml con el parámetro charset omitido, los procesadores MIME y los procesadores XML DEBEN usar el valor de charset predeterminado de "us-ascii" [ASCII]. En los casos en que la entidad XML MIME se transmite a través de HTTP, el valor predeterminado del juego de caracteres sigue siendo "us-ascii".
Para la aplicación / xml :
Si se recibe una entidad de aplicación / xml donde se omite el parámetro charset, el encabezado MIME Content-Type no proporciona información sobre el charset. Los procesadores XML conformes DEBEN seguir los requisitos de la sección 4.3.3 de [XML] que abordan directamente esta contingencia. Sin embargo, los procesadores MIME que no son procesadores XML NO DEBEN asumir un conjunto de caracteres predeterminado si el parámetro de conjunto de caracteres se omite de una aplicación / entidad xml.
Por lo tanto, si se omite el parámetro charset , la codificación de caracteres de text / xml es US-ASCII, mientras que con application / xml la codificación de caracteres se puede especificar en el documento mismo.
Ahora, una regla general en Internet es: "Sea estricto con la salida pero sea tolerante con la entrada". Eso significa asegurarse de cumplir con los estándares tanto como sea posible al entregar datos a través de Internet. Pero incorpore algunos mecanismos para pasar por alto las fallas o adivinar al recibir e interpretar datos a través de Internet.
Así, en su caso sólo debes elegir uno de los dos tipos (recomiendo application / xml ) y asegúrese de especificar el carácter utiliza la codificación adecuada (recomiendo utilizar la respectiva codificación de caracteres por defecto ir a lo seguro, por lo que en caso de aplicación / xml uso UTF-8 o UTF-16).
Como regla general, la apuesta más segura para que su documento sea tratado adecuadamente por todos los servidores web, servidores proxy y navegadores de clientes es probablemente la siguiente:
En términos de la especificación RFC 3023 , que algunos navegadores no pueden implementar correctamente, la principal diferencia en los tipos de contenido está en cómo se supone que los clientes deben tratar la codificación de caracteres, de la siguiente manera:
Para application / xml, application / xml-dtd, application / xml-external-parsed-entity, o cualquiera de los subtipos de application / xml como application / atom + xml, application / rss + xml o application / rdf + xml , la codificación de caracteres se determina en este orden:
Para text / xml, text / xml-external-parsed-entity, o un subtipo como text / foo + xml, se ignora el atributo de codificación de la declaración XML dentro del documento, y la codificación de caracteres es:
La mayoría de los analizadores no implementan la especificación; ignoran el tipo de contexto HTTP y solo usan la codificación en el documento. Con tantos documentos mal formados, es poco probable que cambie en el corto plazo.
Ambos están bien.
text / xxx significa que en caso de que el programa no entienda xxx, tiene sentido mostrar el archivo al usuario como texto sin formato. application / xxx significa que no tiene sentido mostrarlo.
Tenga en cuenta que esos tipos de contenido se definieron originalmente para el archivo adjunto de correo electrónico antes de que luego se usaran en el mundo web.
text / xml es para documentos que serían significativos para un humano si se presentaran como texto sin procesamiento adicional, application / xml es para todo lo demás
Cada entidad XML es adecuada para su uso con el tipo de medio de aplicación / xml sin modificación. Pero esto no explota el hecho de que XML puede tratarse como texto sin formato en muchos casos. Los agentes de usuario MIME (y los agentes de usuario web) que no tienen soporte explícito para application / xml lo tratarán como application / octet-stream, por ejemplo, ofreciendo guardarlo en un archivo.
Para indicar que una entidad XML debe tratarse como texto sin formato de forma predeterminada, use el tipo de medio text / xml. Esto restringe la codificación utilizada en la entidad XML a aquellos que son compatibles con los requisitos para los tipos de medios de texto como se describe en [RFC-2045] y [RFC-2046], por ejemplo, UTF-8, pero no UTF-16 (excepto HTTP).
text/htmlha existido por mucho tiempo, y fue un poco tarde para cambiarlo.
Otras respuestas aquí abordan la cuestión general de lo que el adecuado Content-Typepara una respuesta XML es, y llegan a la conclusión (como con cuál es la diferencia entre el texto / xml vs application / xml de respuesta de servicio web ) que tanto text/xmly application/xmlson permisibles. Sin embargo, ninguno aborda si hay reglas específicas para los sitemaps .
Respuesta: no hay. La especificación del mapa del sitio es https://www.sitemaps.org , y con las site:búsquedas de Google puede confirmar que no contiene las palabras o frases mime , mimetype , content-type , application / xml o text / xml en ningún lado. En otras palabras, es completamente silencioso sobre el tema de lo Content-Typeque se debe utilizar para servir mapas del sitio.
En ausencia de algún comentario en la especificación del mapa del sitio que aborde directamente esta pregunta, podemos asumir con seguridad que se aplican las mismas reglas que al elegir Content-Typecualquier otro documento XML, es decir, que puede ser text/xmlo application/xml.
text/htmly el tipo MIME XHTML preferido seaapplication/xhtml+xml.