Open Bug 89928 Opened 23 years ago Updated 2 months ago

PAC: Proxy configuration overhaul (use PAC for everything)

Categories

(Core :: Networking: Proxy, enhancement, P5)

x86
Other
enhancement

Tracking

()

Future

People

(Reporter: benc, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [necko-would-take])

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.
Severity: normal → enhancement
serge, another pac bug.
Assignee: neeti → serge
Blocks: 79893
*** 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).
QA Contact: benc → pacqa
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)
Keywords: helpwanted
Assignee: general → nobody
QA Contact: pacqa → networking
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
See Also: → 133903
Severity: normal → S3

Moving bug to Core/Networking: Proxy.

Component: Networking → Networking: Proxy
You need to log in before you can comment on or make changes to this bug.