mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
dd0c0a9a27
Bug 614677 - Connection is reset message appears intermittently Bug 614950 - Connections stall occasionally after 592284 landed A couple of follow-on changes to 592284 rolled together to prevent diff conflicts 1] Set the securitycallback information for unused speculative connections in the connection manager to be the new cloned connection rather than the one they originated on. (613977) 2] When adding unused speculative connections to the connection manager, due so with a short timeout (<= 5 seconds) as some servers get grumpy if they haven't seen a request in that time. Most will close the connection, but some will just sit there quietly and RST things when the connection is used - so if you don't use the connection quickly don't use it at all. This is probably a L4 load balancer issue, actually. Mozillazine illustrates the problem. Connections are made in bursts anyhow, so the reuse optimization is likely still quite useful. (614677 and 614950) 3] mark every connection in the connection manager persistent conneciton pool as "reused". This allows the transaction to be restarted if a RST is recvd upon sending the requests (see #2) - with the conservative timeout this is now a rare event, but still possible so recovery is the right thing to do. (614677 and 614950) 4] obtain an nshttpconnection object from the connection manager, subject to the max connection constraints, at the same time as starting the backup conneciton. If we defer that until recycling time the exceeded limits of the SocketService can cause problems for other connections. also re-enables the syn retry feature by default. r+ honzab |
||
---|---|---|
.. | ||
HttpBaseChannel.cpp | ||
HttpBaseChannel.h | ||
HttpChannelChild.cpp | ||
HttpChannelChild.h | ||
HttpChannelParent.cpp | ||
HttpChannelParent.h | ||
HttpChannelParentListener.cpp | ||
HttpChannelParentListener.h | ||
ipdl.mk | ||
Makefile.in | ||
nsAHttpConnection.h | ||
nsAHttpTransaction.h | ||
nsHttp.cpp | ||
nsHttp.h | ||
nsHttpActivityDistributor.cpp | ||
nsHttpActivityDistributor.h | ||
nsHttpAtomList.h | ||
nsHttpAuthCache.cpp | ||
nsHttpAuthCache.h | ||
nsHttpAuthManager.cpp | ||
nsHttpAuthManager.h | ||
nsHttpBasicAuth.cpp | ||
nsHttpBasicAuth.h | ||
nsHttpChannel.cpp | ||
nsHttpChannel.h | ||
nsHttpChannelAuthProvider.cpp | ||
nsHttpChannelAuthProvider.h | ||
nsHttpChunkedDecoder.cpp | ||
nsHttpChunkedDecoder.h | ||
nsHttpConnection.cpp | ||
nsHttpConnection.h | ||
nsHttpConnectionInfo.cpp | ||
nsHttpConnectionInfo.h | ||
nsHttpConnectionMgr.cpp | ||
nsHttpConnectionMgr.h | ||
nsHttpDigestAuth.cpp | ||
nsHttpDigestAuth.h | ||
nsHttpHandler.cpp | ||
nsHttpHandler.h | ||
nsHttpHeaderArray.cpp | ||
nsHttpHeaderArray.h | ||
nsHttpNTLMAuth.cpp | ||
nsHttpNTLMAuth.h | ||
nsHttpPipeline.cpp | ||
nsHttpPipeline.h | ||
nsHttpRequestHead.cpp | ||
nsHttpRequestHead.h | ||
nsHttpResponseHead.cpp | ||
nsHttpResponseHead.h | ||
nsHttpTransaction.cpp | ||
nsHttpTransaction.h | ||
nsIHttpActivityObserver.idl | ||
nsIHttpAuthenticableChannel.idl | ||
nsIHttpAuthenticator.idl | ||
nsIHttpAuthManager.idl | ||
nsIHttpChannel.idl | ||
nsIHttpChannelAuthProvider.idl | ||
nsIHttpChannelChild.idl | ||
nsIHttpChannelInternal.idl | ||
nsIHttpEventSink.idl | ||
nsIHttpHeaderVisitor.idl | ||
nsIHttpProtocolHandler.idl | ||
PHttpChannel.ipdl | ||
PHttpChannelParams.h | ||
README |
Darin Fisher darin@netscape.com 8/8/2001 HTTP DESIGN NOTES CLASS BREAKDOWN nsHttpHandler - implements nsIProtocolHandler - manages preferences - owns the authentication cache - holds references to frequently used services nsHttpChannel - implements nsIHttpChannel - talks to the cache - initiates http transactions - processes http response codes - intercepts progress notifications nsHttpConnection - implements nsIStreamListener & nsIStreamProvider - talks to the socket transport service - feeds data to its transaction object - routes progress notifications nsHttpConnectionInfo - identifies a connection nsHttpTransaction - implements nsIRequest - encapsulates a http request and response - parses incoming data nsHttpChunkedDecoder - owned by a transaction - removes chunked decoding nsHttpRequestHead - owns a nsHttpHeaderArray - knows how to fill a request buffer nsHttpResponseHead - owns a nsHttpHeaderArray - knows how to parse response lines - performs common header manipulations/calculations nsHttpHeaderArray - stores http "<header>:<value>" pairs nsHttpAuthCache - stores authentication credentials for http auth domains nsHttpBasicAuth - implements nsIHttpAuthenticator - generates BASIC auth credentials from user:pass ATOMS nsHttp:: (header namespace) eg. nsHttp::Content_Length TRANSACTION MODEL 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. There are several other major design factors, including: - transaction cancelation - progress notification - SSL tunneling - chunked decoding - thread safety - premature EOF detection and transaction restarting - pipelining (not yet implemented) CACHING <EOF>