2012-08-14 18 views
5

Me pregunto si la siguiente idea está funcionando en contra del espíritu y/o carta de HTTP Content Negotiation y HTTP Compression.Negociación/compresión de contenido HTTP: ¿utiliza Base64 con Aceptar codificación/Codificación de contenido?

La situación

El cliente HTTP solicita un recurso:

HTTP GET /image.jpeg HTTP/1.1 
Accept: image/jpeg 

Los rendimientos HTTP Server Este recurso:

HTTP/1.1 200 OK 
Content-Type: image/jpeg 

La idea

El cliente piensa que es una buena idea para solicitar el recurso codificado:

HTTP GET /image.jpeg HTTP/1.1 
Accept: image/jpeg 
Accept-Encoding: base64 

Los honores Server esta solicitud y devuelve el recurso codificada:

HTTP/1.1 200 OK 
Content-Type: image/jpeg 
Content-Encoding: base64 

La pregunta

I No estoy del todo contento con esta idea. La compresión HTTP, para la cual se usan los encabezados Accept-Encoding y Content-Encoding, es aproximadamente que comprime datos, no sobre incrementando su tamaño como lo hace Base64.

¿El uso de base64 como valor para estos encabezados es una violación del espíritu y/o letra de negociación de contenido HTTP y compresión de contenido HTTP?

Respuesta

6

RFC 2616 section 3.5 (el énfasis es mío):

codificaciones de contenido son principalmente utiliza para permitir que un documento sea comprimido o de otra manera útil transformó sin perder la identidad de su tipo de soporte subyacente y sin pérdida de información.

Su idea está perfectamente en línea con el "espíritu y la letra" de HTTP.

Cuestiones relacionadas