Okay, that makes sense. To test this, is there a way I can force the content type on the client side, prior to requesting the response entity, via the response object?
On 4/2/11 6:05 AM, Oleg Kalnichevski wrote: > This is a problem with content decoding. > > << "HTTP/1.1 200 OK[\r][\n]" > << "Date: Fri, 01 Apr 2011 14:14:28 GMT[\r][\n]" > << "Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7d[\r][\n]" > << "Last-Modified: Thu, 31 Mar 2011 17:00:05 GMT[\r][\n]" > << "ETag: "4d0e-39932f40"[\r][\n]" > << "Accept-Ranges: bytes[\r][\n]" > << "Content-Length: 19726[\r][\n]" > << "Keep-Alive: timeout=5, max=99[\r][\n]" > << "Connection: Keep-Alive[\r][\n]" > << "Content-Type: application/xml[\r][\n]" > << "[\r][\n]" > << "<?xml version="1.0" encoding="UTF-8"?><!--[\n]" > > The response content is clearly UTF-8 encoded. However the Content-Type > header does not specify a charset. Per HTTP specification if content > charset is not explicitly set in the Content-Type content charset is > assumed to be ISO-8859-1 -- Chad La Joie http://itumi.biz trusted identities, delivered --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
