login about faq

It always has double quotes in charset, even using the SetRequestHeader For example, Content-Type: text/xml; charset="utf-8"

It causes some issues when calling the Microsoft web service, For example, ---- Received ---- HTTP/1.1 415 Cannot process the message because the content type 'text/xml; charset="utf-8"' was not the expected type 'text/xml; charset=utf-8'. Cache-Control: private Server: Microsoft-IIS/7.5 RequestId: c2ee717c-e608-4ac0-a8f7-2191293be87f X-AspNet-Version: 2.0.50727

According to the http spec, it seems no "double quotes" in Content-Type charset field

asked Feb 04 '13 at 12:06

Eric%20Smalltalk's gravatar image

Eric Smalltalk

The Chilkat.HttpRequest object has a "SendCharset" boolean property that may be set to true/false. It defaults to true. Set it equal to false (0) if you don't want the charset attribute added to the Content-Type header field.


answered Feb 04 '13 at 12:14

chilkat's gravatar image

chilkat ♦♦

The problem is it requires the Content-Type header and charset attribute. As the Microsoft service response, it thinks charset="utf-8" is different from the chraset=utf-8

Adding custom header, ckhttp automatically adds double quotes to the charset attribute even my custom header does NOT add it.

(Feb 05 '13 at 07:41) Eric Smalltalk

Make sure you are testing with the latest version of Chilkat (v9.4.0). Also, please post the contents of the LastErrorText for the method call that sends the request, assuming the issue appears using the latest version. Please make sure to use "pre" tags, as described in the right side-bar of this Forum when posting the LastErrorText.

(Feb 05 '13 at 09:22) chilkat ♦♦

We already add custom header manually without using the SendCharset or ContentType VC 2008 with Chilkat 9.4.0

    req.AddHeader("Content-Type", "text/xml; charset=utf-8");

The header sent and response received shown below. Always extra double quotes add in charset attribute. The response clearly stating the error.

---- Sending ----
POST /Autodiscover/Autodiscover.xml HTTP/1.1
User-Agent: ExchangeServicesClient/15.00.0516.014
Content-Type: text/xml; charset="utf-8"
Host: autodiscover-s.outlook.com
Authorization: Basic GZzb2Z0Lm9ubWljcm9zb2Z0LmNvbTpuZW83NjVFeCE=
Content-Length: 1153

---- skip -----

---- Received ----
HTTP/1.1 415 Cannot process the message because the content type 'text/xml; charset="utf-8"' was not the expected type 'text/xml; charset=utf-8'.
Cache-Control: private
Server: Microsoft-IIS/7.5
RequestId: 7436fb51-200f-4f1b-9197-f1579fe9ed5e
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
X-DiagInfo: HKXPRD0210CA016
Date: Tue, 05 Feb 2013 17:58:37 GMT
Content-Length: 0

Testing with WinInet with

Content-Type: text/xml; charset=utf-8
wlll get sucess response


answered Feb 05 '13 at 13:08

Eric%20Smalltalk's gravatar image

Eric Smalltalk

You forgot to post the contents of the LastErrorText...

(Feb 05 '13 at 13:38) chilkat ♦♦

There is no error when sending the request. We list the lastHeader ( in the sending section) instead. The request can be sent to the web service but 415 response code due to

 Cannot process the message because the content type 'text/xml; charset="utf-8"' was not the expected type 'text/xml; charset=utf-8'.

(Feb 05 '13 at 13:44) Eric Smalltalk

It doesn't matter. The LastErrorText will always contain information about what happened regardless of success or failure.

(Feb 05 '13 at 13:46) chilkat ♦♦

The problem is just ckhttp always adds " to wrap the charset value. It shall be utf-8 instead of "utf-8"

Content-Type: text/xml; charset=utf-8

Rather than

Content-Type: text/xml; charset="utf-8"

any option to avoid such behaviour

(Feb 05 '13 at 13:47) Eric Smalltalk

The reason I ask for a LastErrorText is to verify that you are in fact actually using the latest version. I've already tested in trying to produce the charset="utf-8" with quotes, but I don't get the same behavior. I quite often waste time investigating when a user thinks he's using the latest version but actually isn't. Therefore, I want to quickly verify that you aren't wasting my time. Like I've said, I already tested and do not get the same results. If you verify to me that you're using the latest version, then I'll investigate more deeply and spend more time on it.

(Feb 05 '13 at 17:44) chilkat ♦♦
Content-Type: text/xml; charset="utf-8"

charset with double quote works fine in most web service However, it fails on this autodiscover-s.outlook.com microsoft web service

(Feb 06 '13 at 02:26) Eric Smalltalk
showing 5 of 6 show all

The last error log:



DllDate: Dec 12 2012

UnlockPrefix: XEXSXHttp

Username: ASUSLAPTOP:eric

Architecture: Little Endian; 32-bit

Language: Visual C++ 9.0

VerboseLogging: 0

domain: autodiscover-s.outlook.com

port: 443

ssl: 1


HttpVersion: 1.1

Verb: POST

Path: /Autodiscover/Autodiscover.xml

Charset: utf-8

SendCharset: 0

MimeHeader: User-Agent: ExchangeServicesClient/15.00.0516.014

Content-Type: text/xml; charset="utf-8"


ReadTimeout: 20

ConnectTimeout: 10


hostname: autodiscover-s.outlook.com

port: 443

ssl: 1

Need to establish connection to the HTTP server...

ConnectTimeoutMs_1: 10000

calling ConnectSocket2

IPV6 enabled connect with NO heartbeat.

connectingTo: autodiscover-s.outlook.com


dnsCacheLookup: autodiscover-s.outlook.com

Resolving domain name (IPV4)


GetHostByNameHB_ipv4: Elapsed time: 0 millisec


myPort_1: 51687

connect successful (1)

clientHelloMajorMinorVersion: 3.1


majorVersion: 3

minorVersion: 1

numRandomBytes: 32

sessionIdSize: 0

numCipherSuites: 10

numCompressionMethods: 1





handshakeMessageType: ServerHello

handshakeMessageLen: 0x46


MessageType: ServerHello

Processing ServerHello...


MajorVersion: 3

MinorVersion: 1

SessionIdLen: 32

CipherSuite: RSA_WITH_RC4_128_MD5

CipherSuite: 00,04

CompressionMethod: 0

Queueing ServerHello message.

ServerHello is OK.



handshakeMessageType: Certificate

handshakeMessageLen: 0x1447


MessageType: Certificate



derSize: 1709

certSubjectCN: outlook.com

certSerial: 4E10E630000800027CC3

certIssuerCN: Microsoft Secure Server Authority



derSize: 1559

certSubjectCN: Microsoft Secure Server Authority

certSerial: 61033336000500000030

certIssuerCN: Microsoft Internet Authority



derSize: 1302

certSubjectCN: Microsoft Internet Authority

certSerial: 07276202

certIssuerCN: GTE CyberTrust Global Root



derSize: 606

certSubjectCN: GTE CyberTrust Global Root

certSerial: 01A5

certIssuerCN: GTE CyberTrust Global Root


NumCertificates: 4

Queueing Certificates message...



handshakeMessageType: ServerHelloDone

handshakeMessageLen: 0x0


MessageType: ServerHelloDone

Queueing HelloDone message.






MessageType: ServerHello

MessageType: Certificate

MessageType: ServerHelloDone


Dequeued ServerHello message.

Dequeued Certificate message.

DequeuedMessageType: ServerHelloDone

OK to ServerHelloDone!

No client certificate required by the server.

Encrypted pre-master secret with server certificate RSA public key is OK.

Sending ClientKeyExchange...

Sent ClientKeyExchange message.

Sending ChangeCipherSpec...

Sent ChangeCipherSpec message.

Derived keys.

Installed new outgoing security params.

Sending FINISHED message..

algorithm: arc4

keyLength: 128

Sent FINISHED message..




ccsProtocolType: 1







handshakeMessageType: HandshakeFinished

handshakeMessageLen: 0xc


MessageType: HandshakeFinished

FinishedMsgLen: 12

Queueing Finished message.





Dequeue the FINISHED message...

Dequeued Finished message.

Handshake completed successfully.

Secure Channel Established.



connectTime1: Elapsed time: 344 millisec



Adding Host header...

host: autodiscover-s.outlook.com

port: 443

Not auto-adding cookies.

Adding Basic Authentication Header..


sendRequestTime: Elapsed time: 62 millisec

---- Reading HTTP Response ----


No transfer-encoding header field.

sslContentLength: 0

extraLen: 0

Already have entire response.

readResponseTime: Elapsed time: 2200 millisec



responseStatus: 415



totalTime: Elapsed time: 2606 millisec




answered Feb 06 '13 at 02:18

Eric%20Smalltalk's gravatar image

Eric Smalltalk

Here's a new build that should solve the problem:


However, technically the problem is with the web service. Let me explain:

HTTP requests and responses are MIME, which is a standard use extensively in Internet technologies. For example, all email's are also MIME. An HTTP client or server should be able to parse MIME according to all the standards that are commonly used. One such standard involves header fields that have name/value attributes, such as the charset in this case. The attribute value may be enclosed in double-quotes. This would make sense if the attribute value contains whitespace characters. Even if it doesn't, the MIME parser should be able to handle attribute name/value pairs with or without double-quotes.

Internal to Chilkat, decisions are made about whether or not to use double quotes around an attribute value. If the value contains whitespace chars, or any of a number of other special chars, then quotes are used. One such char is "-". This is why the quotes were used for "utf-8" -- because of the "-" character. There were notes in the internal Chilkat source indicating that some other MIME parsers, which could've been email or HTTP related, had trouble when double quotes were NOT used. Therefore, we now have a damned-if-we-do and damned-if-we-don't situation: One server requires the double-quotes, another requires NO double-quotes. What a complete F** mess. If only the servers were properly implemented, there would be no trouble.

Anyway, Chilkat works around it -- but I doubt Chilkat can keep contorting it's insides to make up for the piss-poor implementation of many of these server-side applications..


answered Feb 06 '13 at 17:56

chilkat's gravatar image

chilkat ♦♦

We suggest you may either

  1. When using CkHttp SetRequestHeader or CkHttpRequest AddHeader to manually add Content-Type header, just keep the header string as the programmer set. When using put_ContentType, you may automatically check it to add double quotes if necessary.


  1. Just add a boolean flag property to choose whether automatically add double quotes or just keep the header string as it is set by the programmer.

This shall provide better backward compatibility with reasonable flexibility. Since in some cases, developers may want to just set the header as it is originally set. If needing double quotes or even single quote, we can just set the header as we want.


answered Feb 07 '13 at 10:15

Eric%20Smalltalk's gravatar image

Eric Smalltalk

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: Feb 04 '13 at 12:06

Seen: 13,251 times

Last updated: Feb 07 '13 at 10:15

powered by OSQA