User:Brahmana/Netwerk Docs/Connection Transaction Organization

There are two main classes which actually define the basic behavior of a Http Connection and a Http Transaction. They are:

1. nsAHttpConnection
2. nsAHttpTransaction

Ideally, I would have expected these two be two interfaces. Because that's what they are, "Interfaces to two things, viz a connection and a transaction". But for some reason these were made abstract classes. Probably to avoid usage from JS. Then again these could be made non-scriptable interfaces. Now as you know, I seriously do not know why these are abstract classes and not interfaces.

[When you say interface you mean IDL file? There's no point to write an IDL for these two interfaces really. They're only supposed to be used inside of the HTTP implementation, and there doesn't seem to be any advantage in being restricted by IDL syntax --Biesi 06:20, 18 July 2008 (PDT)]

Going ahead, there are multiple implementations of these two behavioral classes. Some of which I have come across are:

• nsAHttpConnection
  • nsHttpConnection -- This actually represents a connection. This is never accessed directly. The two things below act as wrappers to this one.
  • nsConnectionHandle -- This is used for wrapping the connection when pipelining is not allowed.
  • nsPipeline -- This is used for wrapping the connection when pipelining is allowed and is being done.

• nsAHttpTransaction
  • nsHttpTransaction -- This is used when pipelining is not allowed.
  • nsPipeline -- This is used when pipelining is allowed and is being done.

[you mean nsHttpPipeline where you write nsPipeline, right? --Biesi 18:36, 4 August 2008 (UTC)]

Now I do not know whether these implementations have something extra apart from helper methods. That is a question for necko folks.

Q1. Do the concrete implementations have a lot more things than what is present in the abstract classes? If so what sort of stuff? (Examples at a high-level)

[Sorry, I don't really understand the question. Other than the helper methods they also have the implementation of the interfaces. I'm not sure what kind of answer you are looking for...

The transaction class is what actually sends the data to the server, parses the headers, etc. It sits between the channel and the socket.

Does that answer your question? --Biesi 18:36, 4 August 2008 (UTC)]

There is no 1-to-1 mapping between a transaction and a connection.

Q2. What all things are logically represented by a transaction (a nsHttpTransaction or a nsHttpPipeline object)?

[A transaction (txn) is a single HTTP request. An HTTP channel usually has one txn, but can have more than one in the case of authentication retries or none in case of cache reads. It can not have more than one at a time though. --Biesi 18:36, 4 August 2008 (UTC)]

Q3. In this part of code we take away references to the actual connection from both the transaction and the wrapper object connection handle. But later in DispatchTranscation we populate the two objects with the same connection. What is the reason for this? Is this to take care of the situation where in initially pipelining was not done and now it needs to be done? What is rationale behind this code?

[Which lines are you talking about in DispatchTransaction? I don't see where we populate two objects with the same connection. --Biesi 18:36, 4 August 2008 (UTC)]