http - personalizadas - Aceptar y aceptar el conjunto de caracteres: ¿Cuál es superior?
http request (5)
En primer lugar, Aceptar encabezados puede aceptar parámetros, consulte https://tools.ietf.org/html/rfc7231#section-5.3.2
Todos los tipos de texto / * mime pueden aceptar un parámetro charset. http://www.iana.org/assignments/media-types/media-types.xhtml#text
El encabezado Accept-Charset permite que un agente de usuario especifique los charsets que admite.
Si el encabezado Accept-Charset no existiera, un agente de usuario tendría que especificar cada parámetro charset para cada texto / * tipo de medio que aceptó, por ejemplo
Accept: text/html;charset=US-ASCII, text/html;charset=UTF-8, text/plain;charset=US-ASCII, text/plain;charset=UTF-8
En HTTP, puede especificar en una solicitud que su cliente pueda aceptar contenido específico en respuestas usando el encabezado de accept , con valores como application/xml . La especificación del tipo de contenido le permite incluir parámetros en el tipo de contenido, como charset=utf-8 , lo que indica que puede aceptar contenido con un conjunto de caracteres específico.
También está el encabezado accept-charset , que especifica las codificaciones de caracteres que son aceptadas por el cliente.
Si se especifican ambos encabezados y el encabezado de accept contiene tipos de contenido con el parámetro charset, ¿cuál debe ser considerado el encabezado superior por el servidor?
p.ej:
Accept: application/xml; q=1,
text/plain; charset=ISO-8859-1; q=0.8
Accept-Charset: UTF-8
He enviado algunas solicitudes de ejemplo a varios servidores que utilizan Fiddler para probar cómo responden:
Ejemplos
W3
Solicitud
GET http://www.w3.org/ HTTP/1.1
Host: www.w3.org
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1
Respuesta
Content-Type: text/html; charset=utf-8
Solicitud
GET http://www.google.co.uk/ HTTP/1.1
Host: www.google.co.uk
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1
Respuesta
Content-Type: text/html; charset=ISO-8859-1
Desbordamiento de pila
Solicitud
GET http://stackoverflow.com/ HTTP/1.1
Host: stackoverflow.com
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1
Respuesta
Content-Type: text/html; charset=utf-8
Microsoft
Solicitud
GET http://www.microsoft.com/ HTTP/1.1
Host: www.microsoft.com
Accept: text/html;charset=UTF-8
Accept-Charset: ISO-8859-1
Respuesta
Content-Type: text/html
No parece haber consenso sobre cuál es el comportamiento esperado. Estoy tratando de parecer sorprendido.
Lea RFC 2616 Sección 14.1 y 14.2. El encabezado Accept no le permite especificar un charset . Tienes que usar el encabezado Accept-Charset lugar.
No creo que importe. El cliente está haciendo algo tonto; no es necesario que haya interoperabilidad para eso :-)
Si bien puede configurar el tipo de medio en el encabezado Accept , la definición del parámetro charset para ese tipo de medio no se define en ningún lugar en RFC 2616 (aunque no está prohibido).
Por lo tanto, si va a implementar un servidor compatible con HTTP 1.1, primero deberá buscar el encabezado Accept-charset , y luego buscar sus propios parámetros en el encabezado Accept .
https://tools.ietf.org/html/rfc7231#section-5.3.2 establece claramente:
Cada rango de medios puede ir seguido de cero o más parámetros de tipo de medios aplicables (por ejemplo, conjunto de caracteres)
Por lo tanto, se permite un parámetro charset para cada tipo de contenido. En teoría, un cliente podría aceptar, por ejemplo, text/html solo en UTF-8 y text/plain solo en US-ASCII .
Pero, por lo general, tendría más sentido establecer conjuntos de caracteres posibles en el encabezado Accept-Charset ya que eso se aplica a todos los tipos mencionados en el encabezado Accept .
Si los conjuntos de caracteres de esos encabezados no se superponen, el servidor podría enviar el estado 406 Not Acceptable .
Sin embargo, no esperaría una combinación cruzada elegante de un servidor por varias razones. Haría que el código del servidor fuera más complicado (y, por lo tanto, más propenso a errores), mientras que en la práctica un cliente rarely enviaría tales solicitudes. También hoy en día espero que todo el lado del servidor esté usando UTF-8 y se envíe como está, así que no hay nada que negociar.