#1 Posted by meb (7 posts) -

The HTTP 'Content-Type' header that is returned when i make requests to the API has 'text/xml' as a value when it should have 'text/xml;charset=utf-8'
 
This seems like a trivial issue, but it really isn't. This can cause some problems for software trying to guess the encoding of the xml file. According to the RFC spec, you're supposed to ignore anything about the encoding that's specified inside the xml file, and instead look at the content-type header. If there is no charset parameter in the content-type header, you're supposed to default to 'us-ascii' instead of 'utf-8'. Kinda problematic if software is up to spec and following the rules.
 
More info here:  http://feedparser.org/docs/character-encoding.html

#2 Posted by andy (427 posts) -

Good catch. I just committed a fix. I'll go live with the next deployment.

Staff
#3 Edited by meb (7 posts) -
@andy said:

" Good catch. I just committed a fix. I'll go live with the next deployment. "

You are awesome, thanks. Another observation - I also noticed that the api's http server doesn't compress anything when i send it the 'accept-encoding: gzip, deflate' http header. A quick Chrome audit says you could be saving 2/3rds bandwidth w/ a quick server configuration change. Add 'text/xml' to gzip_types or something like that (I've never used nginx). Then you can tell your boss you're saving him money! 
 
Thanks again
#4 Posted by ThatFrood (3377 posts) -

thanks meb :)