InitiateTransaction -> ActivateConnection -> AsyncWrite, AsyncRead
The channel creates transactions, and passes them to the handler via InitiateTransaction along with a nsHttpConnectionInfo object identifying the requested connection. The handler either dispatches the transaction immediately or queues it up to be dispatched later, depending on whether or not the limit on the number of connections to the requested server has been reached. Once the transaction can be run, the handler looks for an idle connection or creates a new connection, and then (re)activates the connection, assigning it the new transaction.
Once activated the connection ensures that it has a socket transport, and then calls AsyncWrite and AsyncRead on the socket transport. This begins the process of talking to the server. To minimize buffering, socket transport thread-proxying is completely disabled (using the flags DONT_PROXY_LISTENER | DONT_PROXY_PROVIDER | DONT_PROXY_OBSERVER with both AsyncWrite and AsyncRead). This means that the nsHttpConnection's OnStartRequest, OnDataAvailable, OnDataWritable, and OnStopRequest methods will execute on the socket transport thread.
The transaction defines (non-virtual) OnDataReadable, OnDataWritable, and OnStopTransaction methods, which the connection calls in response to its OnDataAvailable, OnDataWritable, and OnStopRequest methods, respectively. The transaction owns a nsStreamListenerProxy created by the channel, which it uses to transfer data from the socket thread over to the client's thread. To mimize buffering, the transaction implements nsIInputStream, and passes itself to the stream listener proxy's OnDataAvailable. In this way, we have effectively wedged the response parsing between the socket and the thread proxy's buffer. When read, the transaction turns around and reads from the socket using the buffer passed to it. The transaction scans the buffer for headers, removes them as they are detected, and copies the headers into its nsHttpResponseHead object. The rest of the data remains in the buffer, and is proxied over to the client's thread to be handled first by the http channel and eventually by the client.