[BUG] Doesn't modify the header value as configured

[ygoe]

Describe the bug I've installed the extension in Firefox 64.0 on Windows 10 and created a single rule:

• Rule type: Modify the response header
• Match type: Domain
• Match rules: www.heise.de
• Execute type: Normal
• Header name: Cache-Control
• Header value: public, max-age=3600

Then I opened the page https://www.heise.de/newsticker/ and inspected the response headers in the Firefox F12 tools. It was still the max-age value of 30 that is sent by the server. The extension doesn'T change anything.

I need a way to prolong the cache time of these pages because the website loads very slow and I often go back after reading an article. That takes too much time, so I thought I could hack (improve) their HTTP headers a bit. Going back should be instant but it isn't.

Rule and Test address See above.

[ae3a5]

It's possible that headers are modified after they passed through inspector tool. You can check cache entry information (about:cache window), it contains "response-head" and "original-response-headers". I use HE for the nearly same purposes, to reduce mobile traffic. It works.

[ae3a5]

Example: response-head: ..... Cache-Control: max-age=31536000, public, immutable ...... original-response-headers: ......... Cache-Control: max-age=604800 ......

[sylingd]

HE have modified this header, it have taken effects, but Firefox does not completely follow Cache-Control header. When no rules enabled: When rule with a short time (10 seconds) enabled: When rule with a long time (1200000 seconds) enabled:

[baptx]

It looks like the addon is not modifying response headers, for example I tested by adding the response header "Location: https://example.com/" but nothing happens, I am not redirected to https://example.com/ when I visit any website. Any idea? Tested with Firefox 65.0.1 64-bit on Linux (Ubuntu / LXQt).

[sylingd]

I have made a simple test by written a new Extension which only modify "Location" header directly. Then I found that if the original response headers include "Location", the modification will take effect. If not, the modification will take no effect. It's not HE's bug, both Firefox and Chrome do this.

This simple extension: manifest.json

{
	"name": "test",
	"short_name": "test",
	"version": "1",
	"description": "test",
	"manifest_version": 2,
	"permissions": [
		"tabs",
		"webRequest",
		"webRequestBlocking",
		"*://*/*"
	],
	"background": {
		"scripts": ["background.js"]
	}
}

background.js

chrome.webRequest.onHeadersReceived.addListener(function(e) {
	if (!e.responseHeaders) {
		return;
	}
	let set = false;
	e.responseHeaders.forEach(el => {
		if (el.name.toLowerCase() === "location") {
			el.value = "http://www.baidu.com";
			set = true;
		}
	})
	if (!set) {
		e.responseHeaders.push({
			name: "Location",
			value: "http://www.baidu.com"
		});
	}
	return { responseHeaders: e.responseHeaders };
// If you are using Firefox, remove ", 'extraHeaders'" below
}, { urls: ["<all_urls>"] }, ['blocking', 'responseHeaders', 'extraHeaders']);

[sylingd]

I searched the documentions, maybe because the status code is not 301 or 302, so browser will ignore location header

[baptx]

@sylingd thanks for your quick reply, I can confirm that modifying other response headers works, for example "Content-Disposition: attachment" displays a download popup. Is it not possible to modify the status code with the WebExtensions API? It looks like other addons have this problem also: https://github.com/spenibus/cors-everywhere-firefox-addon/issues/11

[sylingd]

There is no such API to modify status code but I found that you can redirect requests in "onHeadersReceived" stage, I'm thinking about how to implement it in HE