nsIIOService

The decision whether to use a proxy is made in nsIOService::NewChannelFromURI. It first asks the nsIProtocolProxyService for an nsIProxyInfo. Depending on the type of the proxy info, it either asks the HTTP Protocol Handler or the protocol handler for the requested URI for a new channel with the nsIProxyInfo - if the channel supports nsIProxiedProtocolHandler. Otherwise, the proxy info is discarded.

nsIProtocolProxyService

The most important function on nsIProtocolProxyService is resolve. It checks whether the passed-in URI should use a proxy, and returns an nsIProxyInfo if so.

This works by examining the protocolFlags of the protocol handler for the given URI. If this protocol handler does not support proxies, resolve returns null. Alternatively, if proxies are disabled, or this host is in the list of hosts for which no proxy should be used, null is also returned.

If PAC (proxy autoconfiguration) is enabled, it is asked for the proxy string for the given URI, which determines whether to use a proxy. Note that the PROXY method is only used when the protocol handler supports HTTP proxies, as indicated by its protocol flags.

Finally, depending on the protocol, the proxy info will be created with the appropriate type, host and port.

SOCKS and nsISocketTransportService

The aforementioned methods work very well for application-level proxies. However, SOCKS is transparent to upper-level protocols, and can transport any other TCP- or UDP-based protocol.

Therefore, nsISocketTransportService supports creating socket transports using an nsIProxyInfo. This proxy info will only be used if it specifies a SOCKS proxy, through which the connection is then made.

Note that SOCKS is implemented as an nsISocketProvider, and the socket transport service will therefore use it as as the downmost socket type.

To be written

XXX missing paragraphs are about PAC, and more details about HTTP proxying, and maybe some more details about SOCKS proxies.