Changed behaviour of XHR regarding content length

John Bieling john.bieling at
Sat Aug 31 11:18:34 UTC 2019


I wanted to report something that I tracked down yesterday, which I
thought is very strange. I do not know if it is a bug, but it did cause
my AddOn to fail.

I have a simple XHR request:

             syncData.req = new XMLHttpRequest();
             syncData.req.mozBackgroundRequest = true;
             syncData.req.setRequestHeader("User-Agent", "Thunderbird
             syncData.req.setRequestHeader("Authorization", "Basic xxx");
             syncData.req.setRequestHeader("MS-ASProtocolVersion", "14.0");
             syncData.req.setRequestHeader("Content-Length", wbxml.length);

             syncData.req.onload = function() {
                 let response = syncData.req.responseText;
                 console.log(syncData.req.status + " : " +response);


This started to fail in TB68 using the exact same request as in TB60, if
the wbxml string contained non-ascii chars. With "fail" I mean that the
server no longer accepted the request.

I tracked it down to the Content-Length header. The protocoll requires
the wbxml string to be utf-8, so chars like "ä" or "ü" need two bytes
instead of one. This means that the byte length of wbxml does not match
its "character" length returned by wbxml.length.

I now do

             const textEncoder = new TextEncoder();
             let encoded = textEncoder.encode(wbxml);

             syncData.req.send(encoded); // or syncData.req.send(wbxml);
- both work

I think how I did it before was wrong, but nevertheless, the XHR request
with the wrong Content-Length header was accepted on the other side with
TB60, but not with TB68. Maybe TB60 adjusted the Content-Length header?

I do not know.

Just wanted to share this, as others might stumble over this as well.


More information about the tb-planning mailing list