mirror of
https://github.com/warmcat/libwebsockets.git
synced 2025-03-09 00:00:04 +01:00
update some wording
This commit is contained in:
Andy Green
parent
ef8bfb2488
commit
08c9395da5
7 changed files with 32 additions and 32 deletions
|
|
@ -373,7 +373,7 @@ See `READMEs/README.detailed-latency.md` for how to use it.
|
|||
|
||||
## Client connection logic rewrite
|
||||
|
||||
Lws master now makes much better use of the DNS results for ipv4 and ipv6... it
|
||||
Lws now makes much better use of the DNS results for ipv4 and ipv6... it
|
||||
will iterate through them automatically making the best use it can of what's
|
||||
provided and attempting new connections for each potentially usable one in turn
|
||||
before giving up on the whole client connection attempt.
|
||||
|
|
@ -405,7 +405,7 @@ H1 is not so simple to parse because the header length is not known until it
|
|||
has been fully parsed. The next header, or http body may be directly coalesced
|
||||
with the header as well. Lws has supported bulk h1 parsing from a buffer for a
|
||||
long time, but on clientside due to interactions with http proxying it had
|
||||
been stuck parsing the header bytewise out of the tls buffer. In master,
|
||||
been stuck parsing the header bytewise out of the tls buffer. Now,
|
||||
everything now bulk parses from a buffer and uses a buflist to pass leftovers
|
||||
through the event loop cleanly.
|
||||
|
||||
|
|
@ -423,7 +423,7 @@ schedule your own arbitrary callbacks using this system.
|
|||
|
||||
## Master is now MIT-licensed
|
||||
|
||||
Libwebsockets master is now under the MIT license. See ./LICENSE.
|
||||
Libwebsockets is now under the MIT license. See ./LICENSE.
|
||||
|
||||
## Support
|
||||
|
||||
|
|
@ -440,5 +440,5 @@ You can get the latest version of the library from git:
|
|||
|
||||
- https://libwebsockets.org/git
|
||||
|
||||
Doxygen API docs for master: https://libwebsockets.org/lws-api-doc-master/html/index.html
|
||||
Doxygen API docs for development: https://libwebsockets.org/lws-api-doc-master/html/index.html
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ CSP lets the origin server define what is legitimate for the page it
|
|||
served and everything else is denied.
|
||||
|
||||
The CSP for warmcat.com and libwebsockets.org looks like this,
|
||||
I removed a handful of whitelisted image sources like travis
|
||||
I removed a handful of approved image sources like travis
|
||||
status etc for clarity...
|
||||
|
||||
```
|
||||
|
|
@ -40,7 +40,7 @@ provide a very significant increase in client security.
|
|||
### Implications of strict CSP
|
||||
|
||||
Halfhearted CSP isn't worth much. The only useful approach is to start
|
||||
with `default-src 'none'` which disables everything, and then whitelist the
|
||||
with `default-src 'none'` which disables everything, and then allow the
|
||||
minimum needed for the pages to operate.
|
||||
|
||||
"Minimum needed for the pages to operate" doesn't mean defeat the protections
|
||||
|
|
@ -63,7 +63,7 @@ files referenced in the document `<head>` section, along these lines:
|
|||
#### Inline styles must die
|
||||
|
||||
All styling must go in one or more `.css` file(s) best served by the same
|
||||
server... while you can whitelist other sources in the CSP if you have to,
|
||||
server... while you can approve other sources in the CSP if you have to,
|
||||
unless you control that server as well, you are allowing whoever gains
|
||||
access to that server access to your users.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ nobody dare think about updating it.
|
|||
|
||||
The stable releases go on to a branch like v4.0-stable as described below, over
|
||||
time these attract dozens or even hundreds of minor or major fix patches
|
||||
backported from master. So you should not consume tags like v4.0.0 but build
|
||||
into your planning that you will need to follow v4.0-stable in order to stay on
|
||||
top of known bugs.
|
||||
backported from the development branch. So you should not consume tags like
|
||||
v4.0.0 but build into your planning that you will need to follow v4.0-stable in
|
||||
order to stay on top of known bugs.
|
||||
|
||||
And we only backport fixes to the last stable release, although we will make
|
||||
exceptions for important fixes. So after a while, trying to stick with one
|
||||
|
|
@ -21,13 +21,13 @@ should build into your planning that you will follow lws release upgrades.
|
|||
If you find problems and create fixes, please upstream them, simplifying your
|
||||
life so you can just directly consume the upstream tree with no private changes.
|
||||
|
||||
## Master branch
|
||||
## Development
|
||||
|
||||
Master branch is the default and all new work happens there. It's unstable and
|
||||
subject to history rewrites, patches moving about and being squashed etc. In
|
||||
terms of it working, it is subject to passing CI tests including a battery of
|
||||
runtime tests, so if it is passing CI as it usually is then it's probably in
|
||||
usable shape. See "Why no history on master" below for why it's managed like
|
||||
usable shape. See "Why no history on development" below for why it's managed like
|
||||
that.
|
||||
|
||||
|
||||
|
|
@ -42,10 +42,10 @@ patches there. Instead use a flow like this:
|
|||
$ git fetch https://libwebsockets.org/repo/libwebsockets +master:m && git reset --hard m
|
||||
```
|
||||
|
||||
This fetches current remote master into local branch `m`, and then forces your
|
||||
This fetches current remote development branch into local branch `m`, and then forces your
|
||||
local checkout to exactly match `m`. This replaces your checked-out tree
|
||||
including any of your local changes, so stash those first, or use stgit or so
|
||||
to pop them before updating your basis against lws master.
|
||||
to pop them before updating your basis against lws development.
|
||||
|
||||
## Stable branches
|
||||
|
||||
|
|
@ -53,23 +53,23 @@ Master is very useful for coordinating development, and integrating WIP,
|
|||
but for distros or integration into large user projects some stability is often
|
||||
more desirable than the latest development work.
|
||||
|
||||
Periodically, when master seems in good shape and various new developments seem
|
||||
to be working, it's copied out into a versioned stable branch, like `v3.0-stable`.
|
||||
Periodically, when development seems in good shape and various new developments seem
|
||||
to be working, it's copied out into a versioned stable branch, like `v4.0-stable`.
|
||||
|
||||
|
||||
|
||||
|
||||
The initial copy is tagged with, eg, `v3.0.0`.
|
||||
The initial copy is tagged with, eg, `v4.0.0`.
|
||||
|
||||
(At that time, master's logical version is set to "...99", eg, `v3.0.99` so
|
||||
version comparisons show that version of master is "later" than any other
|
||||
v3.0 version, which will never reach 99 point releases itself, but "earlier"
|
||||
than, eg, v3.1.)
|
||||
(At that time, development's logical version is set to "...99", eg, `v4.0.99` so
|
||||
version comparisons show that development version is "later" than any other
|
||||
v4.0 version, which will never reach 99 point releases itself, but "earlier"
|
||||
than, eg, v4.1.)
|
||||
|
||||
## Backport policy
|
||||
|
||||
Work continues on master, and as part of that usually bugs are reported and / or
|
||||
fixes found that may apply not just to current master, but the version of master
|
||||
that was copied to form the last -stable branch.
|
||||
Development continues, and as part of that usually bugs are reported and / or
|
||||
fixes found that may apply not just to current development, but the version of
|
||||
the development branch that was copied to form the last -stable branch.
|
||||
|
||||
In that case, the patch may be backported to the last stable branch to also fix
|
||||
the bug there. In the case of refactors or major internal improvements, these
|
||||
|
|
@ -108,11 +108,11 @@ uncommon though.
|
|||
|
||||
|
||||
|
||||
## Why no history on master
|
||||
## Why no history on the development branch
|
||||
|
||||
Git is a wonderful tool that can be understood to have two main modes of operation,
|
||||
merge and rebase that are mutually exclusive. Most devs only use merge / pull,
|
||||
but rebase / fetch is much more flexible. Running master via rebases allows me to
|
||||
but rebase / fetch is much more flexible. Developing via rebases allows me to
|
||||
dispense with feature branches during development and enables tracking multiple
|
||||
in-progress patches in-tree by updating them in place. If this doesn't make
|
||||
sense or seems heretical to you, it's OK I don't need devsplain'ing about it,
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ struct lws_ec_curves {
|
|||
* \param context: your lws_context (for RNG access)
|
||||
* \param curve_table: NULL, enabling P-256, P-384 and P-521, or a replacement
|
||||
* struct lws_ec_curves array, terminated by an entry with
|
||||
* .name = NULL, of curves you want to whitelist
|
||||
* .name = NULL, of curves you want to allow
|
||||
*
|
||||
* Initializes a genecdh
|
||||
*/
|
||||
|
|
@ -118,7 +118,7 @@ lws_genecdh_compute_shared_secret(struct lws_genec_ctx *ctx, uint8_t *ss,
|
|||
* \param context: your lws_context (for RNG access)
|
||||
* \param curve_table: NULL, enabling P-256, P-384 and P-521, or a replacement
|
||||
* struct lws_ec_curves array, terminated by an entry with
|
||||
* .name = NULL, of curves you want to whitelist
|
||||
* .name = NULL, of curves you want to allow
|
||||
*
|
||||
* Initializes a genecdh
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ typedef enum {
|
|||
LWSNDVWIFI_STATE_STAT,
|
||||
/*
|
||||
* trying to connect to another non-group AP. If we don't get an
|
||||
* IP within a timeout and retries, blacklist it and go back
|
||||
* IP within a timeout and retries, mark it as unusable it and go back
|
||||
*/
|
||||
LWSNDVWIFI_STATE_STAT_HAPPY,
|
||||
} lws_netdev_wifi_state_t;
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@
|
|||
#define __LWS_DISPLAY_SSD1306_I2C_H__
|
||||
|
||||
/*
|
||||
* D/C# pin on SSD1306 sets the I2C slave ads
|
||||
* D/C# pin on SSD1306 sets the I2C device ads
|
||||
* from these two options (7-bit address)
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ more or less bytes according to the value. So the peak memory requirements for
|
|||
large tries are much bigger than the size of the serialized trie file that is
|
||||
output.
|
||||
|
||||
For the linux kernel at 4.14 and default indexing whitelist on a 2.8GHz AMD
|
||||
For the linux kernel at 4.14 and default indexing list on a 2.8GHz AMD
|
||||
threadripper (using one thread), the stats are:
|
||||
|
||||
Name|Value
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue