There are lots of individaul RFE's for Proxy configuration (multiple hostnames in manual config, failover of multiple servers, support for other protocols). The underlying problem is that the current feature set (and the preferences panel) are built on 1995 technology. What we need is a larger re-write that combines several new features to coherently update what we support. 1- Add a "URLScheme()" to PAC. The shell expression function call is too messy, and this is the most frequent use of that function. 2- Change the Proxy prefs so the underlying modes are implemented as PAC. Direct would be a null PAC file (so each URL would be treated as "DIRECT"). Manual would create a PAC file that is composed of a series of manual entries in the form "URLScheme()". PAC would point to a PAC URL. This would do several things: - Simplify turning prefs into working behavior. The current system has each URL scheme implementation reading out of "networking.proxy.*" manually. Making changes like "should SOCKS come before or after the relevant application proxy" require re-codes. If prefs wrote a PAC file, we could change these behaviors without having to extensivly re-code and test the underlying behavior, we just make sure the new PAC file created by prefs is valid and logical. - Simply the initizliation: On startup, if online, you can just call the PAC URL directly, and not worry about the chicken-and-egg PAC problem b/c the default PAC behvaior would be a DIRECT connection, which is how you should load PAC anyhow. - Simplify the reload button. It would set the PAC back to a null function, then try to fetch the PAC URL (which would end up a DIRECT connection attempt). - Simplfy the addition of proxy support of other protocols. Just add new manual entries to the UI, and they would create other "URLScheme()" handlers. - Simplify the process of adding more robustnest to manual config. Manual config is a mess, and I don't think anyone knows what the final feature set of a the next re-write would be. This architecture would allow implmentation of that by leveraging the PAC flexiblity. - Simplify admin creation of PAC files. As manual config becomes more sophisticated, proxy admins might find they want to make minor changes. If manual config is already creating a PAC, they can hack the file. Right now, they have to understand manual behavior, then write a PAC that has that behavior + the changes they want.
serge, another pac bug.
Assignee: neeti → serge
*** Bug 60337 has been marked as a duplicate of this bug. ***
resetting owner. Additional plus: Things like multi-server failover could be more easily implemented b/c the pac logic is much easier than implementing and testing hard coded behaviors.
Assignee: serge → new-network-bugs
*** Bug 132540 has been marked as a duplicate of this bug. ***
*** Bug 133903 has been marked as a duplicate of this bug. ***
Please don't mark prxy bug dups of this bug. This bug is an enhancement, and it has not yet been decided, if this bug will be fixed or when.
Temporarily "futuring" all PAC&SOCKS bugs to clear new-networking queue. I will review later. (I promise) If you object, and can make a case for a mozilla 1.0 fix, please reset milestone to "--" or email me.
Target Milestone: --- → Future
I'm just a user so I'm not too familiar with PAC. But, am I to assume that you would create a new UI that would write out these files and give you all the capabilities of PAC. And PAC already has automatic fallback? As a laptop user I'd very much like something that would try a direct connection, then my local proxy, then my work proxy, etc, and then stick with that connection until it encountered another problem. I'd also like to be able to select a particular proxy with toggle buttons on the Navigation bar, say to use an adbuster, or to use "Any" or "Work." It should also by stick to tabs, so that when I opened up a connection to oed.com in a "Work" proxy, it wouldn't switch to some other proxy when I opened up a website inaccessable to the "Work" proxy in another window. Cuz oed.com uses your IP to tell whether you have access, and the direct or "Home" proxy wouldn't be able to query for definitions, but would get a reply with some "subscribe for only $10,000 today!" web page.
This bug is about the implementation only, not UI.
Yes. The idea is to change the plumbing under the manual UI, so that you could basically implement more types of UI w/o re-writing every affected protocol handler. PAC specifies failover, although it is currently broken (there is a bug on that). There is another bug that says we should allow switching of network configs (which would include a PAC file selection) as a menu that replaces the offline/online UI. This would probably get you what you want, although this is generally thought of as a mode-switching, not a real-time feature. If you have trouble finding these bugs, I'll link them in later (when bugzilla queries are faster).
Summary: [RFE] Proxy configuration overhaul (use PAC for everything) → PAC: [RFE] Proxy configuration overhaul (use PAC for everything)
Summary: PAC: [RFE] Proxy configuration overhaul (use PAC for everything) → PAC: Proxy configuration overhaul (use PAC for everything)
Assignee: general → nobody
QA Contact: pacqa → networking
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.