1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/netwerk/protocol/http/README Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,119 @@
1.4 + Darin Fisher
1.5 + darin@netscape.com
1.6 + 8/8/2001
1.7 +
1.8 + HTTP DESIGN NOTES
1.9 +
1.10 +
1.11 +CLASS BREAKDOWN
1.12 +
1.13 + nsHttpHandler
1.14 + - implements nsIProtocolHandler
1.15 + - manages preferences
1.16 + - owns the authentication cache
1.17 + - holds references to frequently used services
1.18 +
1.19 + nsHttpChannel
1.20 + - implements nsIHttpChannel
1.21 + - talks to the cache
1.22 + - initiates http transactions
1.23 + - processes http response codes
1.24 + - intercepts progress notifications
1.25 +
1.26 + nsHttpConnection
1.27 + - implements nsIStreamListener & nsIStreamProvider
1.28 + - talks to the socket transport service
1.29 + - feeds data to its transaction object
1.30 + - routes progress notifications
1.31 +
1.32 + nsHttpConnectionInfo
1.33 + - identifies a connection
1.34 +
1.35 + nsHttpTransaction
1.36 + - implements nsIRequest
1.37 + - encapsulates a http request and response
1.38 + - parses incoming data
1.39 +
1.40 + nsHttpChunkedDecoder
1.41 + - owned by a transaction
1.42 + - removes chunked decoding
1.43 +
1.44 + nsHttpRequestHead
1.45 + - owns a nsHttpHeaderArray
1.46 + - knows how to fill a request buffer
1.47 +
1.48 + nsHttpResponseHead
1.49 + - owns a nsHttpHeaderArray
1.50 + - knows how to parse response lines
1.51 + - performs common header manipulations/calculations
1.52 +
1.53 + nsHttpHeaderArray
1.54 + - stores http "<header>:<value>" pairs
1.55 +
1.56 + nsHttpAuthCache
1.57 + - stores authentication credentials for http auth domains
1.58 +
1.59 + nsHttpBasicAuth
1.60 + - implements nsIHttpAuthenticator
1.61 + - generates BASIC auth credentials from user:pass
1.62 +
1.63 +
1.64 +ATOMS
1.65 +
1.66 + nsHttp:: (header namespace)
1.67 +
1.68 + eg. nsHttp::Content_Length
1.69 +
1.70 +
1.71 +TRANSACTION MODEL
1.72 +
1.73 + InitiateTransaction -> ActivateConnection -> AsyncWrite, AsyncRead
1.74 +
1.75 + The channel creates transactions, and passes them to the handler via
1.76 + InitiateTransaction along with a nsHttpConnectionInfo object
1.77 + identifying the requested connection. The handler either dispatches
1.78 + the transaction immediately or queues it up to be dispatched later,
1.79 + depending on whether or not the limit on the number of connections
1.80 + to the requested server has been reached. Once the transaction can
1.81 + be run, the handler looks for an idle connection or creates a new
1.82 + connection, and then (re)activates the connection, assigning it the
1.83 + new transaction.
1.84 +
1.85 + Once activated the connection ensures that it has a socket transport,
1.86 + and then calls AsyncWrite and AsyncRead on the socket transport. This
1.87 + begins the process of talking to the server. To minimize buffering,
1.88 + socket transport thread-proxying is completely disabled (using the flags
1.89 + DONT_PROXY_LISTENER | DONT_PROXY_PROVIDER | DONT_PROXY_OBSERVER with
1.90 + both AsyncWrite and AsyncRead). This means that the nsHttpConnection's
1.91 + OnStartRequest, OnDataAvailable, OnDataWritable, and OnStopRequest
1.92 + methods will execute on the socket transport thread.
1.93 +
1.94 + The transaction defines (non-virtual) OnDataReadable, OnDataWritable, and
1.95 + OnStopTransaction methods, which the connection calls in response to
1.96 + its OnDataAvailable, OnDataWritable, and OnStopRequest methods, respectively.
1.97 + The transaction owns a nsStreamListenerProxy created by the channel, which
1.98 + it uses to transfer data from the socket thread over to the client's thread.
1.99 + To mimize buffering, the transaction implements nsIInputStream, and passes
1.100 + itself to the stream listener proxy's OnDataAvailable. In this way, we
1.101 + have effectively wedged the response parsing between the socket and the
1.102 + thread proxy's buffer. When read, the transaction turns around and reads
1.103 + from the socket using the buffer passed to it. The transaction scans the
1.104 + buffer for headers, removes them as they are detected, and copies the headers
1.105 + into its nsHttpResponseHead object. The rest of the data remains in the
1.106 + buffer, and is proxied over to the client's thread to be handled first by the
1.107 + http channel and eventually by the client.
1.108 +
1.109 + There are several other major design factors, including:
1.110 +
1.111 + - transaction cancelation
1.112 + - progress notification
1.113 + - SSL tunneling
1.114 + - chunked decoding
1.115 + - thread safety
1.116 + - premature EOF detection and transaction restarting
1.117 + - pipelining (not yet implemented)
1.118 +
1.119 +
1.120 +CACHING
1.121 +
1.122 +<EOF>
