netwerk/protocol/http/README@deefc01c0e14
netwerk/protocol/http/README
Thu, 15 Jan 2015 21:03:48 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Thu, 15 Jan 2015 21:03:48 +0100
- branch
- TOR_BUG_9701
- changeset 11
- deefc01c0e14
- permissions
- -rw-r--r--
Integrate friendly tips from Tor colleagues to make (or not) 4.5 alpha 3;
This includes removal of overloaded (but unused) methods, and addition of
a overlooked call to DataStruct::SetData(nsISupports, uint32_t, bool.)
1 Darin Fisher
2 darin@netscape.com
3 8/8/2001
5 HTTP DESIGN NOTES
8 CLASS BREAKDOWN
10 nsHttpHandler
11 - implements nsIProtocolHandler
12 - manages preferences
13 - owns the authentication cache
14 - holds references to frequently used services
16 nsHttpChannel
17 - implements nsIHttpChannel
18 - talks to the cache
19 - initiates http transactions
20 - processes http response codes
21 - intercepts progress notifications
23 nsHttpConnection
24 - implements nsIStreamListener & nsIStreamProvider
25 - talks to the socket transport service
26 - feeds data to its transaction object
27 - routes progress notifications
29 nsHttpConnectionInfo
30 - identifies a connection
32 nsHttpTransaction
33 - implements nsIRequest
34 - encapsulates a http request and response
35 - parses incoming data
37 nsHttpChunkedDecoder
38 - owned by a transaction
39 - removes chunked decoding
41 nsHttpRequestHead
42 - owns a nsHttpHeaderArray
43 - knows how to fill a request buffer
45 nsHttpResponseHead
46 - owns a nsHttpHeaderArray
47 - knows how to parse response lines
48 - performs common header manipulations/calculations
50 nsHttpHeaderArray
51 - stores http "<header>:<value>" pairs
53 nsHttpAuthCache
54 - stores authentication credentials for http auth domains
56 nsHttpBasicAuth
57 - implements nsIHttpAuthenticator
58 - generates BASIC auth credentials from user:pass
61 ATOMS
63 nsHttp:: (header namespace)
65 eg. nsHttp::Content_Length
68 TRANSACTION MODEL
70 InitiateTransaction -> ActivateConnection -> AsyncWrite, AsyncRead
72 The channel creates transactions, and passes them to the handler via
73 InitiateTransaction along with a nsHttpConnectionInfo object
74 identifying the requested connection. The handler either dispatches
75 the transaction immediately or queues it up to be dispatched later,
76 depending on whether or not the limit on the number of connections
77 to the requested server has been reached. Once the transaction can
78 be run, the handler looks for an idle connection or creates a new
79 connection, and then (re)activates the connection, assigning it the
80 new transaction.
82 Once activated the connection ensures that it has a socket transport,
83 and then calls AsyncWrite and AsyncRead on the socket transport. This
84 begins the process of talking to the server. To minimize buffering,
85 socket transport thread-proxying is completely disabled (using the flags
86 DONT_PROXY_LISTENER | DONT_PROXY_PROVIDER | DONT_PROXY_OBSERVER with
87 both AsyncWrite and AsyncRead). This means that the nsHttpConnection's
88 OnStartRequest, OnDataAvailable, OnDataWritable, and OnStopRequest
89 methods will execute on the socket transport thread.
91 The transaction defines (non-virtual) OnDataReadable, OnDataWritable, and
92 OnStopTransaction methods, which the connection calls in response to
93 its OnDataAvailable, OnDataWritable, and OnStopRequest methods, respectively.
94 The transaction owns a nsStreamListenerProxy created by the channel, which
95 it uses to transfer data from the socket thread over to the client's thread.
96 To mimize buffering, the transaction implements nsIInputStream, and passes
97 itself to the stream listener proxy's OnDataAvailable. In this way, we
98 have effectively wedged the response parsing between the socket and the
99 thread proxy's buffer. When read, the transaction turns around and reads
100 from the socket using the buffer passed to it. The transaction scans the
101 buffer for headers, removes them as they are detected, and copies the headers
102 into its nsHttpResponseHead object. The rest of the data remains in the
103 buffer, and is proxied over to the client's thread to be handled first by the
104 http channel and eventually by the client.
106 There are several other major design factors, including:
108 - transaction cancelation
109 - progress notification
110 - SSL tunneling
111 - chunked decoding
112 - thread safety
113 - premature EOF detection and transaction restarting
114 - pipelining (not yet implemented)
117 CACHING
119 <EOF>
