Fossil SCM
Further improvements to the server document.
Commit
c2c4d3039fbdd44f0baadc5da858bf0ccb8cbf6fe6bf0f267e554be2dcc22eea
Parent
bc7683e15ab55d0…
1 file changed
+25
-21
+25
-21
| --- www/server/index.html | ||
| +++ www/server/index.html | ||
| @@ -75,50 +75,52 @@ | ||
| 75 | 75 | <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> |
| 76 | 76 | <li><a id="scgi" href="any/scgi.md">SCGI</a> |
| 77 | 77 | </ol> |
| 78 | 78 | |
| 79 | 79 | <p>All of these methods can serve either a single repository or a |
| 80 | -directory containing repositories named "<tt>*.fossil</tt>".</p> | |
| 80 | +directory hierarchy containing mulitiple repositories.</p> | |
| 81 | 81 | |
| 82 | -<p>You are not restricted to using a single method. The same Fossil | |
| 82 | +<p>You are not restricted to a single server setup. The same Fossil | |
| 83 | 83 | repository can be served using two or more of the above techniques at |
| 84 | 84 | the same time. These methods use clean, well-defined, standard |
| 85 | 85 | interfaces (CGI, SCGI, and HTTP) which allow you to easily migrate from |
| 86 | -one method to another to accommodate changes in hosting providers or | |
| 86 | +one method to another in response to changes in hosting providers or | |
| 87 | 87 | administrator preferences.</p> |
| 88 | 88 | |
| 89 | 89 | <h3>CGI</h3> |
| 90 | 90 | |
| 91 | 91 | <p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a |
| 92 | 92 | CGI script</a>. This method is known to work with Apache, |
| 93 | 93 | <tt>lighttpd</tt>, and <a |
| 94 | 94 | href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server |
| 95 | 95 | administrator places a <a href="/help?cmd=cgi">short CGI script</a> in |
| 96 | -the web server's document hierarchy, and when a client requests the URL | |
| 97 | -that corresponds to that script, the script runs Fossil to generate the | |
| 96 | +the web server's document hierarchy and when a client requests the URL | |
| 97 | +that corresponds to that script, Fossil runs and generates the | |
| 98 | 98 | response.</p> |
| 99 | 99 | |
| 100 | 100 | <p>CGI is a good choice for merging Fossil into an existing web site, |
| 101 | -particularly on hosts that have CGI set up for you already and won't let | |
| 102 | -you modify the web server configuration further. The Fossil <a | |
| 103 | -href="../selfhost.wiki">self-hosting repositories</a> are implemented | |
| 104 | -with CGI underneath <tt>althttpd</tt>.</p> | |
| 101 | +particularly on hosts that have CGI set up and working. | |
| 102 | +The Fossil <a href="../selfhost.wiki">self-hosting repositories</a> are | |
| 103 | +implemented with CGI underneath <tt>althttpd</tt>.</p> | |
| 105 | 104 | |
| 106 | 105 | <h3>Socket Listener</h3> |
| 107 | 106 | |
| 108 | -<p>Only slightly more complicated is the socket listener method. | |
| 109 | -Instead of letting Fossil run in the background continuously to handle | |
| 110 | -HTTP requests from clients, you configure a socket listener daemon to | |
| 111 | -run a <a href="/help?cmd=http"><tt>fossil http</tt></a> command on each | |
| 112 | -HTTP hit. That Fossil instance handles only that one hit and then shuts | |
| 113 | -back down, letting the socket listener go back to waiting for the next | |
| 114 | -hit. This scheme is known to work with <a id="inetd" | |
| 115 | -href="any/inetd.md"><tt>inetd</tt></a>, <a id="xinetd" | |
| 107 | +<p>Socket listener daemons such as | |
| 108 | +<a id="inetd" href="any/inetd.md"><tt>inetd</tt></a>, <a id="xinetd" | |
| 116 | 109 | href="any/xinetd.md"><tt>xinetd</tt></a>, <a id="stunnel" |
| 117 | 110 | href="any/stunnel.md"><tt>stunnel</tt></a>, <a |
| 118 | 111 | href="macos/service.md"><tt>launchd</tt></a>, and <a |
| 119 | -href="debian/service.md"><tt>systemd</tt></a>.</p> | |
| 112 | +href="debian/service.md"><tt>systemd</tt></a> | |
| 113 | +can be configured to invoke the the | |
| 114 | +<a href="/help?cmd=http"><tt>fossil http</tt></a> command to handle | |
| 115 | +each incoming HTTP request. The "<tt>fossil http</tt>" command reads | |
| 116 | +the HTTP request off of standard input, computes an appropriate | |
| 117 | +reply, and writes the reply on standard output. There is a separate | |
| 118 | +invocation of the "<tt>fossil http</tt>" command for each HTTP request. | |
| 119 | +The socket listener daemon takes care of relaying content to and from | |
| 120 | +the client, and (in the case of <a href="any/stunnel.md">stunnel</a>) | |
| 121 | +handling TLS decryption and encryption. | |
| 120 | 122 | |
| 121 | 123 | <h3>Stand-alone HTTP Server</h3> |
| 122 | 124 | |
| 123 | 125 | <p>This is the <a href="any/none.md">easiest method</a>. |
| 124 | 126 | A stand-alone server uses the <a |
| @@ -129,13 +131,14 @@ | ||
| 129 | 131 | <a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> |
| 130 | 132 | layer between the clients and Fossil.</p> |
| 131 | 133 | |
| 132 | 134 | <h3>SCGI</h3> |
| 133 | 135 | |
| 134 | -<p>The Fossil standalone server can also run <a href="any/scgi.md">in | |
| 135 | -SCGI mode</a> — <a href="/help/server"><tt>fossil server --scgi</tt></a> | |
| 136 | -— instead of <a href="any/none.md">HTTP mode</a>, which allows it to | |
| 136 | +<p>The Fossil standalone server can also handle <a href="any/scgi.md">SCGI</a>. | |
| 137 | +When the <a href="/help/server"><tt>fossil server</tt></a> command is | |
| 138 | +run with the extra <tt>--scgi</tt> option, it listens for incoming | |
| 139 | +SCGI requests rather than HTTP requests. This allows Fossil to | |
| 137 | 140 | respond to requests from web servers <a href="debian/nginx.md">such as |
| 138 | 141 | nginx</a> that don't support CGI. SCGI is a simpler protocol to proxy |
| 139 | 142 | than HTTP, since the HTTP doesn't have to be re-interpreted in terms of |
| 140 | 143 | the proxy's existing HTTP implementation, but it's more complex to set |
| 141 | 144 | up because you also have to set up an SCGI-to-HTTP proxy for it. It is |
| @@ -232,12 +235,13 @@ | ||
| 232 | 235 | <h2 id="more">Further Details</h2> |
| 233 | 236 | |
| 234 | 237 | <ul> |
| 235 | 238 | <li><a id="chroot" href="../chroot.md" >The Server Chroot Jail</a> |
| 236 | 239 | <li><a id="loadmgmt" href="../loadmgmt.md" >Managing Server Load</a> |
| 240 | + <li><a id="bkofc" href="../backoffice.md" >The Backoffice</a> | |
| 237 | 241 | <li><a id="tls" href="../ssl.wiki" >Securing a Repository with TLS</a> |
| 238 | 242 | <li><a id="ext" href="../serverext.wiki">CGI Server Extensions</a> |
| 239 | 243 | <li><a id="about" href="../aboutcgi.wiki" >How CGI Works In Fossil</a> |
| 240 | 244 | <li><a id="sync" href="../sync.wiki" >The Fossil Sync Protocol</a> |
| 241 | 245 | </ul> |
| 242 | 246 | |
| 243 | 247 | </div> |
| 244 | 248 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -75,50 +75,52 @@ | |
| 75 | <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> |
| 76 | <li><a id="scgi" href="any/scgi.md">SCGI</a> |
| 77 | </ol> |
| 78 | |
| 79 | <p>All of these methods can serve either a single repository or a |
| 80 | directory containing repositories named "<tt>*.fossil</tt>".</p> |
| 81 | |
| 82 | <p>You are not restricted to using a single method. The same Fossil |
| 83 | repository can be served using two or more of the above techniques at |
| 84 | the same time. These methods use clean, well-defined, standard |
| 85 | interfaces (CGI, SCGI, and HTTP) which allow you to easily migrate from |
| 86 | one method to another to accommodate changes in hosting providers or |
| 87 | administrator preferences.</p> |
| 88 | |
| 89 | <h3>CGI</h3> |
| 90 | |
| 91 | <p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a |
| 92 | CGI script</a>. This method is known to work with Apache, |
| 93 | <tt>lighttpd</tt>, and <a |
| 94 | href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server |
| 95 | administrator places a <a href="/help?cmd=cgi">short CGI script</a> in |
| 96 | the web server's document hierarchy, and when a client requests the URL |
| 97 | that corresponds to that script, the script runs Fossil to generate the |
| 98 | response.</p> |
| 99 | |
| 100 | <p>CGI is a good choice for merging Fossil into an existing web site, |
| 101 | particularly on hosts that have CGI set up for you already and won't let |
| 102 | you modify the web server configuration further. The Fossil <a |
| 103 | href="../selfhost.wiki">self-hosting repositories</a> are implemented |
| 104 | with CGI underneath <tt>althttpd</tt>.</p> |
| 105 | |
| 106 | <h3>Socket Listener</h3> |
| 107 | |
| 108 | <p>Only slightly more complicated is the socket listener method. |
| 109 | Instead of letting Fossil run in the background continuously to handle |
| 110 | HTTP requests from clients, you configure a socket listener daemon to |
| 111 | run a <a href="/help?cmd=http"><tt>fossil http</tt></a> command on each |
| 112 | HTTP hit. That Fossil instance handles only that one hit and then shuts |
| 113 | back down, letting the socket listener go back to waiting for the next |
| 114 | hit. This scheme is known to work with <a id="inetd" |
| 115 | href="any/inetd.md"><tt>inetd</tt></a>, <a id="xinetd" |
| 116 | href="any/xinetd.md"><tt>xinetd</tt></a>, <a id="stunnel" |
| 117 | href="any/stunnel.md"><tt>stunnel</tt></a>, <a |
| 118 | href="macos/service.md"><tt>launchd</tt></a>, and <a |
| 119 | href="debian/service.md"><tt>systemd</tt></a>.</p> |
| 120 | |
| 121 | <h3>Stand-alone HTTP Server</h3> |
| 122 | |
| 123 | <p>This is the <a href="any/none.md">easiest method</a>. |
| 124 | A stand-alone server uses the <a |
| @@ -129,13 +131,14 @@ | |
| 129 | <a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> |
| 130 | layer between the clients and Fossil.</p> |
| 131 | |
| 132 | <h3>SCGI</h3> |
| 133 | |
| 134 | <p>The Fossil standalone server can also run <a href="any/scgi.md">in |
| 135 | SCGI mode</a> — <a href="/help/server"><tt>fossil server --scgi</tt></a> |
| 136 | — instead of <a href="any/none.md">HTTP mode</a>, which allows it to |
| 137 | respond to requests from web servers <a href="debian/nginx.md">such as |
| 138 | nginx</a> that don't support CGI. SCGI is a simpler protocol to proxy |
| 139 | than HTTP, since the HTTP doesn't have to be re-interpreted in terms of |
| 140 | the proxy's existing HTTP implementation, but it's more complex to set |
| 141 | up because you also have to set up an SCGI-to-HTTP proxy for it. It is |
| @@ -232,12 +235,13 @@ | |
| 232 | <h2 id="more">Further Details</h2> |
| 233 | |
| 234 | <ul> |
| 235 | <li><a id="chroot" href="../chroot.md" >The Server Chroot Jail</a> |
| 236 | <li><a id="loadmgmt" href="../loadmgmt.md" >Managing Server Load</a> |
| 237 | <li><a id="tls" href="../ssl.wiki" >Securing a Repository with TLS</a> |
| 238 | <li><a id="ext" href="../serverext.wiki">CGI Server Extensions</a> |
| 239 | <li><a id="about" href="../aboutcgi.wiki" >How CGI Works In Fossil</a> |
| 240 | <li><a id="sync" href="../sync.wiki" >The Fossil Sync Protocol</a> |
| 241 | </ul> |
| 242 | |
| 243 | </div> |
| 244 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -75,50 +75,52 @@ | |
| 75 | <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> |
| 76 | <li><a id="scgi" href="any/scgi.md">SCGI</a> |
| 77 | </ol> |
| 78 | |
| 79 | <p>All of these methods can serve either a single repository or a |
| 80 | directory hierarchy containing mulitiple repositories.</p> |
| 81 | |
| 82 | <p>You are not restricted to a single server setup. The same Fossil |
| 83 | repository can be served using two or more of the above techniques at |
| 84 | the same time. These methods use clean, well-defined, standard |
| 85 | interfaces (CGI, SCGI, and HTTP) which allow you to easily migrate from |
| 86 | one method to another in response to changes in hosting providers or |
| 87 | administrator preferences.</p> |
| 88 | |
| 89 | <h3>CGI</h3> |
| 90 | |
| 91 | <p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a |
| 92 | CGI script</a>. This method is known to work with Apache, |
| 93 | <tt>lighttpd</tt>, and <a |
| 94 | href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server |
| 95 | administrator places a <a href="/help?cmd=cgi">short CGI script</a> in |
| 96 | the web server's document hierarchy and when a client requests the URL |
| 97 | that corresponds to that script, Fossil runs and generates the |
| 98 | response.</p> |
| 99 | |
| 100 | <p>CGI is a good choice for merging Fossil into an existing web site, |
| 101 | particularly on hosts that have CGI set up and working. |
| 102 | The Fossil <a href="../selfhost.wiki">self-hosting repositories</a> are |
| 103 | implemented with CGI underneath <tt>althttpd</tt>.</p> |
| 104 | |
| 105 | <h3>Socket Listener</h3> |
| 106 | |
| 107 | <p>Socket listener daemons such as |
| 108 | <a id="inetd" href="any/inetd.md"><tt>inetd</tt></a>, <a id="xinetd" |
| 109 | href="any/xinetd.md"><tt>xinetd</tt></a>, <a id="stunnel" |
| 110 | href="any/stunnel.md"><tt>stunnel</tt></a>, <a |
| 111 | href="macos/service.md"><tt>launchd</tt></a>, and <a |
| 112 | href="debian/service.md"><tt>systemd</tt></a> |
| 113 | can be configured to invoke the the |
| 114 | <a href="/help?cmd=http"><tt>fossil http</tt></a> command to handle |
| 115 | each incoming HTTP request. The "<tt>fossil http</tt>" command reads |
| 116 | the HTTP request off of standard input, computes an appropriate |
| 117 | reply, and writes the reply on standard output. There is a separate |
| 118 | invocation of the "<tt>fossil http</tt>" command for each HTTP request. |
| 119 | The socket listener daemon takes care of relaying content to and from |
| 120 | the client, and (in the case of <a href="any/stunnel.md">stunnel</a>) |
| 121 | handling TLS decryption and encryption. |
| 122 | |
| 123 | <h3>Stand-alone HTTP Server</h3> |
| 124 | |
| 125 | <p>This is the <a href="any/none.md">easiest method</a>. |
| 126 | A stand-alone server uses the <a |
| @@ -129,13 +131,14 @@ | |
| 131 | <a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> |
| 132 | layer between the clients and Fossil.</p> |
| 133 | |
| 134 | <h3>SCGI</h3> |
| 135 | |
| 136 | <p>The Fossil standalone server can also handle <a href="any/scgi.md">SCGI</a>. |
| 137 | When the <a href="/help/server"><tt>fossil server</tt></a> command is |
| 138 | run with the extra <tt>--scgi</tt> option, it listens for incoming |
| 139 | SCGI requests rather than HTTP requests. This allows Fossil to |
| 140 | respond to requests from web servers <a href="debian/nginx.md">such as |
| 141 | nginx</a> that don't support CGI. SCGI is a simpler protocol to proxy |
| 142 | than HTTP, since the HTTP doesn't have to be re-interpreted in terms of |
| 143 | the proxy's existing HTTP implementation, but it's more complex to set |
| 144 | up because you also have to set up an SCGI-to-HTTP proxy for it. It is |
| @@ -232,12 +235,13 @@ | |
| 235 | <h2 id="more">Further Details</h2> |
| 236 | |
| 237 | <ul> |
| 238 | <li><a id="chroot" href="../chroot.md" >The Server Chroot Jail</a> |
| 239 | <li><a id="loadmgmt" href="../loadmgmt.md" >Managing Server Load</a> |
| 240 | <li><a id="bkofc" href="../backoffice.md" >The Backoffice</a> |
| 241 | <li><a id="tls" href="../ssl.wiki" >Securing a Repository with TLS</a> |
| 242 | <li><a id="ext" href="../serverext.wiki">CGI Server Extensions</a> |
| 243 | <li><a id="about" href="../aboutcgi.wiki" >How CGI Works In Fossil</a> |
| 244 | <li><a id="sync" href="../sync.wiki" >The Fossil Sync Protocol</a> |
| 245 | </ul> |
| 246 | |
| 247 | </div> |
| 248 |