Hi, I noticed two problems related to images: Some websites seems to send images with a charset set in the header, e.g: Content-Type: image/jpeg;charset=ISO-8859-1 In that case dillo seems to decode the data resulting in: Not a JPEG file: starts with 0xc3 0xbf Not sure whether we can/want to do anything about that. I don't understand the other problem: http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg loads and displays fine. from html however it doesn't work <img src="http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg" /> Cheers, Johannes
Johannes wrote:
I noticed two problems related to images:
Some websites seems to send images with a charset set in the header, e.g: Content-Type: image/jpeg;charset=ISO-8859-1 In that case dillo seems to decode the data resulting in: Not a JPEG file: starts with 0xc3 0xbf Not sure whether we can/want to do anything about that.
It seems like it would make sense to restrict decoding to text/*. I'll look in the rfc to see whether it says something relevant. It might be good to have text decoded outside of cache to UTF-8 in the same way that images are decoded outside of cache to RGB. (Right now that would be a problem with view src using getbuf, and perhaps for text/css following @charset="..." eventually, but still it would be nice to have one way of doing things.) Speaking of the rfc, I noticed just recently that it says "The value of Content-Location also defines the base URI for the entity." and I wonder whether that's ever a problem in practice because dillo makes no use of this header.
I don't understand the other problem: http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg loads and displays fine. from html however it doesn't work <img src="http://sz-magazin.sueddeutsche.de/upl/images/user/8059/17337.jpg" />
When you load it by itself, dillo follows the redirection to http://szmimg.sueddeutsche.de/upl/images/user/8059/17337.jpg
I wrote:
Johannes wrote:
Some websites seems to send images with a charset set in the header, e.g: Content-Type: image/jpeg;charset=ISO-8859-1 In that case dillo seems to decode the data resulting in: Not a JPEG file: starts with 0xc3 0xbf Not sure whether we can/want to do anything about that.
It seems like it would make sense to restrict decoding to text/*. I'll look in the rfc to see whether it says something relevant.
Fix committed. RFC 2046 defines a charset parameter for text/* (and it's also mentioned in the RFCs for text/html and text/css media types). Nothing mentions any parameters defined for image/*, or for the specific image types that dillo displays. Interestingly, I learned of RFC 5147, which is a proposed standard involving URI fragments and text/plain: http://tools.ietf.org/html/rfc5147#section-5
participants (2)
-
corvid@lavabit.com
-
Johannes.Hofmann@gmx.de