Fossil SCM
Changed "socket activation" to "socket listener" in all the new docs
Commit
3c9f811b872841065b8fa639103d7af7999335c61d7e1da0b5a8351c73334f80
Parent
1428f59ec9a2a16…
2 files changed
+2
-2
+4
-4
+2
-2
| --- www/server.wiki | ||
| +++ www/server.wiki | ||
| @@ -32,11 +32,11 @@ | ||
| 32 | 32 | |
| 33 | 33 | <blockquote> |
| 34 | 34 | There are basically four ways to set up a Fossil server: |
| 35 | 35 | |
| 36 | 36 | <ol> |
| 37 | - <li>Socket activation: | |
| 37 | + <li>Socket listener: | |
| 38 | 38 | <a id="inetd" href="./server/any/inetd.md">inetd</a>, |
| 39 | 39 | <a id="xinetd" href="./server/any/xinetd.md">xinetd</a>, |
| 40 | 40 | <a id="stunnel" href="./server/any/stunnel.md">stunnel</a>... |
| 41 | 41 | <li><a id="standalone" href="./server/any/none.md">Stand-alone HTTP server</a> |
| 42 | 42 | <li><a id="scgi" href="./server/any/scgi.md">SCGI</a> |
| @@ -130,11 +130,11 @@ | ||
| 130 | 130 | Where there is a check mark in the "Any" row, the method for that is |
| 131 | 131 | generic enough that it works across OSes that Fossil is known to work |
| 132 | 132 | on. The check marks below that usually just link to this generic |
| 133 | 133 | documentation. |
| 134 | 134 | |
| 135 | -There are several widely-deployed socket activation schemes besides the | |
| 135 | +There are several widely-deployed socket listener schemes besides the | |
| 136 | 136 | <tt>inetd</tt>, <tt>xinetd</tt>, and <tt>stunnel</tt> schemes with |
| 137 | 137 | documents linked above: Apple’s <tt>launchd</tt>, Linux’s |
| 138 | 138 | <tt>systemd</tt>, Solaris’ SMF, etc. We would welcome [./contribute.wiki |
| 139 | 139 | | contributions] to cover these as well. We also welcome contributions |
| 140 | 140 | to fill gaps (❌) in the table above. |
| 141 | 141 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | |
| 33 | <blockquote> |
| 34 | There are basically four ways to set up a Fossil server: |
| 35 | |
| 36 | <ol> |
| 37 | <li>Socket activation: |
| 38 | <a id="inetd" href="./server/any/inetd.md">inetd</a>, |
| 39 | <a id="xinetd" href="./server/any/xinetd.md">xinetd</a>, |
| 40 | <a id="stunnel" href="./server/any/stunnel.md">stunnel</a>... |
| 41 | <li><a id="standalone" href="./server/any/none.md">Stand-alone HTTP server</a> |
| 42 | <li><a id="scgi" href="./server/any/scgi.md">SCGI</a> |
| @@ -130,11 +130,11 @@ | |
| 130 | Where there is a check mark in the "Any" row, the method for that is |
| 131 | generic enough that it works across OSes that Fossil is known to work |
| 132 | on. The check marks below that usually just link to this generic |
| 133 | documentation. |
| 134 | |
| 135 | There are several widely-deployed socket activation schemes besides the |
| 136 | <tt>inetd</tt>, <tt>xinetd</tt>, and <tt>stunnel</tt> schemes with |
| 137 | documents linked above: Apple’s <tt>launchd</tt>, Linux’s |
| 138 | <tt>systemd</tt>, Solaris’ SMF, etc. We would welcome [./contribute.wiki |
| 139 | | contributions] to cover these as well. We also welcome contributions |
| 140 | to fill gaps (❌) in the table above. |
| 141 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | |
| 33 | <blockquote> |
| 34 | There are basically four ways to set up a Fossil server: |
| 35 | |
| 36 | <ol> |
| 37 | <li>Socket listener: |
| 38 | <a id="inetd" href="./server/any/inetd.md">inetd</a>, |
| 39 | <a id="xinetd" href="./server/any/xinetd.md">xinetd</a>, |
| 40 | <a id="stunnel" href="./server/any/stunnel.md">stunnel</a>... |
| 41 | <li><a id="standalone" href="./server/any/none.md">Stand-alone HTTP server</a> |
| 42 | <li><a id="scgi" href="./server/any/scgi.md">SCGI</a> |
| @@ -130,11 +130,11 @@ | |
| 130 | Where there is a check mark in the "Any" row, the method for that is |
| 131 | generic enough that it works across OSes that Fossil is known to work |
| 132 | on. The check marks below that usually just link to this generic |
| 133 | documentation. |
| 134 | |
| 135 | There are several widely-deployed socket listener schemes besides the |
| 136 | <tt>inetd</tt>, <tt>xinetd</tt>, and <tt>stunnel</tt> schemes with |
| 137 | documents linked above: Apple’s <tt>launchd</tt>, Linux’s |
| 138 | <tt>systemd</tt>, Solaris’ SMF, etc. We would welcome [./contribute.wiki |
| 139 | | contributions] to cover these as well. We also welcome contributions |
| 140 | to fill gaps (❌) in the table above. |
| 141 |
+4
-4
| --- www/server/any/stunnel.md | ||
| +++ www/server/any/stunnel.md | ||
| @@ -5,19 +5,19 @@ | ||
| 5 | 5 | HTTPS, but only as a client.) `stunnel` decodes the HTTPS data from the |
| 6 | 6 | outside world as HTTP before passing it to Fossil, and it encodes the |
| 7 | 7 | HTTP replies from Fossil as HTTPS before sending them to the remote host |
| 8 | 8 | that made the request. |
| 9 | 9 | |
| 10 | -You can run `stunnel` in one of two modes: socket activation — much like | |
| 10 | +You can run `stunnel` in one of two modes: socket listener — much like | |
| 11 | 11 | in our [`inetd` doc](./inetd.md) — and as an HTTP reverse proxy. We’ll |
| 12 | 12 | cover both cases here, separately. |
| 13 | 13 | |
| 14 | 14 | |
| 15 | 15 | ## S<a name="sa"></a>ocket Activation |
| 16 | 16 | |
| 17 | 17 | The following `stunnel.conf` configuration configures it to run Fossil |
| 18 | -in socket activation mode, launching Fossil only when an HTTPS hit comes | |
| 18 | +in socket listener mode, launching Fossil only when an HTTPS hit comes | |
| 19 | 19 | in, then shutting it back down as soon as the transaction is complete: |
| 20 | 20 | |
| 21 | 21 | ```dosini |
| 22 | 22 | [fossil] |
| 23 | 23 | accept = 443 |
| @@ -68,10 +68,10 @@ | ||
| 68 | 68 | |
| 69 | 69 | There are a few advantages to this mode: |
| 70 | 70 | |
| 71 | 71 | 1. At the cost of some server memory and a tiny bit of idle CPU time, |
| 72 | 72 | Fossil remains running so that hits can be served a smidge faster |
| 73 | - than in socket activation mode, where the Fossil binary has to be | |
| 73 | + than in socket listener mode, where the Fossil binary has to be | |
| 74 | 74 | loaded and re-initialized on each HTTPS hit. |
| 75 | 75 | |
| 76 | -2. The socket activation mode doesn’t work on all platforms that | |
| 76 | +2. The socket listener mode doesn’t work on all platforms that | |
| 77 | 77 | `stunnel` runs on, particularly [on Windows](../windows/stunnel.md). |
| 78 | 78 |
| --- www/server/any/stunnel.md | |
| +++ www/server/any/stunnel.md | |
| @@ -5,19 +5,19 @@ | |
| 5 | HTTPS, but only as a client.) `stunnel` decodes the HTTPS data from the |
| 6 | outside world as HTTP before passing it to Fossil, and it encodes the |
| 7 | HTTP replies from Fossil as HTTPS before sending them to the remote host |
| 8 | that made the request. |
| 9 | |
| 10 | You can run `stunnel` in one of two modes: socket activation — much like |
| 11 | in our [`inetd` doc](./inetd.md) — and as an HTTP reverse proxy. We’ll |
| 12 | cover both cases here, separately. |
| 13 | |
| 14 | |
| 15 | ## S<a name="sa"></a>ocket Activation |
| 16 | |
| 17 | The following `stunnel.conf` configuration configures it to run Fossil |
| 18 | in socket activation mode, launching Fossil only when an HTTPS hit comes |
| 19 | in, then shutting it back down as soon as the transaction is complete: |
| 20 | |
| 21 | ```dosini |
| 22 | [fossil] |
| 23 | accept = 443 |
| @@ -68,10 +68,10 @@ | |
| 68 | |
| 69 | There are a few advantages to this mode: |
| 70 | |
| 71 | 1. At the cost of some server memory and a tiny bit of idle CPU time, |
| 72 | Fossil remains running so that hits can be served a smidge faster |
| 73 | than in socket activation mode, where the Fossil binary has to be |
| 74 | loaded and re-initialized on each HTTPS hit. |
| 75 | |
| 76 | 2. The socket activation mode doesn’t work on all platforms that |
| 77 | `stunnel` runs on, particularly [on Windows](../windows/stunnel.md). |
| 78 |
| --- www/server/any/stunnel.md | |
| +++ www/server/any/stunnel.md | |
| @@ -5,19 +5,19 @@ | |
| 5 | HTTPS, but only as a client.) `stunnel` decodes the HTTPS data from the |
| 6 | outside world as HTTP before passing it to Fossil, and it encodes the |
| 7 | HTTP replies from Fossil as HTTPS before sending them to the remote host |
| 8 | that made the request. |
| 9 | |
| 10 | You can run `stunnel` in one of two modes: socket listener — much like |
| 11 | in our [`inetd` doc](./inetd.md) — and as an HTTP reverse proxy. We’ll |
| 12 | cover both cases here, separately. |
| 13 | |
| 14 | |
| 15 | ## S<a name="sa"></a>ocket Activation |
| 16 | |
| 17 | The following `stunnel.conf` configuration configures it to run Fossil |
| 18 | in socket listener mode, launching Fossil only when an HTTPS hit comes |
| 19 | in, then shutting it back down as soon as the transaction is complete: |
| 20 | |
| 21 | ```dosini |
| 22 | [fossil] |
| 23 | accept = 443 |
| @@ -68,10 +68,10 @@ | |
| 68 | |
| 69 | There are a few advantages to this mode: |
| 70 | |
| 71 | 1. At the cost of some server memory and a tiny bit of idle CPU time, |
| 72 | Fossil remains running so that hits can be served a smidge faster |
| 73 | than in socket listener mode, where the Fossil binary has to be |
| 74 | loaded and re-initialized on each HTTPS hit. |
| 75 | |
| 76 | 2. The socket listener mode doesn’t work on all platforms that |
| 77 | `stunnel` runs on, particularly [on Windows](../windows/stunnel.md). |
| 78 |