зеркало из https://github.com/mozilla/gecko-dev.git
Backed out 3 changesets (bug 1870106, bug 1845276) for causing doc generate failures. CLOSED TREE
Backed out changeset 083ab02b4c23 (bug 1870106)
Backed out changeset aa351cb86c22 (bug 1845276)
Backed out changeset 76221decc71d (bug 1845276)
This commit is contained in:
Natalia Csoregi
Родитель
b428910e40
Коммит
eac7d668ea
|
|
@ -1,6 +1,6 @@
|
|||
# Captive Portal Detection
|
||||
# Captive portal detection
|
||||
|
||||
## What are Captive Portals?
|
||||
## What are captive portals?
|
||||
A captive portal is what we call a network that requires your action before it allows you to connect to the Internet. This action could be to log in using a username and password, or just to accept the network's terms and conditions.
|
||||
|
||||
There are many different ways in which captive portal network might attempt to direct you to the captive portal page.
|
||||
|
|
@ -60,9 +60,21 @@ pref("captivedetect.maxWaitingTime", 5000);
|
|||
pref("captivedetect.pollingTime", 3000);
|
||||
// Number of times to retry the captive portal check if there is an error or timeout.
|
||||
pref("captivedetect.maxRetryCount", 5);
|
||||
|
||||
```
|
||||
|
||||
## Connectivity checking
|
||||
|
||||
The connectivity checker might use some of the captive portal URLs.
|
||||
Refer [this](connectivity_checking.md) page for more details.
|
||||
# Connectivity checking
|
||||
We use a mechanism similar to captive portal checking to verify if the browser has internet connectivity. The [NetworkConnectivityService](https://searchfox.org/mozilla-central/source/netwerk/base/NetworkConnectivityService.h) will periodically connect to the same URL we use for captive portal detection, but will restrict its preferences to either IPv4 or IPv6. Based on which responses succeed, we can infer if Firefox has IPv4 and/or IPv6 connectivity. We also perform DNS queries to check if the system has a IPv4/IPv6 capable DNS resolver.
|
||||
|
||||
## Preferences
|
||||
|
||||
```js
|
||||
|
||||
pref("network.connectivity-service.enabled", true);
|
||||
pref("network.connectivity-service.DNSv4.domain", "example.org");
|
||||
pref("network.connectivity-service.DNSv6.domain", "example.org");
|
||||
pref("network.connectivity-service.IPv4.url", "http://detectportal.firefox.com/success.txt?ipv4");
|
||||
pref("network.connectivity-service.IPv6.url", "http://detectportal.firefox.com/success.txt?ipv6");
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
# Connectivity Checking
|
||||
We use a mechanism similar to captive portal checking to verify if the browser has internet connectivity. The [NetworkConnectivityService](https://searchfox.org/mozilla-central/source/netwerk/base/NetworkConnectivityService.h) will periodically connect to the same URL we use for captive portal detection, but will restrict its preferences to either IPv4 or IPv6. Based on which responses succeed, we can infer if Firefox has IPv4 and/or IPv6 connectivity. We also perform DNS queries to check if the system has a IPv4/IPv6 capable DNS resolver.
|
||||
|
||||
## Preferences
|
||||
|
||||
```js
|
||||
|
||||
pref("network.connectivity-service.enabled", true);
|
||||
pref("network.connectivity-service.DNSv4.domain", "example.org");
|
||||
pref("network.connectivity-service.DNSv6.domain", "example.org");
|
||||
pref("network.connectivity-service.IPv4.url", "http://detectportal.firefox.com/success.txt?ipv4");
|
||||
pref("network.connectivity-service.IPv6.url", "http://detectportal.firefox.com/success.txt?ipv6");
|
||||
|
||||
```
|
||||
|
|
@ -86,7 +86,7 @@ is an NS record for its parent domain, in which case we add that to the
|
|||
blocklist. This feature is controlled by the
|
||||
_network.trr.temp\_blocklist_ pref.
|
||||
|
||||
## TRR Confirmation
|
||||
## TRR confirmation
|
||||
|
||||
TRR requests normally have a 1.5 second timeout. If for some reason we
|
||||
do not get a response in that time we fall back to Do53. To avoid this
|
||||
|
|
@ -125,7 +125,7 @@ _HandleConfirmationEvent_ method in _TRRService.cpp_
|
|||
If strict fallback mode is enabled, Confirmation will set a flag to
|
||||
refresh our connection to the provider.
|
||||
|
||||
## Excluded Domains
|
||||
## Excluded domains
|
||||
|
||||
Some domains will never be resolved via TRR. This includes:
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ Detection is performed in DoHHeuristics.jsm followed by a call to
|
|||
_TRRService::SetDetectedURI_. This causes Firefox to use the
|
||||
network specific TRR provider until a network change occurs.
|
||||
|
||||
## User Choice
|
||||
## User choice
|
||||
|
||||
The TRR feature is designed to prioritize user choice before user agent
|
||||
decisions. That means the user may explicitly disable TRR by setting
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Http3Session and Streams
|
||||
# Http3Session and streams
|
||||
|
||||
The HTTP/3 and QUIC protocol are implemented in the neqo library. Http3Session, Http3Steam, and Http3WebTransportStream are added to integrate the library into the existing necko code.
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ graph TD
|
|||
B --> G
|
||||
```
|
||||
|
||||
## Interactions with Sockets and Driving Neqo
|
||||
## Interactions with sockets and driving neqo
|
||||
|
||||
As described in [this docs](https://github.com/mozilla/neqo/blob/main/neqo-http3/src/lib.rs), neqo does not create a socket, it produces, i.e. encodes, data that should be sent as a payload in a UDP packet and consumes data received on the UDP socket. Therefore the necko is responsible for creating a socket and reading and writing data from/into the socket. Necko uses nsUDPSocket and nsSocketTransportService for this.
|
||||
The UDP socket is constantly polled for reading. It is not polled for writing, we let QUIC control to not overload the network path and buffers.
|
||||
|
|
@ -71,7 +71,7 @@ The function is called when necko has performed some action on neqo, e.g. new HT
|
|||
- ProcessEvents - look if the state of the connection has changed, i.e. the connection timed out
|
||||
|
||||
|
||||
## HTTP and WebTransport Streams Reading Data
|
||||
## HTTP and WebTransport Streams reading data
|
||||
|
||||
The following diagram shows how data are read from an HTTP stream. The diagram for a WebTransport stream will be added later.
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ When the pipe cannot accept more data nsHttpTransaction will call nsPipeOutputSt
|
|||
|
||||
These streams will be processed in ProcessSlowConsumers which is called by Http3Session::RecvData.
|
||||
|
||||
## HTTP and WebTransport Streams Writing Data
|
||||
## HTTP and WebTransport Streams writing data
|
||||
|
||||
The following diagram shows how data are sent from an HTTP stream. The diagram for a WebTransport stream will be added later.
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ When a nsHttpTransaction has been newly added to a transaction or when nsHttpTra
|
|||
|
||||
The Http3Session::SendData function iterates through mReadyForWrite and calls Http3Stream::ReadSegments for each stream.
|
||||
|
||||
## Neqo Events
|
||||
## Neqo events
|
||||
|
||||
For **HeaderReady** and **DataReadable** the Http3Stream::WriteSegments function of the corresponding stream is called. The code path shown in the flowchart above will call the nssHttpTransaction served by the stream to take headers and data.
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ For **HeaderReady** and **DataReadable** the Http3Stream::WriteSegments function
|
|||
|
||||
**ConnectionConnected**, **GoawayReceived**, **ConnectionClosing** and **ConnectionClosed** expose change in the connection state. Difference between **ConnectionClosing** and **ConnectionClosed** that after **ConnectionClosed** the connection can be immediately closed and after **ConnectionClosing** we will keep the connection object for a short time until **ConnectionClosed** event is received. During this period we will retransmit the closing frame if they are lost.
|
||||
|
||||
### WebTransport Events
|
||||
### WebTransport events
|
||||
|
||||
**Negotiated** - WebTransport is negotiated only after the HTTP/3 settings frame has been received from the server. At that point **Negotiated** event is posted to inform the application.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
The Lifecycle of a HTTP Request
|
||||
The lifecycle of a HTTP request
|
||||
===============================
|
||||
|
||||
|
||||
HTTP requests in Firefox go through several steps. Each piece of the request message and response message become available at certain points. Extracting that information is a challenge, though.
|
||||
|
||||
What is Available When
|
||||
What is available when
|
||||
----------------------
|
||||
|
||||
+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
|
||||
|
|
@ -28,7 +28,7 @@ What is Available When
|
|||
|| || || || nsIPipe_ || |
|
||||
+-----------------------+---------------------------------------------------+---------------------------------------+------------------------+-------------------------------+
|
||||
|
||||
The Request: http-on-modify-request
|
||||
The request: http-on-modify-request
|
||||
-----------------------------------
|
||||
|
||||
Firefox fires a "http-on-modify-request" observer notification before sending the HTTP request, and this blocks the sending of the request until all observers exit. This is generally the point at which you can modify the HTTP request headers (hence the name).
|
||||
|
|
@ -79,7 +79,7 @@ This is also the time to set request headers, if you need to. The method for th
|
|||
|
||||
Most HTTP requests don't have a body, as they are GET requests. POST requests often have them, though. As the nsIUploadChannel_ documentation indicates, the body of most HTTP requests is available via a seekable stream (nsISeekableStream_). So you can simply capture the body stream and its current position, to revisit it later. network-helper.js_ has code to read the request body.
|
||||
|
||||
The Response: http-on-examine-response
|
||||
The response: http-on-examine-response
|
||||
--------------------------------------
|
||||
|
||||
Firefox fires a "http-on-examine-response" observer notification after parsing the HTTP response status and headers, but **before** reading the response body. Attaching a listener for this phase is also very easy::
|
||||
|
|
@ -90,7 +90,7 @@ If you use the same observer for "http-on-modify-request" and "http-on-examine-r
|
|||
|
||||
The response status is available via the *responseStatus* and *responseStatusText* properties. The response headers are available via the *visitResponseHeaders* method, and requires the same interface.
|
||||
|
||||
The Response body: onStopRequest, stream listener tee
|
||||
The response body: onStopRequest, stream listener tee
|
||||
-----------------------------------------------------
|
||||
|
||||
During the "http-on-examine-response" notification, the response body is *not* available. You can, however, use a stream listener tee to *copy* the stream so that the original stream data goes on, and you have a separate input stream you can read from with the same data.
|
||||
|
|
@ -177,19 +177,19 @@ Here's some sample code to illustrate what you need::
|
|||
|
||||
test_traceable_channel.js_ does essentially this.
|
||||
|
||||
Character Encodings and Compression
|
||||
Character encodings and compression
|
||||
-----------------------------------
|
||||
|
||||
Canceling Requests
|
||||
Canceling requests
|
||||
------------------
|
||||
|
||||
HTTP Activity Distributor Notes
|
||||
HTTP activity distributor notes
|
||||
-------------------------------
|
||||
|
||||
URIContentLoader Notes
|
||||
URIContentLoader notes
|
||||
----------------------
|
||||
|
||||
Order of Operations
|
||||
Order of operations
|
||||
-------------------
|
||||
|
||||
1. The HTTP channel is constructed.
|
||||
|
|
@ -200,7 +200,7 @@ Order of Operations
|
|||
6. The HTTP channel parses the response status and headers.
|
||||
7. The "http-on-examine-response" observer service notification fires.
|
||||
|
||||
Useful Code Samples and References
|
||||
Useful code samples and references
|
||||
----------------------------------
|
||||
|
||||
- nsIHttpProtocolHandler_ defines a lot of observer topics, and has a lot of details.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
HTTP Server for Unit Tests
|
||||
HTTP server for unit tests
|
||||
==========================
|
||||
|
||||
This page describes the JavaScript implementation of an
|
||||
HTTP server located in ``netwerk/test/httpserver/``.
|
||||
|
||||
Server Functionality
|
||||
Server functionality
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Here are some of the things you can do with the server:
|
||||
|
|
@ -23,7 +23,7 @@ Here are some of the things you can do with the server:
|
|||
This functionality should be more than enough for you to use it with any
|
||||
test which requires HTTP-provided behavior.
|
||||
|
||||
Where You Can Use It
|
||||
Where you can use it
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The server is written primarily for use from ``xpcshell``-based
|
||||
|
|
@ -33,7 +33,7 @@ Mochitest framework also uses it to serve its tests, and
|
|||
can optionally use it when their behavior is dependent upon specific
|
||||
HTTP header values.
|
||||
|
||||
Ways You Might Use It
|
||||
Ways you might use it
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- application update testing
|
||||
|
|
@ -52,7 +52,7 @@ Ways You Might Use It
|
|||
many purposes like : file/data storage, social sharing and so on
|
||||
- download testing
|
||||
|
||||
Using the Server
|
||||
Using the server
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The best and first place you should look for documentation is
|
||||
|
|
@ -63,7 +63,7 @@ less-comprehensive server
|
|||
`README <https://searchfox.org/mozilla-central/source/netwerk/test/httpserver/README>`__,
|
||||
although the IDL should usually be sufficient.
|
||||
|
||||
Running the Server
|
||||
Running the server
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
From test suites, the server should be importable as a testing-only JS
|
||||
|
|
@ -104,7 +104,7 @@ However, this should only be used as the last possible option.
|
|||
you'll make people running tests grumbly because you've broken the
|
||||
tests.
|
||||
|
||||
Debugging Errors
|
||||
Debugging errors
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The server's default error pages don't give much information, partly
|
||||
|
|
@ -120,7 +120,7 @@ determine why problems exist from that output. ``DEBUG`` is ``false`` by
|
|||
default because the information printed with it set to ``true``
|
||||
unnecessarily obscures tinderbox output.
|
||||
|
||||
Header Modification for Files
|
||||
Header modification for files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The server supports modifying the headers of the files (not request
|
||||
|
|
@ -138,7 +138,7 @@ standard HTTP format. Any line ending style is accepted, and the file
|
|||
may optionally end with a single newline character, to play nice with
|
||||
Unix text tools like ``diff`` and ``hg``.
|
||||
|
||||
Hidden Files
|
||||
Hidden files
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Any file which ends with a single ``^`` is inaccessible when querying
|
||||
|
|
@ -153,7 +153,7 @@ modification for files into the file system without making those files
|
|||
accessible to clients; it remains to be seen whether and how hidden-file
|
||||
capabilities will otherwise be used.
|
||||
|
||||
SJS: Server-Side Scripts
|
||||
SJS: server-side scripts
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Support for server-side scripts is provided through the SJS mechanism.
|
||||
|
|
@ -189,7 +189,7 @@ Please refer to the `IDL
|
|||
documentation <https://searchfox.org/mozilla-central/source/netwerk/test/httpserver/nsIHttpServer.idl>`
|
||||
for more details.
|
||||
|
||||
Storing Information Across Requests
|
||||
Storing information across requests
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
HTTP is basically a stateless protocol, and the httpd.js server API is
|
||||
|
|
@ -350,7 +350,7 @@ object values when called within the sandbox. However, such functions
|
|||
can accept and call callback functions, so we simply use a callback
|
||||
function here to return the object value associated with the key.
|
||||
|
||||
Advanced Dynamic Response Creation
|
||||
Advanced dynamic response creation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The default behavior of request handlers is to fully construct the
|
||||
|
|
@ -396,7 +396,7 @@ Full documentation for ``processAsync()`` and its interactions with
|
|||
other methods may, as always, be found in
|
||||
``netwerk/test/httpserver/nsIHttpServer.idl``.
|
||||
|
||||
Manual, Arbitrary Response Creation
|
||||
Manual, arbitrary response creation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The standard mode of response creation is fully synchronous and is
|
||||
|
|
@ -449,7 +449,7 @@ Full documentation for ``seizePower()`` and its interactions with other
|
|||
methods may, as always, be found in
|
||||
``netwerk/test/httpserver/nsIHttpServer.idl``.
|
||||
|
||||
Example Uses of the Server
|
||||
Example uses of the server
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Shorter examples (for tests which only do one test):
|
||||
|
|
@ -469,7 +469,7 @@ Longer tests (where you'd need to do multiple async server requests):
|
|||
Examples of modifying HTTP headers in files may be found at
|
||||
``netwerk/test/httpserver/test/data/cern_meta/``.
|
||||
|
||||
Future Directions
|
||||
Future directions
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The server, while very functional, is not yet complete. There are a
|
||||
|
|
|
|||
|
|
@ -2,27 +2,28 @@
|
|||
|
||||
The Necko (aka Networking) component is Gecko's implementation of the web's networking protocols.
|
||||
Most of the component's source lives in `netwerk` directory and this document's source can be found in `netwerk/docs`.
|
||||
This page points to helpful resources for developers interested in contributing to Necko.
|
||||
|
||||
Necko's [wiki page](https://wiki.mozilla.org/Networking) is dedicated to help users of firefox and bug authors. Readers can find various information related to bug filing, configuration of various networking features in the wiki page.
|
||||
|
||||
|
||||
|
||||
This page mostly just points to helpful resources for contributing to and understanding Necko.
|
||||
More details can be found on [Necko's wiki](https://wiki.mozilla.org/Networking).
|
||||
The team can be reached:
|
||||
* on Matrix: [#necko:mozilla.org](https://chat.mozilla.org/#/room/#necko:mozilla.org)
|
||||
* by email: necko@mozilla.com
|
||||
* or by submitting a `Core::Networking` bug on [bugzilla.mozilla.org](https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking)
|
||||
|
||||
## How-to's
|
||||
## Contributing to Necko
|
||||
```{toctree}
|
||||
:maxdepth: 1
|
||||
http/logging
|
||||
submitting_networking_bugs.md
|
||||
captive_portals.md
|
||||
connectivity_checking.md
|
||||
```
|
||||
|
||||
## Tutorials
|
||||
## Team resources
|
||||
```{toctree}
|
||||
:maxdepth: 1
|
||||
new_to_necko_resources
|
||||
neqo_triage_guideline.md
|
||||
```
|
||||
|
||||
## Testing
|
||||
```{toctree}
|
||||
:maxdepth: 1
|
||||
network_test_guidelines.md
|
||||
|
|
@ -30,32 +31,16 @@ http_server_for_testing
|
|||
mochitest_with_http3.md
|
||||
```
|
||||
|
||||
## Deep Dives
|
||||
### Necko Design
|
||||
```{toctree}
|
||||
:maxdepth: 1
|
||||
sec-necko-components.md
|
||||
cache2/doc
|
||||
http/http3.md
|
||||
Necko Bird’s-eye View <https://docs.google.com/presentation/d/1BRCK4WMYg-dUy07PB5H4jFVTpc4YnkQX8f5Y3KXqCs8>
|
||||
Gecko HTTP Walkthrough <https://docs.google.com/presentation/d/1iuYNLJfz24MN9SS5ljjhG07452-kZKtXmOeGjcc1-lU/>
|
||||
```
|
||||
|
||||
### Necko Features
|
||||
## Component/Feature details
|
||||
```{toctree}
|
||||
:maxdepth: 1
|
||||
http/lifecycle
|
||||
sec-necko-components.md
|
||||
cache2/doc
|
||||
http/http3.md
|
||||
dns/dns-over-https-trr
|
||||
url_parsers.md
|
||||
webtransport/webtransport
|
||||
captive_portals.md
|
||||
early_hints.md
|
||||
```
|
||||
|
||||
## References
|
||||
```{toctree}
|
||||
:maxdepth: 1
|
||||
new_to_necko_resources
|
||||
neqo_triage_guideline.md
|
||||
necko_lingo.md
|
||||
```
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Introduction to Mochitest framework with HTTP/2 and HTTP/3 Support
|
||||
# Introduction to Mochitest framework with HTTP/2 and HTTP/3 support
|
||||
|
||||
The Mochitest framework currently utilizes [httpd.js](https://searchfox.org/mozilla-central/source/netwerk/test/httpserver/httpd.js) as its primary HTTP server, which only provides support for HTTP/1.1. To boost our testing capacity for HTTP/2 and HTTP/3 within necko, we improved the Mochitest framework to enable Firefox to connect to the test server using HTTP/2 or HTTP/3 while running Mochitest files.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ For HTTP/3 testing, switch the option to `--use-http3-server`. Like this:
|
|||
./mach mochitest --use-http3-server PATH_TO_TEST_FILE
|
||||
```
|
||||
|
||||
### Reasons for Skipped Tests
|
||||
### Reasons for skipped tests
|
||||
|
||||
We have several tests that are currently failing with HTTP/2 and HTTP/3 servers and they are skipped for now. There are a few reasons contributing to these failures:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,241 +0,0 @@
|
|||
# Necko Lingo<!-- omit from toc -->
|
||||
#### Words We Keep Throwing Around Like Internet Confetti<!-- omit from toc -->
|
||||
|
||||
- [B](#b)
|
||||
- [Background Thread](#background-thread)
|
||||
- [C](#c)
|
||||
- [Channel](#channel)
|
||||
- [Child Process](#child-process)
|
||||
- [Content Process](#content-process)
|
||||
- [D](#d)
|
||||
- [DoH](#doh)
|
||||
- [E](#e)
|
||||
- [Eventsource](#eventsource)
|
||||
- [Electrolysis](#electrolysis)
|
||||
- [F](#f)
|
||||
- [Fetch](#fetch)
|
||||
- [Fetch API](#fetch-api)
|
||||
- [Fission](#fission)
|
||||
- [H](#h)
|
||||
- [H1/H2/H3](#h1h2h3)
|
||||
- [Happy eyeballs](#happy-eyeballs)
|
||||
- [HSTS](#hsts)
|
||||
- [L](#l)
|
||||
- [LoadInfo](#loadinfo)
|
||||
- [Listener](#listener)
|
||||
- [M](#m)
|
||||
- [MainThread](#mainthread)
|
||||
- [Mochitest](#mochitest)
|
||||
- [N](#n)
|
||||
- [neqo v/s Necko](#neqo-vs-necko)
|
||||
- [NSS](#nss)
|
||||
- [NSPR](#nspr)
|
||||
- [P](#p)
|
||||
- [PSM](#psm)
|
||||
- [Parent Process](#parent-process)
|
||||
- [Principal](#principal)
|
||||
- [O](#o)
|
||||
- [OMT](#omt)
|
||||
- [OnStartRequest/OnDataAvailable/OnStopRequest/](#onstartrequestondataavailableonstoprequest)
|
||||
- [Q](#q)
|
||||
- [QUIC](#quic)
|
||||
- [R](#r)
|
||||
- [RCWN](#rcwn)
|
||||
- [S](#s)
|
||||
- [Socket Process](#socket-process)
|
||||
- [Socket Thread](#socket-thread)
|
||||
- [SOCKS Proxy](#socks-proxy)
|
||||
- [T](#t)
|
||||
- [TLS](#tls)
|
||||
- [Triage](#triage)
|
||||
- [TRR](#trr)
|
||||
- [W](#w)
|
||||
- [WebSocket](#websocket)
|
||||
- [WebTransport](#webtransport)
|
||||
- [Xpcshell-tests](#xpcshell-tests)
|
||||
- [XHR](#xhr)
|
||||
|
||||
|
||||
|
||||
|
||||
#### Background Thread
|
||||
Any thread that is not main thread.\
|
||||
Or this thread created [here](https://searchfox.org/mozilla-central/rev/23e7e940337d0e0b29aabe0080e4992d3860c940/ipc/glue/BackgroundImpl.cpp#880) for PBackground for IPC\
|
||||
Usually threads either have a dedicated name but background threads might also refer to the background thread pool: [NS_DispatchBackgroundTask](https://searchfox.org/mozilla-central/rev/23e7e940337d0e0b29aabe0080e4992d3860c940/xpcom/threads/nsThreadUtils.cpp#516).
|
||||
|
||||
#### Channel
|
||||
See [nsIChannel.idl](https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/netwerk/base/nsIChannel.idl).
|
||||
It usually means nsHttpChannel.
|
||||
|
||||
#### Child Process
|
||||
Usually a firefox forked process - not the main process.\
|
||||
See [GeckoProcessTypes.h](https://searchfox.org/mozilla-central/source/__GENERATED__/xpcom/build/GeckoProcessTypes.h) for all process types in gecko.
|
||||
|
||||
#### Content Process
|
||||
Usually a firefox forked process running untrusted web content.
|
||||
|
||||
#### DoH
|
||||
[DNS](https://developer.mozilla.org/en-US/docs/Glossary/DNS) over HTTPS.\
|
||||
Refer [RFC 8484 - DNS Queries over HTTPS (DoH)](https://datatracker.ietf.org/doc/html/rfc8484).\
|
||||
Resolves DNS names by using a HTTPS server.\
|
||||
https://firefox-source-docs.mozilla.org/networking/dns/dns-over-https-trr.html
|
||||
|
||||
#### Eventsource
|
||||
Web API for [server-sent-events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events). \
|
||||
Refer https://developer.mozilla.org/en-US/docs/Web/API/EventSource. \
|
||||
Necko is responsible for maintaining part of this code along with DOM.
|
||||
|
||||
|
||||
|
||||
#### Electrolysis
|
||||
Also known as E10S (E + 10 chars + S).\
|
||||
The process to make web content run in its own process.\
|
||||
Extended by the ‘Fission’ project, which introduced isolation for sites (really [eTLD+1’s](https://developer.mozilla.org/en-US/docs/Glossary/eTLD)).\
|
||||
Refer https://wiki.mozilla.org/Electrolysis for more details.
|
||||
|
||||
#### Fetch
|
||||
[Fetch](https://fetch.spec.whatwg.org/) standard [aims](https://fetch.spec.whatwg.org/#goals) specifies standard for fetching resources across web. \
|
||||
Fetch and [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) slightly different things.
|
||||
|
||||
#### Fetch API
|
||||
[Web API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) for fetching resources from the web.
|
||||
The code is jointly maintained by DOM team and Necko team
|
||||
|
||||
#### Fission
|
||||
Similar to Electrolysis, but different domains ([eTLD+1’s](https://developer.mozilla.org/en-US/docs/Glossary/eTLD)) get their own content process to avoid [Spectre attacks](https://meltdownattack.com/). \
|
||||
Max 4 processes per [eTLD+1](https://developer.mozilla.org/en-US/docs/Glossary/eTLD). \
|
||||
Iframes get isolated from the parent. \
|
||||
Also referred to as origin isolation. \
|
||||
|
||||
#### H1/H2/H3
|
||||
HTTP version: 0.9 / 1.0 / 1.1 / 2 / 3.
|
||||
|
||||
#### Happy Eyeballs
|
||||
RFC 6555/8305 – connecting via IPv4 and IPv6 simultaneously. \
|
||||
We implement this in a [different](https://searchfox.org/mozilla-central/rev/23e7e940337d0e0b29aabe0080e4992d3860c940/netwerk/protocol/http/DnsAndConnectSocket.cpp#202-206). \
|
||||
|
||||
#### HSTS
|
||||
HTTP [Strict Transport Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security). \
|
||||
HSTS preload - a list of websites that will be upgraded to HTTPS without first needing a response.
|
||||
|
||||
|
||||
#### LoadInfo
|
||||
Object containing information about about the load (who triggered the load, in which context, etc).
|
||||
Refer [nsILoadContext](https://searchfox.org/mozilla-central/source/netwerk/base/nsILoadContextInfo.idl) for more details.
|
||||
|
||||
|
||||
#### Listener
|
||||
In async programming, we usually trigger an action, and set a listener to receive the result. \
|
||||
In necko it’s most usually referring to the listener of a channel, which is an object implementing [nsIStreamListener](https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/netwerk/base/nsIStreamListener.idl) and/or [nsIRequestObserver](https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/netwerk/base/nsIRequestObserver.idl#14).
|
||||
|
||||
|
||||
#### MainThread
|
||||
Every process has a MainThread, which is also the master event loop for the process. \
|
||||
Many things are scoped to run on MainThread (DispatchToMainThread, etc).\
|
||||
For content processes, MainThread is where normal JS content runs ([Worker](https://developer.mozilla.org/en-US/docs/Web/API/Worker) JavaScript runs on DOM Worker threads).
|
||||
|
||||
|
||||
#### Mochitest
|
||||
Browser tests, run with full UI. \
|
||||
Refer [this](https://firefox-source-docs.mozilla.org/testing/mochitest-plain/index.html) for more details.
|
||||
|
||||
#### neqo v/s Necko
|
||||
_neqo_ is the name of the Mozilla QUIC stack, i.e., https://github.com/mozilla/neqo.
|
||||
Sometimes pronounced “knee-ko” or “neck-ou”, “knee-q-oo”.
|
||||
|
||||
_Necko_ is the project name of the Mozilla networking stack.
|
||||
|
||||
|
||||
#### NSS
|
||||
An acronym for the Network Security Services.
|
||||
Refer [this](https://firefox-source-docs.mozilla.org/security/nss/index.html) for more details.
|
||||
|
||||
|
||||
#### NSPR
|
||||
An acronym for [Netscape Portable Runtime](https://firefox-source-docs.mozilla.org/nspr/index.html)
|
||||
Necko’s scope?
|
||||
|
||||
#### Observer
|
||||
Terminology used for referring the classes implementing the Observer design pattern. \
|
||||
Refer the following interfaces for more details:
|
||||
- [nsIObserver](https://searchfox.org/mozilla-central/source/xpcom/ds/nsIObserver.idl)
|
||||
- [nsIObserverService](https://searchfox.org/mozilla-central/source/xpcom/ds/nsIObserverService.idl)
|
||||
|
||||
#### PSM
|
||||
The PSM acronym may also be described as "Platform Security Module". \
|
||||
Glue code between Gecko and NSS. \
|
||||
Refer [this](https://wiki.mozilla.org/PSM:Topics) for more details.
|
||||
|
||||
|
||||
#### Parent Process
|
||||
The process that runs the main structure of the browser, including the UI.
|
||||
It spawns the other processes needed for the browser. \
|
||||
Generally it is unrestricted, while most other processes have some level of sandboxing of permissions applied. \
|
||||
Before e10s, all code ran in the Parent Process.
|
||||
|
||||
### Principal
|
||||
Abstraction encapsulating security details of a web page.
|
||||
Refer the following links for more details:
|
||||
- [sec-necko-components](https://firefox-source-docs.mozilla.org/networking/sec-necko-components.html)
|
||||
- [nsIPrincipal](https://searchfox.org/mozilla-central/source/caps/nsIPrincipal.idl)
|
||||
|
||||
#### OMT
|
||||
Abbreviation for Off Main Thread. OMT refers to processing data in non-main thread.
|
||||
There has been efforts in the past to move the processing of data to non-main thread to free up main thread resources.
|
||||
|
||||
|
||||
#### OnStartRequest/OnDataAvailable/OnStopRequest/
|
||||
- OnStartRequest is listener notification sent when the necko has parsed the status and the header.
|
||||
- OnDataAvailable is a listener notification sent when necko has received the the data/body.
|
||||
- OnStopRequest is a listener notification sent when necko has received the complete response.
|
||||
- Refer to the following interface documentation for more details:
|
||||
- [nsIRequestObserver](https://searchfox.org/mozilla-central/source/netwerk/base/nsIRequestObserver.idl)
|
||||
- [nsIStreamListener.idl](https://searchfox.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl)
|
||||
|
||||
#### QUIC
|
||||
An IETF transport protocol [RFC9000](https://datatracker.ietf.org/doc/html/rfc9000) primarily designed to carry HTTP/3, but now also used as a general-purpose Internet transport protocol for other workloads.
|
||||
Implemented in RUST and maintained by [neqo](https://github.com/mozilla/neqo).
|
||||
|
||||
#### RCWN
|
||||
Race cache with network. Feature that will send a request to network and cache at the same time and take the first to resolve.
|
||||
|
||||
#### Socket Process
|
||||
WIP project to move the actions of the socket thread into its own process for the purposes of isolation for security and stability (during crashes).
|
||||
|
||||
#### Socket Thread
|
||||
From the main process, a thread that handles opening and reading from the sockets for network communication. \
|
||||
We also use socket thread in content process for PHttpBackgroundChannel.ipdl
|
||||
|
||||
#### SOCKS Proxy
|
||||
https://datatracker.ietf.org/doc/html/rfc1928
|
||||
|
||||
#### TLS
|
||||
Transport Layer Security. It’s implementation is maintained by NSS team.
|
||||
|
||||
#### Triage
|
||||
Team process of bug intake, analysis and categorization.
|
||||
|
||||
#### TRR
|
||||
Trusted recursive resolver.This is the name of our DoH implementation, as well as the name of the program that ensures DoH providers included in Firefox have agreed not to spy on users. \
|
||||
Refer the following for more details:
|
||||
- [Trusted_Recursive_Resolver](https://wiki.mozilla.org/Trusted_Recursive_Resolver)
|
||||
- [DOH-resolver-policy](https://wiki.mozilla.org/Security/DOH-resolver-policy)
|
||||
|
||||
#### WebSocket
|
||||
Server/client connections over TCP to pass data. A replacement for long-poll HTTP connection. \
|
||||
Refer [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455) and [whatwg spec](https://websockets.spec.whatwg.org/).
|
||||
|
||||
|
||||
#### WebTransport
|
||||
A mechanism similar to WebSockets to transfer data between server and client, but built for HTTP/3; can also run over HTTP/2 (being implemented in gecko). \
|
||||
References:
|
||||
- [MDN Documentation on WebTransport](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport)
|
||||
- [WebTransport RFC Draft](https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/)
|
||||
|
||||
#### Xpcshell-tests
|
||||
Unit tests for testing our XPCOM code from JS context.
|
||||
Runs without a UI in a simpler setup (typically single-process). \
|
||||
Refer [firefox-source-docs](https://firefox-source-docs.mozilla.org/testing/xpcshell/index.html) for detailed explanation.
|
||||
|
||||
#### XHR
|
||||
[XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest). One way to perform AJAX, essentially a way to dynamically make network requests for use in the callers webpage, similar to Fetch.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Neqo Triage Guideline
|
||||
# Neqo triage guideline
|
||||
|
||||
[Neqo](https://github.com/mozilla/neqo/issues) has p1, p2, and p3 labels that correspond to the following Bugzilla labels:
|
||||
- p1 - the issue should be fixed as soon as possible because it is a defect or a fix has been planned for a project.
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ There are also [web-platform-tests](https://firefox-source-docs.mozilla.org/web-
|
|||
Note that it's not usually a good idea to enabling logging when running all tests in a folder on try, since the raw log file can be really huge. The log file might be not available if the size exceeds the limit on try.
|
||||
In the case that your code change is too generic or you are not sure which tests to run, you can use [Auto Selector](https://firefox-source-docs.mozilla.org/tools/try/selectors/auto.html) to let it select tests for you.
|
||||
|
||||
## Debugging Intermittent Test Failures
|
||||
## Debugging intermittent test failures
|
||||
|
||||
There are a lot of intermittent failures on try (usually not able to reproduce locally). Debugging these failures can be really annoying and time consuming. Here are some general guidelines to help you debug intermittent failures more efficiently.
|
||||
|
||||
|
|
@ -100,7 +100,7 @@ There are a lot of intermittent failures on try (usually not able to reproduce l
|
|||
```
|
||||
- In the case that we really need to debug an intermittent test failure, see this [document](https://firefox-source-docs.mozilla.org/devtools/tests/debugging-intermittents.html) first for some general tips. Unfortunately, there is no easy way to debug this. One can try to isolate the failed test first and enable `HTTP logging` on try to collect the log for further analysis.
|
||||
|
||||
## Writing Necko XPCShell Tests
|
||||
## Writing Necko XPCShell tests
|
||||
|
||||
The most typical form of necko xpcsehll-test is creating an HTTP server and test your code by letting the server return some specific responses (e.g., `103 Early Hint`). We will only introduce how to write this kind of test in this document.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Submitting Actionable Networking Bugs
|
||||
# Submitting actionable networking bugs
|
||||
|
||||
So you've found a networking issue with Firefox and decided to file a bug. First of all **Thanks!**. 🎉🎉🎉
|
||||
|
||||
## Networking Bugs Lifecycle
|
||||
## Networking bugs lifecycle
|
||||
|
||||
After a bug is filed, it gets triaged by one of the Necko team members.
|
||||
The engineer will consider the *steps to reproduce* then will do one of the following:
|
||||
|
|
@ -25,7 +25,7 @@ possible in the bug report.
|
|||
</div>
|
||||
|
||||
|
||||
## Make Sure it's a Firefox Bug
|
||||
## Make sure it's a Firefox bug
|
||||
|
||||
Sometimes a website may be misbehaving and you'll initially think it's caused by a bug in Firefox. However, extensions and other customizations could also cause an issue. Here are a few things to check before submitting the bug:
|
||||
- [Troubleshoot extensions, themes and hardware acceleration issues to solve common Firefox problems](https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems#w_start-firefox-in-troubleshoot-mode)
|
||||
|
|
@ -35,7 +35,7 @@ Sometimes a website may be misbehaving and you'll initially think it's caused by
|
|||
- Make sure to include the contents of `about:support` in your bug report.
|
||||
- Check if the bug also happens in other browsers
|
||||
|
||||
## Make Sure the Bug has Clear Steps to Reproduce
|
||||
## Make sure the bug has clear steps to reproduce
|
||||
|
||||
This is one of the most important requirements of getting the bug fixed. Clear steps to reproduce will help the engineer figure out what the problem is.
|
||||
If the bug can only be reproduced on a website that requires authentication you may provide a test account to the engineer via private email.
|
||||
|
|
@ -57,7 +57,7 @@ It's still important to report these bugs but they should include additional inf
|
|||
3. Go to `http://localhost:8888/test` and click the button
|
||||
```
|
||||
|
||||
## Additional Questions
|
||||
## Additional questions
|
||||
|
||||
- Are you using a proxy? What kind?
|
||||
- Are you using DNS-over-HTTPS?
|
||||
|
|
@ -73,7 +73,7 @@ First you need to [install the tool](https://mozilla.github.io/mozregression/ins
|
|||
|
||||
At the end you will be presented with a regression range that includes the commits that introduced the bug.
|
||||
|
||||
## Performance Issues
|
||||
## Performance issues
|
||||
|
||||
If you're seeing a performance issue (site is very slow to load, etc) you should consider submitting a performance profile.
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ If something you're doing is causing a crash, having the link to the stack trace
|
|||
- Go to `about:crashes`
|
||||
- Paste the **Report ID** of the crash in the bug.
|
||||
|
||||
## HTTP Logs
|
||||
## HTTP logs
|
||||
|
||||
See the [HTTP Logging](https://firefox-source-docs.mozilla.org/networking/http/logging.html) page for steps to capture HTTP logs.
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ If the logs are large you can create a zip archive and attach them to the bug. I
|
|||
|
||||
Logs may include personal information such as cookies. Try using a fresh Firefox profile to capture the logs. If that is not possible, you can also put them in a password protected archive, or send them directly via email to the developer working on the bug.
|
||||
|
||||
## Wireshark Dump
|
||||
## Wireshark dump
|
||||
|
||||
In some cases it is necessary to see exactly what bytes Firefox is sending and receiving over the network. When that happens, the developer working on the bug might ask you for a wireshark capture.
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ In some cases it is necessary to see exactly what bytes Firefox is sending and r
|
|||
|
||||
If the website you're loading to reproduce the bug is over HTTPS, then it might be necessary to [decrypt the capture file](https://wiki.wireshark.org/TLS#Using_the_.28Pre.29-Master-Secret) when recording it.
|
||||
|
||||
## Web Console and Browser Console Errors
|
||||
## Web console and browser console errors
|
||||
|
||||
Sometimes a website breaks because its assumptions about executing JavaScript in Firefox are wrong. When that happens the JavaScript engine might throw exceptions which could break the website you're viewing.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# URL Parsers
|
||||
# URL parsers
|
||||
|
||||
```{warning}
|
||||
In order to ensure thread safety it is important that all of the objects and interfaces of URI objects are immutable.
|
||||
|
|
@ -36,7 +36,7 @@ While we could simply pass strings around and leave it to the final consumer to
|
|||
- [nsISensitiveInfoHiddenURI](https://searchfox.org/mozilla-central/source/netwerk/base/nsISensitiveInfoHiddenURI.idl)
|
||||
- Objects that implement this interface will have a `getSensitiveInfoHiddenSpec()` method that returns the spec of the URI with sensitive info (such as the password) replaced by the `*` symbol.
|
||||
|
||||
### Diagram of Interfaces
|
||||
### Diagram of interfaces
|
||||
```{mermaid}
|
||||
classDiagram
|
||||
nsISupports <-- nsIURI
|
||||
|
|
@ -58,7 +58,7 @@ To change a URI the consumer must call `nsIURI.mutate()` which returns a `nsIMut
|
|||
- This interface contains a series of setters that can be used to mutate and/or construct a `nsIURI`
|
||||
|
||||
|
||||
### Additional Interfaces
|
||||
### Additional interfaces
|
||||
|
||||
- [nsISerializable](https://searchfox.org/mozilla-central/source/xpcom/ds/nsISerializable.idl)
|
||||
- Allows us to serialize and deserialize URL objects into strings for persistent storage (such as session restore).
|
||||
|
|
@ -89,7 +89,7 @@ To change a URI the consumer must call `nsIURI.mutate()` which returns a `nsIMut
|
|||
- [nsJARURI](https://searchfox.org/mozilla-central/source/modules/libjar/nsJARURI.h)
|
||||
- Used to represent resources inside of JAR files.
|
||||
|
||||
### Diagram of Implementations
|
||||
### Diagram of implementations
|
||||
|
||||
```{mermaid}
|
||||
classDiagram
|
||||
|
|
@ -111,7 +111,7 @@ nsINestedURI o-- nsJARURI
|
|||
nsIJARURI o-- nsJARURI
|
||||
```
|
||||
|
||||
## Class and Interface Diagram
|
||||
## Class and interface diagram
|
||||
|
||||
```{mermaid}
|
||||
classDiagram
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
WebTransport (WIP)
|
||||
WebTransport
|
||||
============
|
||||
|
||||
Components:
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче