1730441 - Firefox is not sending proper HTTP headers, causing addon update/update_url check to fail.

Status: UNCONFIRMED

(Toolkit :: Add-ons Manager, task, P5)

Description

[Raven N]

User Agent: Firefox

Steps to reproduce:

1. Have a unlisted add-on (for example, to use in internal network) with this manifest.json example:

1. manifest.json
  "applications": {
    "gecko": {
      "update_url": "https://intranet.example.com/addons?corpId=1"
    }
  }

Note, intranet.example.com is having valid HTTPS certificate.

2. Install the add-on.

3. Open Burger, Web Developer, Browser Console.

4. From about:addons select the add-on, Turn Allow automatic updates to Off.

5. Click Check for Updates blue link.

Actual results:

6. Your Firefox will try to make HTTP request but it will fail with "addons.update-checker WARN HTTP Request failed for an unknown reason"

You can see headers from Browser Console:

GET /addons?corpId=1 undefined
Host: intranet.example.com
...

This is preventing add-on update.

Expected results:

6. Your Firefox should send HTTP headers properly just like normal request.

Normal request (open New tab, paste URL and hit Enter):
GET /addons?corpId=1 HTTP/2.0
Result: Load successfuly

Your addons.update-checker request:
GET /addons?corpId=1 undefined
Result: Fail

Many corporate WAFs deny invalid headers (like above example, request will be dropped because there is not HTTP/2.0)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Tomislav Jovanovic :zombie]

Do you have a public server that exhibits this behavior? It might be a corporate firewall that's doing this.

Comment 3

[Rob Wu [:robwu]]

The "corporate WAFs deny invalid headers" comment suggests that your environment does TLS interception (to view the plain text HTTP request), and then re-encrypts the request supported by a custom root CA (to get Firefox to trust the response).

Could you share more details such as about:support, and maybe a packet capture (e.g. with Wireshark) so that we can see the actual network traffic?

Comment 4

[Alex Cornestean]

Hello,

I’ve tried modifying an add-on with the suggested manifest.json file contents, loaded it in Firefox and checked for updates.
Whereas no updates were found, I did not notice any of the behavior described in the “Actual results: section of the bug.

Comment 5

[Jykkel]

I have similar result.

1. Download Tor Browser 10.5.6 (latest)
2. Install add-on which uses custom https for json
3. Open Browser Console and set XHR active.
4. and do step 4 and 5 as the OP suggested.

Tor Browser

Request Headers
GET /... undefined

Not HTTP/1.1, not HTTP/2.0. It just says 'undefined.'

Strangely, official Firefox 78.14.0esr exhibits similar problem

Firefox 78esr

Request Headers
GET /... HTTP/1.1

It should try HTTP/2.0, just like on normal tab do.

Comment 6

[Jykkel]

tl:dr;

• Tor Browser is sending 'undefined'
• Firefox esr is requesting request with HTTP/1.1 against HTTP2-only website; e.g. if ($http_version != 'HTTP/2.0'){kill_connection()}
  • This site works fine with Firefox esr in new tab, why not updatechecker?
• Firefox should try HTTP2 against updatechecker, just like normal tab request do.

Comment 7

[Shane Caraveo (:mixedpuppy)]

• 78esr has been out for a very long time, I'm not aware of any changes there that would have caused this.
• I'm not familiar with tor patches, they should be contacted regarding the difference they display.

If this is configured via proxy, the network.http.proxy.version preference is defaulted to 1.1
From what I can see, any code that might have affected this was only related to http3, landed in fx53. I'm not sure why the upgrade to http2 is not happening.

It could help to see an http log.

set MOZ_LOG=nsHttp:5
set MOZ_LOG_FILE=http.log

Comment 8

[Shane Caraveo (:mixedpuppy)]

Tom, can you get someone at Tor to look at the Tor part of this issue? See comment 5

Comment 9

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I'll leave the ni for myself until we can validate or invalidate the issue in vanilla Firefox - that might be the same thing affecting Tor.

Comment 10

[Yasmin Lee]

Hi everyone, just wanted to add my case here.

In Browser console, XHR's Raw header says

GET /dev/update?addon=experiment1 undefined

/ network.http.proxy.version is not modified
/ using PAC file (about:preferences) to proxy url to corporate proxy
/ updater didn't switch to HTTP2 at all
/ above /dev/updater can be opened in new tab over HTTP/2

addons.update-checker WARN HTTP Request failed for an unknown reason

Firefox 91.2.0esr 64bit

Comment 11

[Kv]

HTTP2 switching is not happening on Firefox 91.
I have this add-on since about 2 years ago.

The easiest steps would be:

1. Open Firefox 91 (with proxy PAC settings in my case)
2. Install the add-on
3. Open Console
4. Check for update

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mixedpuppy, since the bug doesn't have a severity set, could you please set the severity or close the bug?

For more information, please visit auto_nag documentation.

Comment 13

[Shane Caraveo (:mixedpuppy)]

removing old ni?