HTTPS proxy setting change doesn't take effect until restart

UNCONFIRMED
Unassigned

Status

()

Core
Networking
P3
normal
UNCONFIRMED
5 years ago
a month ago

People

(Reporter: james-bugzilla, Unassigned)

Tracking

18 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

Change proxy setting from one (valid) proxy address to another (manual proxy configuration/HTTP proxy/use this proxy server for all protocols ticked)


Actual results:

HTTP requests go to new proxy entered in preferences, HTTPS requests go to proxy specified previously. Happens reliably until restart of FF.


Expected results:

Should use newly specified proxy for both HTTP and HTTPS
Are you sure that this isn't due to an already open connection (keep alive) ?
James, could you please answer to comment1?
Component: Untriaged → Networking
Product: Firefox → Core
(Reporter)

Comment 3

5 years ago
Trying to replicate problem again, but access to multiple proxies is time consuming. Will drag wireshark traces off. Might take a few days.
(Reporter)

Comment 4

5 years ago
Confirmed, although subtly different than I originally thought.

Proxy used remains the same as the first time a given HTTPS site was accessed, until restart.

eg set to use proxy 1, go to https://www.google.com

set to use proxy 2
go to https://www.google.com, proxy 1 is used
go to https://onlinebanking.nationwide.co.uk, proxy 2 is used

set back to proxy 1
go to https://www.google.com, proxy 1 is used
go to https://onlinebanking.nationwide.co.uk, proxy 2 is used

close onlinebanking tab,
go to https://onlinebanking.nationwide.co.uk again, proxy 2 is used

Performed same tests with http:// versions, immediate use of the proxy as per settings.

It's possible that keep alive is in effect, I dont know enough about how that shoud/can work. I have waited before refresh, and closed tabs to ensure that any open session should (in my mind) be closed. Maybe not.

Have noticed sometimes it works as expected. Will do another test tomorrow to see if I can spot the issue again.

Tried to take wireshark caps but they'll be too complicated to redact. Can pull relevent parts if it's really required.
(Reporter)

Comment 5

5 years ago
Just noticed that I began troubleshooting with 17.0.1, FF updated itself to 18.0.1 during the test (at browser restart I guess) and it's potentially at this point I noticed correct behaviour (i.e sometimes works as expected comment above).

Apologies if this is making for a confused bug report.
 can you repro with nightly? (ff 21) There have been some changes in recent weeks and I'm not 100% certain which releases they are in.. some of them are certainly in 18, but I'm not sure if it is everything that is relelvant. I kinda suspect this was fixed in 18.

you can clear old keep-alives with ctrl-shift-r .. though I don't think they should play a role here. (i.e. the pref change should dictate a new route which should be honored immediately.. independent of existing cached connections)

If you still have a reproducible failure on ff 21 a clear STR (steps to reproduce) would be needed to make it actionable.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.