You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Proxies in Necko

by Christian Biesinger <>

Proxies are implemented transparently to necko users. This means that callers can just create an nsIChannel, not needing to worry about whether the channel will use a proxy or not

The basic interfaces for proxies are: nsIProxyInfo, nsIProtocolProxyService, nsIProxiedProtocolHandler

nsIProxyInfo is a simple helper which stores information about the type of the proxy, its host and its port.


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.


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.