<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Opera extensions fail to modify requestHeaders on google.com ...]]></title><description><![CDATA[<p dir="auto">There is a fairly serious issue that's affecting Opera 109.x and earlier editions, and it surfaces when an extension is installed that modifies the User-Agent header. For v2 extensions that use chrome.webRequest.onBeforeSendHeaders, as well as v3 extensions chrome.declarativeNetRequest via modifyHeaders, the extension is able to modify all requestHeaders as expected except headers on <a href="http://google.com" target="_blank" rel="noopener noreferrer nofollow ugc">google.com</a> domain, but the issue is only with the initial request, all subsequent modifications are fine. This causes unexpected service issues with Google websites, as google receives different User-Agent header responses. Allow access to search page results is already enabled. This also includes not being able to add other headers, cookies, etc. If more information is needed please contact me. This issue does not exist in Chrome or Edge browsers. A quick way to test for this error is to search "what is my user agent" on <a href="http://google.com" target="_blank" rel="noopener noreferrer nofollow ugc">google.com</a> and notice how the UA is never modified as expected.</p>
]]></description><link>https://forums.opera.com/topic/71082/opera-extensions-fail-to-modify-requestheaders-on-google-com</link><generator>RSS for Node</generator><lastBuildDate>Thu, 18 Jun 2026 18:48:31 GMT</lastBuildDate><atom:link href="https://forums.opera.com/topic/71082.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 09 Apr 2024 21:00:06 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Opera extensions fail to modify requestHeaders on google.com ... on Thu, 11 Apr 2024 06:07:17 GMT]]></title><description><![CDATA[<p dir="auto">@escape75 Confirmed. Everything is correct with the extension and it works in other Chromium-based browsers. I filed DNA-116030 for it to see if it's a bug or something intentional Opera does for some reason.</p>
]]></description><link>https://forums.opera.com/post/347782</link><guid isPermaLink="true">https://forums.opera.com/post/347782</guid><dc:creator><![CDATA[burnout426]]></dc:creator><pubDate>Thu, 11 Apr 2024 06:07:17 GMT</pubDate></item><item><title><![CDATA[Reply to Opera extensions fail to modify requestHeaders on google.com ... on Wed, 10 Apr 2024 17:08:10 GMT]]></title><description><![CDATA[<p dir="auto">This would be one way to have a v2 example:</p>
<p dir="auto">manifest.json</p>
<pre><code>{
   "background": {
      "persistent": true,
      "scripts": [ "background.js" ]
   },
   "description": "Header Test",
   "homepage_url": "https://sermak.ca",
   "icons": {
      "128": "icon.png"
   },
   "manifest_version": 2,
   "name": "Header Test",
   "permissions": [ "webRequest", "webRequestBlocking", "tabs", "http://*/*", "https://*/*", "file:///*" ],
   "short_name": "HT",
   "version": "31.6"
}
</code></pre>
<p dir="auto">background.js</p>
<pre><code>// override User Agent
var OBSHOption = ["requestHeaders", "blocking"];
if (chrome.webRequest.OnBeforeSendHeadersOptions.hasOwnProperty("EXTRA_HEADERS")) OBSHOption.push("extraHeaders");
chrome.webRequest.onBeforeSendHeaders.addListener(function(details)
{
	details.requestHeaders = details.requestHeaders.filter(function(elem) { return !elem.name.toLowerCase().includes("sec-ch-ua"); });
	details.requestHeaders.find(function(elem) { if (elem.name.toLowerCase() == "user-agent") elem.value = "New Agent"; });

	return {requestHeaders:details.requestHeaders};
}, {urls:["&lt;all_urls&gt;"]}, OBSHOption);
</code></pre>
<p dir="auto">It's not fixed in v3 either,- I'm guessing it has to do with the "allow access to search results" and a bug in the Opera code that does sets this permission too late for headers to be modified, or something like that ...</p>
<p dir="auto">In the meantime I've switched to Brave, but submitted a bug report.</p>
]]></description><link>https://forums.opera.com/post/347733</link><guid isPermaLink="true">https://forums.opera.com/post/347733</guid><dc:creator><![CDATA[[[global:former_user]]]]></dc:creator><pubDate>Wed, 10 Apr 2024 17:08:10 GMT</pubDate></item><item><title><![CDATA[Reply to Opera extensions fail to modify requestHeaders on google.com ... on Wed, 10 Apr 2024 06:08:30 GMT]]></title><description><![CDATA[<p dir="auto">@escape75 said in <a href="/post/347661">Opera extensions fail to modify requestHeaders on google.com ...</a>:</p>
<blockquote>
<p dir="auto">extension is installed that modifies the User-Agent header. For v2 extensions that use chrome.webRequest.onBeforeSendHeaders, as well as v3 extensions chrome.declarativeNetRequest via modifyHeaders, the extension is able to modify all requestHeaders as expected except headers on <a href="http://google.com" target="_blank" rel="noopener noreferrer nofollow ugc">google.com</a> domain, but the issue is only with the initial request, all subsequent modifications are fine.</p>
</blockquote>
<p dir="auto">Do you have minimal test extensions (v2 and v3) that show this?</p>
]]></description><link>https://forums.opera.com/post/347694</link><guid isPermaLink="true">https://forums.opera.com/post/347694</guid><dc:creator><![CDATA[burnout426]]></dc:creator><pubDate>Wed, 10 Apr 2024 06:08:30 GMT</pubDate></item><item><title><![CDATA[Reply to Opera extensions fail to modify requestHeaders on google.com ... on Wed, 10 Apr 2024 06:07:23 GMT]]></title><description><![CDATA[<p dir="auto">@escape75 said in <a href="/post/347661">Opera extensions fail to modify requestHeaders on google.com ...</a>:</p>
<blockquote>
<p dir="auto">A quick way to test for this error is to search "what is my user agent" on <a href="http://google.com" target="_blank" rel="noopener noreferrer nofollow ugc">google.com</a> and notice how the UA is never modified as expected.</p>
</blockquote>
<p dir="auto">I've noticed that too for a long time with <a href="https://addons.opera.com/en/extensions/details/user-agent-switcher-5/" target="_blank" rel="noopener noreferrer nofollow ugc">https://addons.opera.com/en/extensions/details/user-agent-switcher-5/</a> for example (when set to Chrome for Windows and then clicking the pencil icon (edit) to set the string to <code>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36</code> (what Chrome Stable says at the URL <code>chrome://version</code>)).</p>
<p dir="auto">"Allow access to search page results" doesn't help and neither does going to the URL <code>opera://browserjs</code> and disabling browser.js (to disable any user-agent workarounds Opera might have for Google that might override an extension's).</p>
<p dir="auto">I figured it might have to do with <a href="https://www.chromium.org/updates/ua-ch/" target="_blank" rel="noopener noreferrer nofollow ugc">client hints</a> that the extension isn't modifying or something to do with some Javascript navigator.stuff that the extension neglects to change., but not sure.</p>
<p dir="auto">What does seem to work though is starting Opera like this:</p>
<pre><code>"opera.exe" "--user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
</code></pre>
<p dir="auto">and not using an extension at all. Downside with that is it messes with Opera's sites.</p>
]]></description><link>https://forums.opera.com/post/347693</link><guid isPermaLink="true">https://forums.opera.com/post/347693</guid><dc:creator><![CDATA[burnout426]]></dc:creator><pubDate>Wed, 10 Apr 2024 06:07:23 GMT</pubDate></item></channel></rss>