Name Description Size
ASpdySession.cpp Currently supported is h2 3616
ASpdySession.h 4689
AltDataOutputStreamChild.cpp stabilize 5085
AltDataOutputStreamChild.h 1715
AltDataOutputStreamParent.cpp 2131
AltDataOutputStreamParent.h 1889
AltServiceChild.cpp 3166
AltServiceChild.h 1413
AltServiceParent.cpp 2057
AltServiceParent.h 1386
AltSvcTransactionChild.cpp 2413
AltSvcTransactionChild.h 1131
AltSvcTransactionParent.cpp 2237
AltSvcTransactionParent.h 1808
AlternateServices.cpp RFC 7838 Alternative Services note that connections currently do not do mixed-scheme (the I attribute in the ConnectionInfo prevents it) but could, do not honor tls-commit and should not, and always require authentication 42596
AlternateServices.h Alt-Svc allows separation of transport routing from the origin host without using a proxy. See and Nice To Have Future Enhancements:: flush on network change event when we have an indicator use established https channel for http instead separate of conninfo hash pin via http-tls header clear based on origin when a random fail happens not just 421 upon establishment of channel, cancel and retry trans that have not yet written anything persistent storage (including private browsing filter) memory reporter for cache, but this is rather tiny 9298
BackgroundChannelRegistrar.cpp 2870
BackgroundChannelRegistrar.h 1909
BackgroundDataBridgeChild.cpp 1735
BackgroundDataBridgeChild.h 1389
BackgroundDataBridgeParent.cpp 2169
BackgroundDataBridgeParent.h 1182
CacheControlParser.cpp 3421
CacheControlParser.h 1338
CachePushChecker.cpp 8372
CachePushChecker.h 1324
ClassifierDummyChannel.cpp static 20472
ClassifierDummyChannel.h In child intercept mode, the decision to intercept a channel is made in the child process without consulting the parent process. The decision is based on whether there is a ServiceWorker with a scope covering the URL in question and whether storage is allowed for the origin/URL. When the "network.cookie.cookieBehavior" preference is set to BEHAVIOR_REJECT_TRACKER, annotated channels are denied storage which means that the ServiceWorker should not intercept the channel. However, the decision for tracking protection to annotate a channel only occurs in the parent process. The dummy channel is a hack to allow the intercept decision process to ask the parent process if the channel should be annotated. Because this round-trip to the parent has overhead, the dummy channel is only created 1) if the ServiceWorker initially determines that the channel should be intercepted and 2) it's a navigation request. This hack can be removed once Bug 1231208's new "parent intercept" mechanism fully lands, the pref is enabled by default it stays enabled for long enough to be confident we will never need/want to turn it off. Then as part of bug 1496997 we can remove this implementation. Bug 1498259 covers removing this hack in particular. 3461
ClassifierDummyChannelChild.cpp static 2721
ClassifierDummyChannelChild.h 1422
ClassifierDummyChannelParent.cpp 1697
ClassifierDummyChannelParent.h 1117
ConnectionDiagnostics.cpp 9295
DelayHttpChannelQueue.cpp 2996
DelayHttpChannelQueue.h DelayHttpChannelQueue stores a set of nsHttpChannels that are ready to fire out onto the network. However, with FuzzyFox, we can only fire those events at a specific interval, so we delay them here, in an instance of this class, until we observe the topic notificaion that we can send them outbound. 1266
Http2Compression.cpp 45580
Http2Compression.h 6464
Http2HuffmanIncoming.h THIS FILE IS AUTO-GENERATED. DO NOT EDIT! 45375
Http2Push.cpp 16014
Http2Push.h 5111
Http2Session.cpp 164998
Http2Session.h HTTP/2 framing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (16) | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +-+-------------------------------------------------------------+ | Frame Data (0...) ... +---------------------------------------------------------------+ 24254
Http2Stream.cpp 58516
Http2Stream.h 13095
Http3Session.cpp 48236
Http3Session.h 6613
Http3Stream.cpp 12086
Http3Stream.h SendStreamState: While sending request: - PREPARING_HEADERS: In this state we are collecting the headers and in some cases also waiting to be able to create a new stream. We need to read all headers into a buffer before calling Http3Session::TryActivating. Neqo may not have place for a new stream if it hits MAX_STREAMS limit. In that case the steam will be queued and dequeue when neqo can again create new stream (RequestsCreatable will be called). If transaction has data to send state changes to SENDING_BODY, otherwise the state transfers to READING_HEADERS. - SENDING_BODY: The stream will be in this state while the transaction is sending request body. Http3Session::SendRequestBody will be call to give the data to neqo. After SENDING_BODY, the state transfers to READING_HEADERS. - EARLY_RESPONSE: The server may send STOP_SENDING frame with error HTTP_EARLY_RESPONSE. That error means that the server is not interested in the request body. In this state the server will just ignore the request body. 4992
HttpAuthUtils.cpp host: pref: result: accept accept reject accept reject 4687
HttpAuthUtils.h Tries to match the given URI against the value of a given pref The pref should be in pseudo-BNF format. url-list base-url ( base-url "," LWS )* base-url ( scheme-part | host-part | scheme-part host-part ) scheme-part scheme "://" host-part host [":" port] for example: "https://," Will return true if the URI matches any of the patterns, or false otherwise. 925
HttpBackgroundChannelChild.cpp 17699
HttpBackgroundChannelChild.h 5690
HttpBackgroundChannelParent.cpp Helper class for continuing the AsyncOpen procedure on main thread. 17118
HttpBackgroundChannelParent.h 4568
HttpBaseChannel.cpp 152040
HttpBaseChannel.h This class is a partial implementation of nsIHttpChannel. It contains code shared by nsHttpChannel and HttpChannelChild. - Note that this class has nothing to do with nsBaseChannel, which is an earlier effort at a base class for channels that somehow never made it all the way to the HTTP channel. 39257
HttpChannelChild.cpp 140755
HttpChannelChild.h 24677
HttpChannelParams.ipdlh 1683
HttpChannelParent.cpp 93805
HttpChannelParent.h 16710
HttpConnectionBase.cpp 2452
HttpConnectionBase.h 9198
HttpConnectionMgrChild.cpp 5923
HttpConnectionMgrChild.h 2093
HttpConnectionMgrParent.cpp 8757
HttpConnectionMgrParent.h 1028
HttpConnectionMgrShell.h 11124
HttpConnectionUDP.cpp 25037
HttpConnectionUDP.h 4028
HttpInfo.cpp 522
HttpInfo.h Calls getConnectionData method in nsHttpConnectionMgr. 569
HttpLog.h This file should ONLY be #included by source (.cpp) files in the /http directory, not headers (.h). If you need to use LOG() in a .h file, call PR_LOG directly. This file should also be the first #include in your file. Yes, this is kludgy. ***************************************************************************** 2419
HttpTrafficAnalyzer.cpp 11452
HttpTrafficAnalyzer.h 1598 4817
HttpTransactionChild.cpp 22642
HttpTransactionChild.h 5129
HttpTransactionParent.cpp stabilize 28442
HttpTransactionParent.h 6377
HttpTransactionShell.h 10011
InterceptedChannel.cpp 11937
InterceptedChannel.h 6206
InterceptedHttpChannel.cpp 41760
InterceptedHttpChannel.h 6975
NullHttpChannel.cpp 22273
NullHttpChannel.h 1821
NullHttpTransaction.cpp 7444
NullHttpTransaction.h 3175
PAltDataOutputStream.ipdl 1252
PAltService.ipdl 1296
PAltSvcTransaction.ipdl 615
PBackgroundDataBridge.ipdl 902
PClassifierDummyChannel.ipdl 2107
PHttpBackgroundChannel.ipdl 3166
PHttpChannel.ipdl 6663
PHttpChannelParams.h 9462
PHttpConnectionMgr.ipdl 1533
PHttpTransaction.ipdl 3657
PSpdyPush.h A pushed stream is put into a memory buffer (The SpdyPushTransactionBuffer) and spooled there until a GET is made that can be matched up with it. At that time we have two spdy streams - the GET (aka the sink) and the PUSH (aka the source). Data is copied between those two streams for the lifetime of the transaction. This is true even if the transaction buffer is empty, partly complete, or totally loaded at the time the GET correspondence is made. correspondence is done through a hash table of the full url, the spdy session, and the load group. The load group is implicit because that's where the hash is stored, the other items comprise the hash key. Pushed streams are subject to aggressive flow control before they are matched with a GET at which point flow control is effectively disabled to match the client pull behavior. 2093
ParentChannelListener.cpp 15393
ParentChannelListener.h 4499
QuicSocketControl.cpp 3386
QuicSocketControl.h 1718
README Darin Fisher 4209
TRRServiceChannel.cpp 47211
TRRServiceChannel.h 6609
TimingStruct.h 1168
TunnelUtils.cpp 67158
TunnelUtils.h The input path of http over a spdy CONNECT tunnel once it is established as a stream note the "real http transaction" can be either a http/1 transaction or another spdy session inside the tunnel. nsHttpConnection::OnInputStreamReady (real socket) nsHttpConnection::OnSocketReadable() SpdySession::WriteSegment() SpdyStream::WriteSegment (tunnel stream) SpdyConnectTransaction::WriteSegment SpdyStream::OnWriteSegment(tunnel stream) SpdySession::OnWriteSegment() SpdySession::NetworkRead() nsHttpConnection::OnWriteSegment (real socket) realSocketIn->Read() return data from network now pop the stack back up to SpdyConnectTransaction::WriteSegment, the data that has been read is stored mInputData SpdyConnectTransaction.mTunneledConn::OnInputStreamReady(mTunnelStreamIn) SpdyConnectTransaction.mTunneledConn::OnSocketReadable() TLSFilterTransaction::WriteSegment() nsHttpTransaction::WriteSegment(real http transaction) TLSFilterTransaction::OnWriteSegment() removes tls on way back up stack SpdyConnectTransaction.mTunneledConn::OnWriteSegment() // gets data from mInputData SpdyConnectTransaction.mTunneledConn.mTunnelStreamIn->Read() The output path works similarly: nsHttpConnection::OnOutputStreamReady (real socket) nsHttpConnection::OnSocketWritable() SpdySession::ReadSegments (locates tunnel) SpdyStream::ReadSegments (tunnel stream) SpdyConnectTransaction::ReadSegments() SpdyConnectTransaction.mTunneledConn::OnOutputStreamReady (tunnel connection) SpdyConnectTransaction.mTunneledConn::OnSocketWritable (tunnel connection) TLSFilterTransaction::ReadSegment() nsHttpTransaction::ReadSegment (real http transaction generates plaintext on way down) TLSFilterTransaction::OnReadSegment (BUF and LEN gets encrypted here on way down) SpdyConnectTransaction.mTunneledConn::OnReadSegment (BUF and LEN) (tunnel connection) SpdyConnectTransaction.mTunneledConn.mTunnelStreamOut->Write(BUF, LEN) .. get stored in mOutputData Now pop the stack back up to SpdyConnectTransaction::ReadSegment(), where it has the encrypted text available in mOutputData SpdyStream->OnReadSegment(BUF,LEN) from mOutputData. Tunnel stream SpdySession->OnReadSegment() // encrypted data gets put in a data frame nsHttpConnection->OnReadSegment() realSocketOut->write() writes data to network ************************************************************************ 12021
WellKnownOpportunisticUtils.jsm -*- indent-tabs-mode: nil; js-indent-level: 2 -*- 820
components.conf 583
http2_huffman_table.txt 17733 5891 /* * THIS FILE IS AUTO-GENERATED. DO NOT EDIT! */ #ifndef mozilla__net__Http2HuffmanOutgoing_h #define mozilla__net__Http2HuffmanOutgoing_h namespace mozilla { namespace net { struct HuffmanOutgoingEntry { uint32_t mValue; uint8_t mLength; }; static const HuffmanOutgoingEntry HuffmanOutgoing[] = { 1480 5155
nsAHttpConnection.h 12466
nsAHttpTransaction.h Xlib headers insist on this for some reason... Nuke it because it'll override our member name 12947
nsCORSListenerProxy.cpp 55033
nsCORSListenerProxy.h 4885
nsHttp.cpp 31715
nsHttp.h 12853
nsHttpActivityDistributor.cpp 6689
nsHttpActivityDistributor.h 953
nsHttpAtomList.h This file contains the list of all HTTP atoms See nsHttp.h for access to the atoms. It is designed to be used as inline input to nsHttp.cpp *only* through the magic of C preprocessing. All entries must be enclosed in the macro HTTP_ATOM which will have cruel and unusual things done to it. The first argument to HTTP_ATOM is the C++ name of the atom. The second argument to HTTP_ATOM is the string value of the atom. **** 4056
nsHttpAuthCache.cpp 14825
nsHttpAuthCache.h 8058
nsHttpAuthManager.cpp 3869
nsHttpAuthManager.h 817
nsHttpBasicAuth.cpp 3541
nsHttpBasicAuth.h 1150
nsHttpChannel.cpp 352352
nsHttpChannel.h 36246
nsHttpChannelAuthProvider.cpp 58049
nsHttpChannelAuthProvider.h Following three methods return NS_ERROR_IN_PROGRESS when nsIAuthPrompt2.asyncPromptAuth method is called. This result indicates the user's decision will be gathered in a callback and is not an actual error. 7398
nsHttpChunkedDecoder.cpp 5247
nsHttpChunkedDecoder.h 1649
nsHttpConnection.cpp 95031
nsHttpConnection.h 12978
nsHttpConnectionInfo.cpp 18165
nsHttpConnectionInfo.h 10349
nsHttpConnectionMgr.cpp = false 203370
nsHttpConnectionMgr.h 30106
nsHttpDigestAuth.cpp 21015
nsHttpDigestAuth.h 3351
nsHttpHandler.cpp ;q=0.8" #define ACCEPT_HEADER_STYLE "text/css, 97078
nsHttpHandler.h FRAMECHECK_LAX - no check FRAMECHECK_BARELY - allows: 1) that chunk-encoding does not have the last 0-size chunk. So, if a chunked-encoded transfer ends on exactly a chunk boundary we consider that fine. This will allows us to accept buggy servers that do not send the last chunk. It will make us not detect a certain amount of cut-offs. 2) When receiving a gzipped response, we consider a gzip stream that doesn't end fine according to the gzip decompressing state machine to be a partial transfer. If a gzipped transfer ends fine according to the decompressor, we do not check for size unalignments. This allows to allow HTTP gzipped responses where the Content-Length is not the same as the actual contents. 3) When receiving HTTP that isn't content-encoded/compressed (like in case 2) and not chunked (like in case 1), perform the size comparison between Content-Length: and the actual size received and consider a mismatch to mean a NS_ERROR_NET_PARTIAL_TRANSFER error. FRAMECHECK_STRICT_CHUNKED - This is the same as FRAMECHECK_BARELY only we enforce that the last 0-size chunk is received in case 1). FRAMECHECK_STRICT - we also do not allow case 2) and 3) from FRAMECHECK_BARELY. 32734
nsHttpHeaderArray.cpp 14966
nsHttpHeaderArray.h 11067
nsHttpNTLMAuth.cpp 14216
nsHttpNTLMAuth.h 888
nsHttpRequestHead.cpp = nsHttpHeaderArray::eFilterAll 10278
nsHttpRequestHead.h 4936
nsHttpResponseHead.cpp 38032
nsHttpResponseHead.h Xlib headers insist on this for some reason... Nuke it because it'll override our member name 8502
nsHttpTransaction.cpp 89651
nsHttpTransaction.h ignored 15739
nsIBackgroundChannelRegistrar.idl Registrar for pairing HttpChannelParent and HttpBackgroundChannelParent via channel Id. HttpChannelParent::OnBackgroundParentReady and HttpBackgroundChannelParent::LinkToChannel will be invoked to notify the existence of associated channel object. 2438
nsICorsPreflightCallback.h 1094
nsIHttpActivityObserver.idl nsIHttpActivityObserver This interface provides a way for http activities to be reported to observers. 6605
nsIHttpAuthManager.idl nsIHttpAuthManager This service provides access to cached HTTP authentication user credentials (domain, username, password) for sites visited during the current browser session. This interface exists to provide other HTTP stacks with the ability to share HTTP authentication credentials with Necko. This is currently used by the Java plugin (version 1.5 and higher) to avoid duplicate authentication prompts when the Java client fetches content from a HTTP site that the user has already logged into. 4889
nsIHttpAuthenticableChannel.idl If the channel being authenticated is using SSL. 3869
nsIHttpAuthenticator.idl nsIHttpAuthenticator Interface designed to allow for pluggable HTTP authentication modules. Implementations are registered under the ContractID: ";1?scheme=<auth-scheme>" where <auth-scheme> is the lower-cased value of the authentication scheme found in the server challenge per the rules of RFC 2617. 10072
nsIHttpChannel.idl nsIHttpChannel This interface allows for the modification of HTTP request parameters and the inspection of the resulting HTTP response status and headers when they become available. 19375
nsIHttpChannelAuthProvider.idl nsIHttpChannelAuthProvider This interface is intended for providing authentication for http-style channels, like nsIHttpChannel and nsIWebSocket, which implement the nsIHttpAuthenticableChannel interface. When requesting pages AddAuthorizationHeaders MUST be called in order to get the http cached headers credentials. When the request is unsuccessful because of receiving either a 401 or 407 http response code ProcessAuthentication MUST be called and the page MUST be requested again with the new credentials that the user has provided. After a successful request, checkForSuperfluousAuth MAY be called, and disconnect MUST be called. 3032
nsIHttpChannelChild.idl 1518
nsIHttpChannelInternal.idl The callback interface for nsIHttpChannelInternal::HTTPUpgrade() 15090
nsIHttpHeaderVisitor.idl Implement this interface to visit http headers. 898
nsIHttpProtocolHandler.idl Get the HTTP advertised user agent string. 6851
nsIRaceCacheWithNetwork.idl This holds methods used to race the cache with the network for a specific channel. This interface is was designed with nsHttpChannel in mind, and it's expected this will be the only class implementing it. 2329
nsIWellKnownOpportunisticUtils.idl For parsing JSON from 754
nsServerTiming.cpp 3596
nsServerTiming.h 1322