Difference in GM_xhr responseHeaders between FF 5.1.1 and Chrome 5.2.3

[perpil]

The responseHeaders returned with GM_xmlhttpRequest include \r in FF TM 5.5.1 and don't in Chrome 5.2.+.

This can be worked around, but raising in case it is unintentional.

Expected Behavior

Behavior is consistent across browsers.

Actual Behavior

FF has \r\n as responseHeaders delimiter, Chrome just has \n.

Specifications

• Chrome 127.0.6533.120/TM 5.2.0 and 5.2.3
• FF 129.0.1/TM 5.1.1
• OS: Mac Os 14.5

Script

// ==UserScript==
// @name         HTTP Header in xmlhttpRequest
// @namespace    http://tampermonkey.net/
// @version      2024-08-17
// @description  try to take over the world!
// @author       You
// @grant        GM_xmlhttpRequest
// @match        https://github.com/
// @connect      self
// @icon         https://www.google.com/s2/favicons?sz=64&domain=google.com
// ==/UserScript==

(async function() {
    'use strict';

  await GM_xmlhttpRequest({
  method: "GET",
  url: "https://github.com/",
  onload: function(response) {
    console.log(`Headers includes \\r?: ${response.responseHeaders.includes('\r')}`);
  }
});
})();

Run this on https://github.com and look in the console in both Firefox and Chrome. Chrome will print false, FF will print true.

[peterpham]

Observe the same behaviour.
This breaks some of our logic to parse headers and caused incompatibility.

[derjanb]

Should be fixed at 5.3.6209 (crx|xpi in review)

Please download the crx file linked above and drag and drop it to the extensions page chrome://extensions (after you've enabled 'Developer Mode').

For a quick fix please export your settings and scripts as zip or (JSON) file at the "Utilities" tab and import it back at the fixed BETA version.

[trim21]

Didn't try beta version, not sure how tampermonkey fix this.

Just want to add some context: RFC says HTTP header should always use CRLF as line break.