- Windows NT 4.0 Server SP4+
- Windows Server 2000
- Windows Server 2003
- Windows Server 2008, R2
- Windows Server 2012, R2
- Windows 2000 Professional
- Windows XP
- Windows Vista
- Windows 7
- Windows 8, 8.1
- IIS 4.0, 5.0, 5.1, 6.0, 7.0, 7.5, 8.0
- ASP 3.0 (Classic)
I was browsing around the web earlier looking for inspiration on making PowerShell send asynchronous XmlHttp requests when I came across a block of VBScript examples. In them, I observed that the coder was religiously attempting to set the Content-Length request header, something that when using MsXml I don’t usually do – it’s a different story with PHP.
Equally, I observed that the programmer was using Len() to define the length of the content body for text, but ASP usually operates using an internal UTF-16 encoding to represent strings, thus does it follow that Len() will give the correct value?
So I thought that I would explore the issue to see for my own amusement, what was actually going on.
Let us take a standard code block to use for our tests and use the services of the good people at httpbin.org for a public message echo system.
The above gives us a boiler plate for what we believe the correct header should looklike written in VBScript. When executed, HttpBin responds with:
HttpBin provides us with an echo of the header and WireShark provides us with a wire capture of the transport packet being sent between the XmlHttpResponse provider and the HttpBin server. With these two tools we can analyse the header states.
If you take out the lineand do not specify a content-length, both HttpBin and Wireshark’s trace of the connection report , which is correct. So logically, this has been inserted by the XmlHttp parser during the request to .send().
So what happens if we attempt to override it. If we inject call x.setRequestHeader(“Content-Length”, 15), which is 4 characters too long, again both WireShark and HttpBin report
The same occurs if we under-report the content length, i.e. 10 characters. Therefore it is safe to conclude that
To further test the theory to see if it is required in down-level versions of MsXml, I repeated the experiment using HttpBin and Wireshark with the following COM objects:
None of them could be coerced to include an incorrectly sized Content-Length and all of them appended the correct 11 character content length on their own when no attempt was made to manually provide it.
We can therefore categorically conclude that with MSXML 3.0 and higher, you do not need to waste time calculating the content length.
A an aside, when dealing with character data, the use of Len() appears to be correct for UTF-8 encoding. LenB() should be used when passing in binary data i.e. ADODB.Stream data, FileSystemObject data etc.
If you do not manually specify a Content-Type header, all MSXML providers appear to transmit POST encoded data as
As we were sending POST data (i.e. a HTML form), this is incorrect as the content-type should be “application/x-www-form-urlencoded; Charset=UTF-8”. Thus is is appropriate and necessary to include the Content-Type header manually as shown below.
Accept language was decidedly different depending on which provider you are using. You can safely override Accept-language by manually specifying it using.
Thus, if you are using the legacy Microsoft.XmlHttp or the client MsXml2.XmlHttp.3.0, it is necessary to manually enter the Accept-Language if of course it is needed.
All examples set the connection value to Connection: Keep-Alive\r\n when communicating with the HTTP/1.1 protocol. If you need to force the remote server to close the TCP connection immediately after the response has been received, you must manually set Connection: Close\r\n using.
Cache-control is only set by the client providers and can be added manually to the server providers.
Accept-encoding is only set by the client providers and can be added manually to the server providers.
Accept is set to Accept: */*\r\n by all providers and can be overridden if required.