зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1845276 - fix inconsistent captilization for titles in Necko's documentation. r=edgul,manuel,necko-reviewers,kershaw
Depends on D195754 Differential Revision: https://phabricator.services.mozilla.com/D196489
This commit is contained in:
sunil mayya
Родитель
064effbe17
Коммит
8ccb3d2528
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Connectivity checking
|
||||
# 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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ The Necko (aka Networking) component is Gecko's implementation of the web's netw
|
|||
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.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ mochitest_with_http3.md
|
|||
sec-necko-components.md
|
||||
cache2/doc
|
||||
http/http3.md
|
||||
Necko Bird’s-eye view <https://docs.google.com/presentation/d/1BRCK4WMYg-dUy07PB5H4jFVTpc4YnkQX8f5Y3KXqCs8>
|
||||
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/>
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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,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
|
||||
WebTransport (WIP)
|
||||
============
|
||||
|
||||
Components:
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче