Problem statement: Applications suck at correctly and consistently supporting proxy configuration.
Proxy configuration is problematic for a number of reasons:
- There are a variety of places to get configuration information
- There are a variety of proxy types
- Automatically determining PAC location requires an implementation of the WPAD protocol
These issues make programming with support for proxies hard. Application developers only want to answer the question: Given a network resource, how do I reach it? Because this is their concern, most applications just give up and try to read the proxy from an environment variable. This is problematic because:
libproxy exists to answer the question: Given a network resource, how do I reach it? It handles all the details, enabling you to get back to programming.
GNOME? KDE? Command line? WPAD? PAC? Network changed? It doesn't matter! Just ask libproxy what proxy to use: you get simple code and your users get correct, consistant behavior and broad infrastructure compatibility. Why use libproxy?
libproxy offers the following features:
- support for all major platforms: Windows, Mac and Linux/UNIX (see upcoming 0.4 release)
- extremely small core footprint
- no external dependencies within libproxy core (libproxy plugins may have dependencies)
- only 3 functions in the stable-ish external API (1.0 will offer full stability)
- dynamic adjustment to changing network topology
- a standard way of dealing with proxy settings across all scenarios
- a sublime sense of joy and accomplishment
Frequently Asked Questions
- What features does libproxy currently provide? Future plans?
- Does libproxy support proxy authentication?
- Which plugins get used in which order?
- How do I use libproxy in my application?
- What programs currently use libproxy?
- How can I help?
- How can I donate?
- How can I contact you?