| 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
http://httpwg.org/http-extensions/opsec.html
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 https://httpwg.github.io/http-extensions/alt-svc.html and
https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06
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 |
| Http2HuffmanOutgoing.h |
THIS FILE IS AUTO-GENERATED. DO NOT EDIT!
|
5272 |
| 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: bar.com foo.bar.com foobar.com foo.bar.com bar.com
pref: bar.com bar.com bar.com .bar.com .bar.com
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://, http://office.foo.com"
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 |
| HttpTrafficAnalyzer.inc |
|
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 |
| make_incoming_tables.py |
|
5891 |
| make_outgoing_tables.py |
/*
* 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 |
| moz.build |
|
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:
"@mozilla.org/network/http-authenticator;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 http://httpwg.org/http-extensions/opsec.html
|
754 |
| nsServerTiming.cpp |
|
3596 |
| nsServerTiming.h |
|
1322 |