The Transfer-Encoding header indicates the format of the request body that follows. It's no solution to just add the header -- because the body must be sent as the header describes. (The header tells the receiving end the transfer encoding of what follows.)
To understand the chunked transfer encoding, see this: https://en.wikipedia.org/wiki/Chunked_transfer_encoding
Chilkat REST can send HTTP requests using the chunked transfer encoding. In fact, in cases where the body of the request comes from a stream, that is the only possible choice. However, many servers cannot handle a client using the chunked transfer encoding. Case in point: Google Drive. The server-side of Google Drive requires a Content-Length header and is incapable of receiving a chunked request. Chilkat makes this exception for Google Drive internally, and will use the non-chunked (i.e. typical) HTTP request w/ a Content-Length if the size of the stream can be known (such as if it is a file stream).
Why do I mention all of this? Because it's best if the server simply accepts either. When implementing a protocol, it's best to avoid constraints -- i.e. requiring the peer to avoid certain aspects of the protocol. For example, the QuickBooks server-side cannot handle MIME continuation lines in the HTTP request. (WTF???) All of these "partial" implementations of protocols where restrictions need to be known in advance make it overly complicated to get anything working with your server. It almost entirely defeats the purpose of having a protocol in the first place.
My advice: Make the server accept both chunked and typical HTTP requests w/ Content-Length.
I just tried this:
And the result was:
So the AddHeader method appears to be working. Can you post a code example that demonstrates the problem? Are you using the latest version of the Chilkat library?
answered Oct 26 '16 at 09:10