README 4.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120
  1. Darin Fisher
  2. darin@netscape.com
  3. 8/8/2001
  4. HTTP DESIGN NOTES
  5. CLASS BREAKDOWN
  6. nsHttpHandler
  7. - implements nsIProtocolHandler
  8. - manages preferences
  9. - owns the authentication cache
  10. - holds references to frequently used services
  11. nsHttpChannel
  12. - implements nsIHttpChannel
  13. - talks to the cache
  14. - initiates http transactions
  15. - processes http response codes
  16. - intercepts progress notifications
  17. nsHttpConnection
  18. - implements nsIStreamListener & nsIStreamProvider
  19. - talks to the socket transport service
  20. - feeds data to its transaction object
  21. - routes progress notifications
  22. nsHttpConnectionInfo
  23. - identifies a connection
  24. nsHttpTransaction
  25. - implements nsIRequest
  26. - encapsulates a http request and response
  27. - parses incoming data
  28. nsHttpChunkedDecoder
  29. - owned by a transaction
  30. - removes chunked decoding
  31. nsHttpRequestHead
  32. - owns a nsHttpHeaderArray
  33. - knows how to fill a request buffer
  34. nsHttpResponseHead
  35. - owns a nsHttpHeaderArray
  36. - knows how to parse response lines
  37. - performs common header manipulations/calculations
  38. nsHttpHeaderArray
  39. - stores http "<header>:<value>" pairs
  40. nsHttpAuthCache
  41. - stores authentication credentials for http auth domains
  42. nsHttpBasicAuth
  43. - implements nsIHttpAuthenticator
  44. - generates BASIC auth credentials from user:pass
  45. ATOMS
  46. nsHttp:: (header namespace)
  47. eg. nsHttp::Content_Length
  48. TRANSACTION MODEL
  49. InitiateTransaction -> ActivateConnection -> AsyncWrite, AsyncRead
  50. The channel creates transactions, and passes them to the handler via
  51. InitiateTransaction along with a nsHttpConnectionInfo object
  52. identifying the requested connection. The handler either dispatches
  53. the transaction immediately or queues it up to be dispatched later,
  54. depending on whether or not the limit on the number of connections
  55. to the requested server has been reached. Once the transaction can
  56. be run, the handler looks for an idle connection or creates a new
  57. connection, and then (re)activates the connection, assigning it the
  58. new transaction.
  59. Once activated the connection ensures that it has a socket transport,
  60. and then calls AsyncWrite and AsyncRead on the socket transport. This
  61. begins the process of talking to the server. To minimize buffering,
  62. socket transport thread-proxying is completely disabled (using the flags
  63. DONT_PROXY_LISTENER | DONT_PROXY_PROVIDER | DONT_PROXY_OBSERVER with
  64. both AsyncWrite and AsyncRead). This means that the nsHttpConnection's
  65. OnStartRequest, OnDataAvailable, OnDataWritable, and OnStopRequest
  66. methods will execute on the socket transport thread.
  67. The transaction defines (non-virtual) OnDataReadable, OnDataWritable, and
  68. OnStopTransaction methods, which the connection calls in response to
  69. its OnDataAvailable, OnDataWritable, and OnStopRequest methods, respectively.
  70. The transaction owns a nsStreamListenerProxy created by the channel, which
  71. it uses to transfer data from the socket thread over to the client's thread.
  72. To mimize buffering, the transaction implements nsIInputStream, and passes
  73. itself to the stream listener proxy's OnDataAvailable. In this way, we
  74. have effectively wedged the response parsing between the socket and the
  75. thread proxy's buffer. When read, the transaction turns around and reads
  76. from the socket using the buffer passed to it. The transaction scans the
  77. buffer for headers, removes them as they are detected, and copies the headers
  78. into its nsHttpResponseHead object. The rest of the data remains in the
  79. buffer, and is proxied over to the client's thread to be handled first by the
  80. http channel and eventually by the client.
  81. There are several other major design factors, including:
  82. - transaction cancelation
  83. - progress notification
  84. - SSL tunneling
  85. - chunked decoding
  86. - thread safety
  87. - premature EOF detection and transaction restarting
  88. - pipelining (not yet implemented)
  89. CACHING
  90. <EOF>