70d091eaccf… — Fossil SCM

M auto.def

+15

		--- auto.def
		+++ auto.def
		@@ -9,10 +9,11 @@
9	9	with-zlib:path\|auto\|tree
10	10	=> {Look for zlib in the given path, automatically, or in the source tree}
11	11	with-exec-rel-paths=0
12	12	=> {Enable relative paths for external diff/gdiff}
13	13	with-legacy-mv-rm=1 => {Enable legacy behavior for mv/rm (skip checkout files)}
	14	+ with-sanitizer: => {Build with C compiler's -fsanitize=LIST; e.g. address,enum,null,undefined}
14	15	with-th1-docs=0 => {Enable TH1 for embedded documentation pages}
15	16	with-th1-hooks=0 => {Enable TH1 hooks for commands and web pages}
16	17	with-tcl:path => {Enable Tcl integration, with Tcl in the specified path}
17	18	with-tcl-stubs=0 => {Enable Tcl integration via stubs library mechanism}
18	19	with-tcl-private-stubs=0
		@@ -589,10 +590,24 @@
589	590	define FOSSIL_HAVE_FUSEFS 1
590	591	define-append LIBS -lfuse
591	592	msg-result "FuseFS support enabled"
592	593	}
593	594	}
	595	+
	596	+# Add -fsanitize compile and link options late: we don't want the C
	597	+# checks above to run with those sanitizers enabled. It can not only
	598	+# be pointless, it can actually break correct tests.
	599	+set fsan [opt-val with-sanitizer]
	600	+if {[string length $fsan]} {
	601	+ define-append EXTRA_CFLAGS -fsanitize=$fsan
	602	+ define-append EXTRA_LDFLAGS -fsanitize=$fsan
	603	+ if {[string first "undefined" $fsan] != -1} {
	604	+ # We need to link with libubsan if we're compiling under
	605	+ # GCC with -fsanitize=undefined.
	606	+ cc-check-function-in-lib __ubsan_handle_add_overflow ubsan
	607	+ }
	608	+}
594	609
595	610	# Finally, append -ldl to make sure it's the last in the list.
596	611	# The library order matters in case of static linking.
597	612	if {[check-function-in-lib dlopen dl]} {
598	613	# Some platforms (*BSD) have the dl functions already in libc and no libdl.
599	614

	--- auto.def
	+++ auto.def
	@@ -9,10 +9,11 @@
9	with-zlib:path\|auto\|tree
10	=> {Look for zlib in the given path, automatically, or in the source tree}
11	with-exec-rel-paths=0
12	=> {Enable relative paths for external diff/gdiff}
13	with-legacy-mv-rm=1 => {Enable legacy behavior for mv/rm (skip checkout files)}

14	with-th1-docs=0 => {Enable TH1 for embedded documentation pages}
15	with-th1-hooks=0 => {Enable TH1 hooks for commands and web pages}
16	with-tcl:path => {Enable Tcl integration, with Tcl in the specified path}
17	with-tcl-stubs=0 => {Enable Tcl integration via stubs library mechanism}
18	with-tcl-private-stubs=0
	@@ -589,10 +590,24 @@
589	define FOSSIL_HAVE_FUSEFS 1
590	define-append LIBS -lfuse
591	msg-result "FuseFS support enabled"
592	}
593	}














594
595	# Finally, append -ldl to make sure it's the last in the list.
596	# The library order matters in case of static linking.
597	if {[check-function-in-lib dlopen dl]} {
598	# Some platforms (*BSD) have the dl functions already in libc and no libdl.
599

	--- auto.def
	+++ auto.def
	@@ -9,10 +9,11 @@
9	with-zlib:path\|auto\|tree
10	=> {Look for zlib in the given path, automatically, or in the source tree}
11	with-exec-rel-paths=0
12	=> {Enable relative paths for external diff/gdiff}
13	with-legacy-mv-rm=1 => {Enable legacy behavior for mv/rm (skip checkout files)}
14	with-sanitizer: => {Build with C compiler's -fsanitize=LIST; e.g. address,enum,null,undefined}
15	with-th1-docs=0 => {Enable TH1 for embedded documentation pages}
16	with-th1-hooks=0 => {Enable TH1 hooks for commands and web pages}
17	with-tcl:path => {Enable Tcl integration, with Tcl in the specified path}
18	with-tcl-stubs=0 => {Enable Tcl integration via stubs library mechanism}
19	with-tcl-private-stubs=0
	@@ -589,10 +590,24 @@
590	define FOSSIL_HAVE_FUSEFS 1
591	define-append LIBS -lfuse
592	msg-result "FuseFS support enabled"
593	}
594	}
595
596	# Add -fsanitize compile and link options late: we don't want the C
597	# checks above to run with those sanitizers enabled. It can not only
598	# be pointless, it can actually break correct tests.
599	set fsan [opt-val with-sanitizer]
600	if {[string length $fsan]} {
601	define-append EXTRA_CFLAGS -fsanitize=$fsan
602	define-append EXTRA_LDFLAGS -fsanitize=$fsan
603	if {[string first "undefined" $fsan] != -1} {
604	# We need to link with libubsan if we're compiling under
605	# GCC with -fsanitize=undefined.
606	cc-check-function-in-lib __ubsan_handle_add_overflow ubsan
607	}
608	}
609
610	# Finally, append -ldl to make sure it's the last in the list.
611	# The library order matters in case of static linking.
612	if {[check-function-in-lib dlopen dl]} {
613	# Some platforms (*BSD) have the dl functions already in libc and no libdl.
614

M skins/bootstrap/header.txt

+1 -1

		--- skins/bootstrap/header.txt
		+++ skins/bootstrap/header.txt
		@@ -2,11 +2,11 @@
2	2	<head>
3	3	<meta charset="utf-8">
4	4	<base href="$baseurl/$current_page" />
5	5	<title>$<project_name>: $<title></title>
6	6	<meta name="viewport" content="width=device-width, initial-scale=1.0">
7		- <meta http-equiv="Content-Security-Policy" content="default-src 'self' data:; script-src 'self' 'nonce-$<nonce>'; style-src 'self' 'unsafe-inline'"/>
	7	+ <meta http-equiv="Content-Security-Policy" content="$default_csp"/>
8	8	<link rel="alternate" type="application/rss+xml" title="RSS Feed" href="$home/timeline.rss" />
9	9	<link rel="stylesheet" href="$home/style.css?default" type="text/css" media="screen" />
10	10	<script nonce="$<nonce>">
11	11	function gebi(x){
12	12	if(/^#/.test(x)) x = x.substr(1);
13	13

	--- skins/bootstrap/header.txt
	+++ skins/bootstrap/header.txt
	@@ -2,11 +2,11 @@
2	<head>
3	<meta charset="utf-8">
4	<base href="$baseurl/$current_page" />
5	<title>$<project_name>: $<title></title>
6	<meta name="viewport" content="width=device-width, initial-scale=1.0">
7	<meta http-equiv="Content-Security-Policy" content="default-src 'self' data:; script-src 'self' 'nonce-$<nonce>'; style-src 'self' 'unsafe-inline'"/>
8	<link rel="alternate" type="application/rss+xml" title="RSS Feed" href="$home/timeline.rss" />
9	<link rel="stylesheet" href="$home/style.css?default" type="text/css" media="screen" />
10	<script nonce="$<nonce>">
11	function gebi(x){
12	if(/^#/.test(x)) x = x.substr(1);
13

	--- skins/bootstrap/header.txt
	+++ skins/bootstrap/header.txt
	@@ -2,11 +2,11 @@
2	<head>
3	<meta charset="utf-8">
4	<base href="$baseurl/$current_page" />
5	<title>$<project_name>: $<title></title>
6	<meta name="viewport" content="width=device-width, initial-scale=1.0">
7	<meta http-equiv="Content-Security-Policy" content="$default_csp"/>
8	<link rel="alternate" type="application/rss+xml" title="RSS Feed" href="$home/timeline.rss" />
9	<link rel="stylesheet" href="$home/style.css?default" type="text/css" media="screen" />
10	<script nonce="$<nonce>">
11	function gebi(x){
12	if(/^#/.test(x)) x = x.substr(1);
13

M src/cgi.c

+7

		--- src/cgi.c
		+++ src/cgi.c
		@@ -144,10 +144,17 @@
144	144	** Return a pointer to the CGI output blob.
145	145	*/
146	146	Blob *cgi_output_blob(void){
147	147	return pContent;
148	148	}
	149	+
	150	+/*
	151	+** Return complete text of the output header
	152	+*/
	153	+const char *cgi_header(void){
	154	+ return blob_str(&cgiContent[0]);
	155	+}
149	156
150	157	/*
151	158	** Combine the header and body of the CGI into a single string.
152	159	*/
153	160	static void cgi_combine_header_and_body(void){
154	161

	--- src/cgi.c
	+++ src/cgi.c
	@@ -144,10 +144,17 @@
144	** Return a pointer to the CGI output blob.
145	*/
146	Blob *cgi_output_blob(void){
147	return pContent;
148	}







149
150	/*
151	** Combine the header and body of the CGI into a single string.
152	*/
153	static void cgi_combine_header_and_body(void){
154

	--- src/cgi.c
	+++ src/cgi.c
	@@ -144,10 +144,17 @@
144	** Return a pointer to the CGI output blob.
145	*/
146	Blob *cgi_output_blob(void){
147	return pContent;
148	}
149
150	/*
151	** Return complete text of the output header
152	*/
153	const char *cgi_header(void){
154	return blob_str(&cgiContent[0]);
155	}
156
157	/*
158	** Combine the header and body of the CGI into a single string.
159	*/
160	static void cgi_combine_header_and_body(void){
161

M src/db.c

+11 -8

		--- src/db.c
		+++ src/db.c
		@@ -1383,21 +1383,24 @@
1383	1383	if( zHome==0 ){
1384	1384	zHome = fossil_getenv("LOCALAPPDATA");
1385	1385	if( zHome==0 ){
1386	1386	zHome = fossil_getenv("APPDATA");
1387	1387	if( zHome==0 ){
1388		- char *zDrive = fossil_getenv("HOMEDRIVE");
1389		- char *zPath = fossil_getenv("HOMEPATH");
1390		- if( zDrive && zPath ) zHome = mprintf("%s%s", zDrive, zPath);
	1388	+ zHome = fossil_getenv("USERPROFILE");
	1389	+ if( zHome==0 ){
	1390	+ char *zDrive = fossil_getenv("HOMEDRIVE");
	1391	+ char *zPath = fossil_getenv("HOMEPATH");
	1392	+ if( zDrive && zPath ) zHome = mprintf("%s%s", zDrive, zPath);
	1393	+ }
1391	1394	}
1392	1395	}
1393	1396	}
1394	1397	if( zHome==0 ){
1395	1398	if( isOptional ) return 0;
1396	1399	fossil_panic("cannot locate home directory - please set the "
1397		- "FOSSIL_HOME, LOCALAPPDATA, APPDATA, or HOMEPATH "
1398		- "environment variables");
	1400	+ "FOSSIL_HOME, LOCALAPPDATA, APPDATA, USERPROFILE, "
	1401	+ "or HOMEDRIVE / HOMEPATH environment variables");
1399	1402	}
1400	1403	#else
1401	1404	if( zHome==0 ){
1402	1405	zHome = fossil_getenv("HOME");
1403	1406	}
		@@ -3488,11 +3491,11 @@
3488	3491	** scripts to be evaluated from TH1. Additionally, the Tcl
3489	3492	** interpreter will be able to evaluate arbitrary TH1
3490	3493	** expressions and scripts.
3491	3494	*/
3492	3495	/*
3493		-** SETTING: tcl-setup width=40 versionable block-text
	3496	+** SETTING: tcl-setup width=40 block-text
3494	3497	** This is the setup script to be evaluated after creating
3495	3498	** and initializing the Tcl interpreter. By default, this
3496	3499	** is empty and no extra setup is performed.
3497	3500	*/
3498	3501	#endif /* FOSSIL_ENABLE_TCL */
		@@ -3520,17 +3523,17 @@
3520	3523	** If enabled, special TH1 commands will be called before and
3521	3524	** after any Fossil command or web page.
3522	3525	*/
3523	3526	#endif
3524	3527	/*
3525		-** SETTING: th1-setup width=40 versionable block-text
	3528	+** SETTING: th1-setup width=40 block-text
3526	3529	** This is the setup script to be evaluated after creating
3527	3530	** and initializing the TH1 interpreter. By default, this
3528	3531	** is empty and no extra setup is performed.
3529	3532	*/
3530	3533	/*
3531		-** SETTING: th1-uri-regexp width=40 versionable block-text
	3534	+** SETTING: th1-uri-regexp width=40 block-text
3532	3535	** Specify which URI's are allowed in HTTP requests from
3533	3536	** TH1 scripts. If empty, no HTTP requests are allowed
3534	3537	** whatsoever.
3535	3538	*/
3536	3539	/*
3537	3540

	--- src/db.c
	+++ src/db.c
	@@ -1383,21 +1383,24 @@
1383	if( zHome==0 ){
1384	zHome = fossil_getenv("LOCALAPPDATA");
1385	if( zHome==0 ){
1386	zHome = fossil_getenv("APPDATA");
1387	if( zHome==0 ){
1388	char *zDrive = fossil_getenv("HOMEDRIVE");
1389	char *zPath = fossil_getenv("HOMEPATH");
1390	if( zDrive && zPath ) zHome = mprintf("%s%s", zDrive, zPath);



1391	}
1392	}
1393	}
1394	if( zHome==0 ){
1395	if( isOptional ) return 0;
1396	fossil_panic("cannot locate home directory - please set the "
1397	"FOSSIL_HOME, LOCALAPPDATA, APPDATA, or HOMEPATH "
1398	"environment variables");
1399	}
1400	#else
1401	if( zHome==0 ){
1402	zHome = fossil_getenv("HOME");
1403	}
	@@ -3488,11 +3491,11 @@
3488	** scripts to be evaluated from TH1. Additionally, the Tcl
3489	** interpreter will be able to evaluate arbitrary TH1
3490	** expressions and scripts.
3491	*/
3492	/*
3493	** SETTING: tcl-setup width=40 versionable block-text
3494	** This is the setup script to be evaluated after creating
3495	** and initializing the Tcl interpreter. By default, this
3496	** is empty and no extra setup is performed.
3497	*/
3498	#endif /* FOSSIL_ENABLE_TCL */
	@@ -3520,17 +3523,17 @@
3520	** If enabled, special TH1 commands will be called before and
3521	** after any Fossil command or web page.
3522	*/
3523	#endif
3524	/*
3525	** SETTING: th1-setup width=40 versionable block-text
3526	** This is the setup script to be evaluated after creating
3527	** and initializing the TH1 interpreter. By default, this
3528	** is empty and no extra setup is performed.
3529	*/
3530	/*
3531	** SETTING: th1-uri-regexp width=40 versionable block-text
3532	** Specify which URI's are allowed in HTTP requests from
3533	** TH1 scripts. If empty, no HTTP requests are allowed
3534	** whatsoever.
3535	*/
3536	/*
3537

	--- src/db.c
	+++ src/db.c
	@@ -1383,21 +1383,24 @@
1383	if( zHome==0 ){
1384	zHome = fossil_getenv("LOCALAPPDATA");
1385	if( zHome==0 ){
1386	zHome = fossil_getenv("APPDATA");
1387	if( zHome==0 ){
1388	zHome = fossil_getenv("USERPROFILE");
1389	if( zHome==0 ){
1390	char *zDrive = fossil_getenv("HOMEDRIVE");
1391	char *zPath = fossil_getenv("HOMEPATH");
1392	if( zDrive && zPath ) zHome = mprintf("%s%s", zDrive, zPath);
1393	}
1394	}
1395	}
1396	}
1397	if( zHome==0 ){
1398	if( isOptional ) return 0;
1399	fossil_panic("cannot locate home directory - please set the "
1400	"FOSSIL_HOME, LOCALAPPDATA, APPDATA, USERPROFILE, "
1401	"or HOMEDRIVE / HOMEPATH environment variables");
1402	}
1403	#else
1404	if( zHome==0 ){
1405	zHome = fossil_getenv("HOME");
1406	}
	@@ -3488,11 +3491,11 @@
3491	** scripts to be evaluated from TH1. Additionally, the Tcl
3492	** interpreter will be able to evaluate arbitrary TH1
3493	** expressions and scripts.
3494	*/
3495	/*
3496	** SETTING: tcl-setup width=40 block-text
3497	** This is the setup script to be evaluated after creating
3498	** and initializing the Tcl interpreter. By default, this
3499	** is empty and no extra setup is performed.
3500	*/
3501	#endif /* FOSSIL_ENABLE_TCL */
	@@ -3520,17 +3523,17 @@
3523	** If enabled, special TH1 commands will be called before and
3524	** after any Fossil command or web page.
3525	*/
3526	#endif
3527	/*
3528	** SETTING: th1-setup width=40 block-text
3529	** This is the setup script to be evaluated after creating
3530	** and initializing the TH1 interpreter. By default, this
3531	** is empty and no extra setup is performed.
3532	*/
3533	/*
3534	** SETTING: th1-uri-regexp width=40 block-text
3535	** Specify which URI's are allowed in HTTP requests from
3536	** TH1 scripts. If empty, no HTTP requests are allowed
3537	** whatsoever.
3538	*/
3539	/*
3540

M src/doc.c

+1 -1

		--- src/doc.c
		+++ src/doc.c
		@@ -422,11 +422,11 @@
422	422	while( fossil_isspace(zIn[0]) ) zIn++;
423	423	if( fossil_strnicmp(zIn,"<div",4)!=0 ) return 0;
424	424	zIn += 4;
425	425	while( zIn[0] ){
426	426	if( fossil_isspace(zIn[0]) ) zIn++;
427		- if( zIn[0]=='>' ) return 0;
	427	+ if( zIn[0]=='>' ) break;
428	428	zAttr = zIn;
429	429	while( fossil_isalnum(zIn[0]) \|\| zIn[0]=='-' ) zIn++;
430	430	nAttr = (int)(zIn - zAttr);
431	431	while( fossil_isspace(zIn[0]) ) zIn++;
432	432	if( zIn[0]!='=' ) continue;
433	433

	--- src/doc.c
	+++ src/doc.c
	@@ -422,11 +422,11 @@
422	while( fossil_isspace(zIn[0]) ) zIn++;
423	if( fossil_strnicmp(zIn,"<div",4)!=0 ) return 0;
424	zIn += 4;
425	while( zIn[0] ){
426	if( fossil_isspace(zIn[0]) ) zIn++;
427	if( zIn[0]=='>' ) return 0;
428	zAttr = zIn;
429	while( fossil_isalnum(zIn[0]) \|\| zIn[0]=='-' ) zIn++;
430	nAttr = (int)(zIn - zAttr);
431	while( fossil_isspace(zIn[0]) ) zIn++;
432	if( zIn[0]!='=' ) continue;
433

	--- src/doc.c
	+++ src/doc.c
	@@ -422,11 +422,11 @@
422	while( fossil_isspace(zIn[0]) ) zIn++;
423	if( fossil_strnicmp(zIn,"<div",4)!=0 ) return 0;
424	zIn += 4;
425	while( zIn[0] ){
426	if( fossil_isspace(zIn[0]) ) zIn++;
427	if( zIn[0]=='>' ) break;
428	zAttr = zIn;
429	while( fossil_isalnum(zIn[0]) \|\| zIn[0]=='-' ) zIn++;
430	nAttr = (int)(zIn - zAttr);
431	while( fossil_isspace(zIn[0]) ) zIn++;
432	if( zIn[0]!='=' ) continue;
433

M src/lookslike.c

+6 -4

		--- src/lookslike.c
		+++ src/lookslike.c
		@@ -363,19 +363,21 @@
363	363	int starts_with_utf16_bom(
364	364	const Blob pContent, / IN: Blob content to perform BOM detection on. */
365	365	int pnByte, / OUT: The number of bytes used for the BOM. */
366	366	int pbReverse / OUT: Non-zero for BOM in reverse byte-order. */
367	367	){
368		- const unsigned short z = (unsigned short )blob_buffer(pContent);
	368	+ const unsigned char z = (unsigned char )blob_buffer(pContent);
369	369	int bomSize = sizeof(unsigned short);
370	370	int size = blob_size(pContent);
	371	+ unsigned short i0;
371	372
372	373	if( size<bomSize ) goto noBom; /* No: cannot read BOM. */
373		- if( size>=(2bomSize) && z[1]==0 ) goto noBom; / No: possible UTF-32. */
374		- if( z[0]==0xfeff ){
	374	+ if( size>=(2*bomSize) && z[2]==0 && z[3]==0 ) goto noBom;
	375	+ memcpy(&i0, z, sizeof(i0));
	376	+ if( i0==0xfeff ){
375	377	if( pbReverse ) *pbReverse = 0;
376		- }else if( z[0]==0xfffe ){
	378	+ }else if( i0==0xfffe ){
377	379	if( pbReverse ) *pbReverse = 1;
378	380	}else{
379	381	static const int one = 1;
380	382	noBom:
381	383	if( pbReverse ) pbReverse = (char *) &one;
382	384

	--- src/lookslike.c
	+++ src/lookslike.c
	@@ -363,19 +363,21 @@
363	int starts_with_utf16_bom(
364	const Blob pContent, / IN: Blob content to perform BOM detection on. */
365	int pnByte, / OUT: The number of bytes used for the BOM. */
366	int pbReverse / OUT: Non-zero for BOM in reverse byte-order. */
367	){
368	const unsigned short z = (unsigned short )blob_buffer(pContent);
369	int bomSize = sizeof(unsigned short);
370	int size = blob_size(pContent);

371
372	if( size<bomSize ) goto noBom; /* No: cannot read BOM. */
373	if( size>=(2bomSize) && z[1]==0 ) goto noBom; / No: possible UTF-32. */
374	if( z[0]==0xfeff ){

375	if( pbReverse ) *pbReverse = 0;
376	}else if( z[0]==0xfffe ){
377	if( pbReverse ) *pbReverse = 1;
378	}else{
379	static const int one = 1;
380	noBom:
381	if( pbReverse ) pbReverse = (char *) &one;
382

	--- src/lookslike.c
	+++ src/lookslike.c
	@@ -363,19 +363,21 @@
363	int starts_with_utf16_bom(
364	const Blob pContent, / IN: Blob content to perform BOM detection on. */
365	int pnByte, / OUT: The number of bytes used for the BOM. */
366	int pbReverse / OUT: Non-zero for BOM in reverse byte-order. */
367	){
368	const unsigned char z = (unsigned char )blob_buffer(pContent);
369	int bomSize = sizeof(unsigned short);
370	int size = blob_size(pContent);
371	unsigned short i0;
372
373	if( size<bomSize ) goto noBom; /* No: cannot read BOM. */
374	if( size>=(2*bomSize) && z[2]==0 && z[3]==0 ) goto noBom;
375	memcpy(&i0, z, sizeof(i0));
376	if( i0==0xfeff ){
377	if( pbReverse ) *pbReverse = 0;
378	}else if( i0==0xfffe ){
379	if( pbReverse ) *pbReverse = 1;
380	}else{
381	static const int one = 1;
382	noBom:
383	if( pbReverse ) pbReverse = (char *) &one;
384

M src/main.c

+48 -7

		--- src/main.c
		+++ src/main.c
		@@ -58,10 +58,19 @@
58	58	#endif
59	59	#ifdef HAVE_BACKTRACE
60	60	# include <execinfo.h>
61	61	#endif
62	62
	63	+/*
	64	+** Default length of a timeout for serving an HTTP request. Changable
	65	+** using the "--timeout N" command-line option or via "timeout: N" in the
	66	+** CGI script.
	67	+*/
	68	+#ifndef FOSSIL_DEFAULT_TIMEOUT
	69	+# define FOSSIL_DEFAULT_TIMEOUT 600 /* 10 minutes */
	70	+#endif
	71	+
63	72	/*
64	73	** Maximum number of auxiliary parameters on reports
65	74	*/
66	75	#define MX_AUX 5
67	76
		@@ -1948,10 +1957,13 @@
1948	1957	** debug: FILE Causing debugging information to be written
1949	1958	** into FILE.
1950	1959	**
1951	1960	** errorlog: FILE Warnings, errors, and panics written to FILE.
1952	1961	**
	1962	+** timeout: SECONDS Do not run for longer than SECONDS. The default
	1963	+** timeout is FOSSIL_DEFAULT_TIMEOUT (600) seconds.
	1964	+**
1953	1965	** extroot: DIR Directory that is the root of the sub-CGI tree
1954	1966	** on the /ext page.
1955	1967	**
1956	1968	** redirect: REPO URL Extract the "name" query parameter and search
1957	1969	** REPO for a check-in or ticket that matches the
		@@ -1981,10 +1993,11 @@
1981	1993	g.httpOut = stdout;
1982	1994	g.httpIn = stdin;
1983	1995	fossil_binary_mode(g.httpOut);
1984	1996	fossil_binary_mode(g.httpIn);
1985	1997	g.cgiOutput = 1;
	1998	+ fossil_set_timeout(FOSSIL_DEFAULT_TIMEOUT);
1986	1999	blob_read_from_file(&config, zFile, ExtFILE);
1987	2000	while( blob_line(&config, &line) ){
1988	2001	if( !blob_token(&line, &key) ) continue;
1989	2002	if( blob_buffer(&key)[0]=='#' ) continue;
1990	2003	if( blob_eq(&key, "repository:") && blob_tail(&line, &value) ){
		@@ -2105,10 +2118,19 @@
2105	2118	** Enables the /ext webpage to use sub-cgi rooted at DIRECTORY
2106	2119	*/
2107	2120	g.zExtRoot = mprintf("%s", blob_str(&value));
2108	2121	blob_reset(&value);
2109	2122	continue;
	2123	+ }
	2124	+ if( blob_eq(&key, "timeout:") && blob_token(&line, &value) ){
	2125	+ /* timeout: SECONDS
	2126	+ **
	2127	+ ** Set an alarm() that kills the process after SECONDS. The
	2128	+ ** default value is FOSSIL_DEFAULT_TIMEOUT (600) seconds.
	2129	+ */
	2130	+ fossil_set_timeout(atoi(blob_str(&value)));
	2131	+ continue;
2110	2132	}
2111	2133	if( blob_eq(&key, "HOME:") && blob_token(&line, &value) ){
2112	2134	/* HOME: VALUE
2113	2135	**
2114	2136	** Set CGI parameter "HOME" to VALUE. This is legacy. Use
		@@ -2453,14 +2475,32 @@
2453	2475	}
2454	2476	#endif
2455	2477	#endif
2456	2478
2457	2479	/*
2458		-** Send a time-out reply
	2480	+** Respond to a SIGALRM by writing a message to the error log (if there
	2481	+** is one) and exiting.
2459	2482	*/
2460		-void sigalrm_handler(int x){
	2483	+#ifndef _WIN32
	2484	+static void sigalrm_handler(int x){
2461	2485	fossil_panic("TIMEOUT");
	2486	+}
	2487	+#endif
	2488	+
	2489	+/*
	2490	+** Arrange to timeout using SIGALRM after N seconds. Or if N==0, cancel
	2491	+** any pending timeout.
	2492	+**
	2493	+** Bugs:
	2494	+** (1) This only works on unix systems.
	2495	+** (2) Any call to sleep() or sqlite3_sleep() will cancel the alarm.
	2496	+*/
	2497	+void fossil_set_timeout(int N){
	2498	+#ifndef _WIN32
	2499	+ signal(SIGALRM, sigalrm_handler);
	2500	+ alarm(N);
	2501	+#endif
2462	2502	}
2463	2503
2464	2504	/*
2465	2505	** COMMAND: server*
2466	2506	** COMMAND: ui
		@@ -2539,11 +2579,11 @@
2539	2579	int isUiCmd; /* True if command is "ui", not "server' */
2540	2580	const char zNotFound; / The --notfound option or NULL */
2541	2581	int flags = 0; /* Server flags */
2542	2582	#if !defined(_WIN32)
2543	2583	int noJail; /* Do not enter the chroot jail */
2544		- const char zMaxLatency; / Maximum runtime of any single HTTP request */
	2584	+ const char zTimeout = 0; / Max runtime of any single HTTP request */
2545	2585	#endif
2546	2586	int allowRepoList; /* List repositories on URL "/" */
2547	2587	const char zAltBase; / Argument to the --baseurl option */
2548	2588	const char zFileGlob; / Static content must match this */
2549	2589	char zIpAddr = 0; / Bind to this IP address */
		@@ -2571,11 +2611,11 @@
2571	2611	zFileGlob = find_option("files",0,1);
2572	2612	}
2573	2613	skin_override();
2574	2614	#if !defined(_WIN32)
2575	2615	noJail = find_option("nojail",0,0)!=0;
2576		- zMaxLatency = find_option("max-latency",0,1);
	2616	+ zTimeout = find_option("max-latency",0,1);
2577	2617	#endif
2578	2618	g.useLocalauth = find_option("localauth", 0, 0)!=0;
2579	2619	Th_InitTraceLog();
2580	2620	zPort = find_option("port", "P", 1);
2581	2621	isUiCmd = g.argv[1][0]=='u';
		@@ -2689,13 +2729,14 @@
2689	2729	**
2690	2730	** So, when control reaches this point, we are running as a
2691	2731	** child process, the HTTP or SCGI request is pending on file
2692	2732	** descriptor 0 and the reply should be written to file descriptor 1.
2693	2733	*/
2694		- if( zMaxLatency ){
2695		- signal(SIGALRM, sigalrm_handler);
2696		- alarm(atoi(zMaxLatency));
	2734	+ if( zTimeout ){
	2735	+ fossil_set_timeout(atoi(zTimeout));
	2736	+ }else{
	2737	+ fossil_set_timeout(FOSSIL_DEFAULT_TIMEOUT);
2697	2738	}
2698	2739	g.httpIn = stdin;
2699	2740	g.httpOut = stdout;
2700	2741
2701	2742	#if !defined(_WIN32)
2702	2743

	--- src/main.c
	+++ src/main.c
	@@ -58,10 +58,19 @@
58	#endif
59	#ifdef HAVE_BACKTRACE
60	# include <execinfo.h>
61	#endif
62









63	/*
64	** Maximum number of auxiliary parameters on reports
65	*/
66	#define MX_AUX 5
67
	@@ -1948,10 +1957,13 @@
1948	** debug: FILE Causing debugging information to be written
1949	** into FILE.
1950	**
1951	** errorlog: FILE Warnings, errors, and panics written to FILE.
1952	**



1953	** extroot: DIR Directory that is the root of the sub-CGI tree
1954	** on the /ext page.
1955	**
1956	** redirect: REPO URL Extract the "name" query parameter and search
1957	** REPO for a check-in or ticket that matches the
	@@ -1981,10 +1993,11 @@
1981	g.httpOut = stdout;
1982	g.httpIn = stdin;
1983	fossil_binary_mode(g.httpOut);
1984	fossil_binary_mode(g.httpIn);
1985	g.cgiOutput = 1;

1986	blob_read_from_file(&config, zFile, ExtFILE);
1987	while( blob_line(&config, &line) ){
1988	if( !blob_token(&line, &key) ) continue;
1989	if( blob_buffer(&key)[0]=='#' ) continue;
1990	if( blob_eq(&key, "repository:") && blob_tail(&line, &value) ){
	@@ -2105,10 +2118,19 @@
2105	** Enables the /ext webpage to use sub-cgi rooted at DIRECTORY
2106	*/
2107	g.zExtRoot = mprintf("%s", blob_str(&value));
2108	blob_reset(&value);
2109	continue;









2110	}
2111	if( blob_eq(&key, "HOME:") && blob_token(&line, &value) ){
2112	/* HOME: VALUE
2113	**
2114	** Set CGI parameter "HOME" to VALUE. This is legacy. Use
	@@ -2453,14 +2475,32 @@
2453	}
2454	#endif
2455	#endif
2456
2457	/*
2458	** Send a time-out reply

2459	*/
2460	void sigalrm_handler(int x){

2461	fossil_panic("TIMEOUT");
















2462	}
2463
2464	/*
2465	** COMMAND: server*
2466	** COMMAND: ui
	@@ -2539,11 +2579,11 @@
2539	int isUiCmd; /* True if command is "ui", not "server' */
2540	const char zNotFound; / The --notfound option or NULL */
2541	int flags = 0; /* Server flags */
2542	#if !defined(_WIN32)
2543	int noJail; /* Do not enter the chroot jail */
2544	const char zMaxLatency; / Maximum runtime of any single HTTP request */
2545	#endif
2546	int allowRepoList; /* List repositories on URL "/" */
2547	const char zAltBase; / Argument to the --baseurl option */
2548	const char zFileGlob; / Static content must match this */
2549	char zIpAddr = 0; / Bind to this IP address */
	@@ -2571,11 +2611,11 @@
2571	zFileGlob = find_option("files",0,1);
2572	}
2573	skin_override();
2574	#if !defined(_WIN32)
2575	noJail = find_option("nojail",0,0)!=0;
2576	zMaxLatency = find_option("max-latency",0,1);
2577	#endif
2578	g.useLocalauth = find_option("localauth", 0, 0)!=0;
2579	Th_InitTraceLog();
2580	zPort = find_option("port", "P", 1);
2581	isUiCmd = g.argv[1][0]=='u';
	@@ -2689,13 +2729,14 @@
2689	**
2690	** So, when control reaches this point, we are running as a
2691	** child process, the HTTP or SCGI request is pending on file
2692	** descriptor 0 and the reply should be written to file descriptor 1.
2693	*/
2694	if( zMaxLatency ){
2695	signal(SIGALRM, sigalrm_handler);
2696	alarm(atoi(zMaxLatency));

2697	}
2698	g.httpIn = stdin;
2699	g.httpOut = stdout;
2700
2701	#if !defined(_WIN32)
2702

	--- src/main.c
	+++ src/main.c
	@@ -58,10 +58,19 @@
58	#endif
59	#ifdef HAVE_BACKTRACE
60	# include <execinfo.h>
61	#endif
62
63	/*
64	** Default length of a timeout for serving an HTTP request. Changable
65	** using the "--timeout N" command-line option or via "timeout: N" in the
66	** CGI script.
67	*/
68	#ifndef FOSSIL_DEFAULT_TIMEOUT
69	# define FOSSIL_DEFAULT_TIMEOUT 600 /* 10 minutes */
70	#endif
71
72	/*
73	** Maximum number of auxiliary parameters on reports
74	*/
75	#define MX_AUX 5
76
	@@ -1948,10 +1957,13 @@
1957	** debug: FILE Causing debugging information to be written
1958	** into FILE.
1959	**
1960	** errorlog: FILE Warnings, errors, and panics written to FILE.
1961	**
1962	** timeout: SECONDS Do not run for longer than SECONDS. The default
1963	** timeout is FOSSIL_DEFAULT_TIMEOUT (600) seconds.
1964	**
1965	** extroot: DIR Directory that is the root of the sub-CGI tree
1966	** on the /ext page.
1967	**
1968	** redirect: REPO URL Extract the "name" query parameter and search
1969	** REPO for a check-in or ticket that matches the
	@@ -1981,10 +1993,11 @@
1993	g.httpOut = stdout;
1994	g.httpIn = stdin;
1995	fossil_binary_mode(g.httpOut);
1996	fossil_binary_mode(g.httpIn);
1997	g.cgiOutput = 1;
1998	fossil_set_timeout(FOSSIL_DEFAULT_TIMEOUT);
1999	blob_read_from_file(&config, zFile, ExtFILE);
2000	while( blob_line(&config, &line) ){
2001	if( !blob_token(&line, &key) ) continue;
2002	if( blob_buffer(&key)[0]=='#' ) continue;
2003	if( blob_eq(&key, "repository:") && blob_tail(&line, &value) ){
	@@ -2105,10 +2118,19 @@
2118	** Enables the /ext webpage to use sub-cgi rooted at DIRECTORY
2119	*/
2120	g.zExtRoot = mprintf("%s", blob_str(&value));
2121	blob_reset(&value);
2122	continue;
2123	}
2124	if( blob_eq(&key, "timeout:") && blob_token(&line, &value) ){
2125	/* timeout: SECONDS
2126	**
2127	** Set an alarm() that kills the process after SECONDS. The
2128	** default value is FOSSIL_DEFAULT_TIMEOUT (600) seconds.
2129	*/
2130	fossil_set_timeout(atoi(blob_str(&value)));
2131	continue;
2132	}
2133	if( blob_eq(&key, "HOME:") && blob_token(&line, &value) ){
2134	/* HOME: VALUE
2135	**
2136	** Set CGI parameter "HOME" to VALUE. This is legacy. Use
	@@ -2453,14 +2475,32 @@
2475	}
2476	#endif
2477	#endif
2478
2479	/*
2480	** Respond to a SIGALRM by writing a message to the error log (if there
2481	** is one) and exiting.
2482	*/
2483	#ifndef _WIN32
2484	static void sigalrm_handler(int x){
2485	fossil_panic("TIMEOUT");
2486	}
2487	#endif
2488
2489	/*
2490	** Arrange to timeout using SIGALRM after N seconds. Or if N==0, cancel
2491	** any pending timeout.
2492	**
2493	** Bugs:
2494	** (1) This only works on unix systems.
2495	** (2) Any call to sleep() or sqlite3_sleep() will cancel the alarm.
2496	*/
2497	void fossil_set_timeout(int N){
2498	#ifndef _WIN32
2499	signal(SIGALRM, sigalrm_handler);
2500	alarm(N);
2501	#endif
2502	}
2503
2504	/*
2505	** COMMAND: server*
2506	** COMMAND: ui
	@@ -2539,11 +2579,11 @@
2579	int isUiCmd; /* True if command is "ui", not "server' */
2580	const char zNotFound; / The --notfound option or NULL */
2581	int flags = 0; /* Server flags */
2582	#if !defined(_WIN32)
2583	int noJail; /* Do not enter the chroot jail */
2584	const char zTimeout = 0; / Max runtime of any single HTTP request */
2585	#endif
2586	int allowRepoList; /* List repositories on URL "/" */
2587	const char zAltBase; / Argument to the --baseurl option */
2588	const char zFileGlob; / Static content must match this */
2589	char zIpAddr = 0; / Bind to this IP address */
	@@ -2571,11 +2611,11 @@
2611	zFileGlob = find_option("files",0,1);
2612	}
2613	skin_override();
2614	#if !defined(_WIN32)
2615	noJail = find_option("nojail",0,0)!=0;
2616	zTimeout = find_option("max-latency",0,1);
2617	#endif
2618	g.useLocalauth = find_option("localauth", 0, 0)!=0;
2619	Th_InitTraceLog();
2620	zPort = find_option("port", "P", 1);
2621	isUiCmd = g.argv[1][0]=='u';
	@@ -2689,13 +2729,14 @@
2729	**
2730	** So, when control reaches this point, we are running as a
2731	** child process, the HTTP or SCGI request is pending on file
2732	** descriptor 0 and the reply should be written to file descriptor 1.
2733	*/
2734	if( zTimeout ){
2735	fossil_set_timeout(atoi(zTimeout));
2736	}else{
2737	fossil_set_timeout(FOSSIL_DEFAULT_TIMEOUT);
2738	}
2739	g.httpIn = stdin;
2740	g.httpOut = stdout;
2741
2742	#if !defined(_WIN32)
2743

M src/markdown.md

+5 -3

		--- src/markdown.md
		+++ src/markdown.md
		@@ -38,21 +38,23 @@
38	38	> * \[label\]: URL
39	39	> * \[label\]: URL "Title"
40	40	> * \[label\]: URL 'Title'
41	41	> * \[label\]: URL (Title)
42	42
43		-> URL may optionally be written \<URL\>.
44		-> In addition to ordinary URLs, the URL may be:
	43	+> If URL begins with "http:", "https:', "ftp:' or "mailto:",
	44	+> it may optionally be written \<URL\> (format 4).
	45	+> Other URL formats include:
45	46	> <ul>
	47	+> <li> A relative pathname.
46	48	> <li> A pathname starting with "/" in which case the Fossil server
47	49	> URL prefix is prepended
48	50	> <li> A wiki page name, or a wiki page name preceded by "wiki:"
49	51	> <li> An artifact or ticket hash or hash prefix
50	52	> <li> A date and time stamp: "YYYY-MM-DD HH:MM:SS" or a subset that
51	53	> includes at least the day of the month.</ul>
52	54
53		-> In form 8, then the URL becomes the display text. This is useful for
	55	+> In format 8, then the URL becomes the display text. This is useful for
54	56	> hyperlinks that refer to wiki pages and check-in and ticket hashes.
55	57
56	58	## Fonts ##
57	59
58	60	> * _\italic\_
59	61

	--- src/markdown.md
	+++ src/markdown.md
	@@ -38,21 +38,23 @@
38	> * \[label\]: URL
39	> * \[label\]: URL "Title"
40	> * \[label\]: URL 'Title'
41	> * \[label\]: URL (Title)
42
43	> URL may optionally be written \<URL\>.
44	> In addition to ordinary URLs, the URL may be:

45	> <ul>

46	> <li> A pathname starting with "/" in which case the Fossil server
47	> URL prefix is prepended
48	> <li> A wiki page name, or a wiki page name preceded by "wiki:"
49	> <li> An artifact or ticket hash or hash prefix
50	> <li> A date and time stamp: "YYYY-MM-DD HH:MM:SS" or a subset that
51	> includes at least the day of the month.</ul>
52
53	> In form 8, then the URL becomes the display text. This is useful for
54	> hyperlinks that refer to wiki pages and check-in and ticket hashes.
55
56	## Fonts ##
57
58	> * _\italic\_
59

	--- src/markdown.md
	+++ src/markdown.md
	@@ -38,21 +38,23 @@
38	> * \[label\]: URL
39	> * \[label\]: URL "Title"
40	> * \[label\]: URL 'Title'
41	> * \[label\]: URL (Title)
42
43	> If URL begins with "http:", "https:', "ftp:' or "mailto:",
44	> it may optionally be written \<URL\> (format 4).
45	> Other URL formats include:
46	> <ul>
47	> <li> A relative pathname.
48	> <li> A pathname starting with "/" in which case the Fossil server
49	> URL prefix is prepended
50	> <li> A wiki page name, or a wiki page name preceded by "wiki:"
51	> <li> An artifact or ticket hash or hash prefix
52	> <li> A date and time stamp: "YYYY-MM-DD HH:MM:SS" or a subset that
53	> includes at least the day of the month.</ul>
54
55	> In format 8, then the URL becomes the display text. This is useful for
56	> hyperlinks that refer to wiki pages and check-in and ticket hashes.
57
58	## Fonts ##
59
60	> * _\italic\_
61

M src/security_audit.c

+80

		--- src/security_audit.c
		+++ src/security_audit.c
		@@ -32,10 +32,69 @@
32	32	zTest++;
33	33	}
34	34	return 0;
35	35	}
36	36
	37	+/*
	38	+** Extract the content-security-policy from the reply header. Parse it
	39	+** up into separate fields, and return a pointer to a null-terminated
	40	+** array of pointers to strings, one entry for each field. Or return
	41	+** a NULL pointer if no CSP could be located in the header.
	42	+**
	43	+** Memory to hold the returned array and of the strings is obtained from
	44	+** a single memory allocation, which the caller should free to avoid a
	45	+** memory leak.
	46	+*/
	47	+static char **parse_content_security_policy(void){
	48	+ char **azCSP = 0;
	49	+ int nCSP = 0;
	50	+ const char *zHeader;
	51	+ const char *zAll;
	52	+ char *zCopy;
	53	+ int nAll = 0;
	54	+ int ii, jj, n, nx = 0;
	55	+ int nSemi;
	56	+
	57	+ zHeader = cgi_header();
	58	+ if( zHeader==0 ) return 0;
	59	+ for(ii=0; zHeader[ii]; ii+=n){
	60	+ n = html_token_length(zHeader+ii);
	61	+ if( zHeader[ii]=='<'
	62	+ && fossil_strnicmp(html_attribute(zHeader+ii,"http-equiv",&nx),
	63	+ "Content-Security-Policy",23)==0
	64	+ && nx==23
	65	+ && (zAll = html_attribute(zHeader+ii,"content",&nAll))!=0
	66	+ ){
	67	+ for(jj=nSemi=0; jj<nAll; jj++){ if( zAll[jj]==';' ) nSemi++; }
	68	+ azCSP = fossil_malloc( nAll+1 + (nSemi+2)sizeof(char) );
	69	+ zCopy = (char*)&azCSP[nSemi+2];
	70	+ memcpy(zCopy,zAll,nAll);
	71	+ zCopy[nAll] = 0;
	72	+ while( fossil_isspace(zCopy[0]) \|\| zCopy[0]==';' ){ zCopy++; }
	73	+ azCSP[0] = zCopy;
	74	+ nCSP = 1;
	75	+ for(jj=0; zCopy[jj]; jj++){
	76	+ if( zCopy[jj]==';' ){
	77	+ int k;
	78	+ for(k=jj-1; k>0 && fossil_isspace(zCopy[k]); k--){ zCopy[k] = 0; }
	79	+ zCopy[jj] = 0;
	80	+ while( jj+1<nAll
	81	+ && (fossil_isspace(zCopy[jj+1]) \|\| zCopy[jj+1]==';')
	82	+ ){
	83	+ jj++;
	84	+ }
	85	+ assert( nCSP<nSemi+1 );
	86	+ azCSP[nCSP++] = zCopy+jj;
	87	+ }
	88	+ }
	89	+ assert( nCSP<=nSemi+2 );
	90	+ azCSP[nCSP] = 0;
	91	+ return azCSP;
	92	+ }
	93	+ }
	94	+ return 0;
	95	+}
37	96
38	97	/*
39	98	** WEBPAGE: secaudit0
40	99	**
41	100	** Run a security audit of the current Fossil setup, looking
		@@ -50,10 +109,11 @@
50	109	const char zAnonCap; / Capabilities of user "anonymous" and "nobody" */
51	110	const char zPubPages; / GLOB pattern for public pages */
52	111	const char zSelfCap; / Capabilities of self-registered users */
53	112	char *z;
54	113	int n;
	114	+ char *azCSP; / Parsed content security policy */
55	115
56	116	login_check_credentials();
57	117	if( !g.perm.Admin ){
58	118	login_needed(0);
59	119	return;
		@@ -439,10 +499,30 @@
439	499	}
440	500
441	501	@ <li><p> User capability summary:
442	502	capability_summary();
443	503
	504	+
	505	+ azCSP = parse_content_security_policy();
	506	+ if( azCSP==0 ){
	507	+ @ <li><p> WARNING: No Content Security Policy (CSP) is specified in the
	508	+ @ header. Though not required, a strong CSP is recommended. Fossil will
	509	+ @ automatically insert an appropriate CSP if you let it generate the
	510	+ @ HTML <tt><head></tt> element by omitting <tt><body></tt>
	511	+ @ from the header configuration in your customized skin.
	512	+ @
	513	+ }else{
	514	+ int ii;
	515	+ @ <li><p> Content Security Policy:
	516	+ @ <ol type="a">
	517	+ for(ii=0; azCSP[ii]; ii++){
	518	+ @ <li>%h(azCSP[ii])
	519	+ }
	520	+ @ </ol>
	521	+ }
	522	+ fossil_free(azCSP);
	523	+
444	524	if( alert_enabled() ){
445	525	@ <li><p> Email alert configuration summary:
446	526	@ <table class="label-value">
447	527	stats_for_email();
448	528	@ </table>
449	529

	--- src/security_audit.c
	+++ src/security_audit.c
	@@ -32,10 +32,69 @@
32	zTest++;
33	}
34	return 0;
35	}
36



























































37
38	/*
39	** WEBPAGE: secaudit0
40	**
41	** Run a security audit of the current Fossil setup, looking
	@@ -50,10 +109,11 @@
50	const char zAnonCap; / Capabilities of user "anonymous" and "nobody" */
51	const char zPubPages; / GLOB pattern for public pages */
52	const char zSelfCap; / Capabilities of self-registered users */
53	char *z;
54	int n;

55
56	login_check_credentials();
57	if( !g.perm.Admin ){
58	login_needed(0);
59	return;
	@@ -439,10 +499,30 @@
439	}
440
441	@ <li><p> User capability summary:
442	capability_summary();
443




















444	if( alert_enabled() ){
445	@ <li><p> Email alert configuration summary:
446	@ <table class="label-value">
447	stats_for_email();
448	@ </table>
449

	--- src/security_audit.c
	+++ src/security_audit.c
	@@ -32,10 +32,69 @@
32	zTest++;
33	}
34	return 0;
35	}
36
37	/*
38	** Extract the content-security-policy from the reply header. Parse it
39	** up into separate fields, and return a pointer to a null-terminated
40	** array of pointers to strings, one entry for each field. Or return
41	** a NULL pointer if no CSP could be located in the header.
42	**
43	** Memory to hold the returned array and of the strings is obtained from
44	** a single memory allocation, which the caller should free to avoid a
45	** memory leak.
46	*/
47	static char **parse_content_security_policy(void){
48	char **azCSP = 0;
49	int nCSP = 0;
50	const char *zHeader;
51	const char *zAll;
52	char *zCopy;
53	int nAll = 0;
54	int ii, jj, n, nx = 0;
55	int nSemi;
56
57	zHeader = cgi_header();
58	if( zHeader==0 ) return 0;
59	for(ii=0; zHeader[ii]; ii+=n){
60	n = html_token_length(zHeader+ii);
61	if( zHeader[ii]=='<'
62	&& fossil_strnicmp(html_attribute(zHeader+ii,"http-equiv",&nx),
63	"Content-Security-Policy",23)==0
64	&& nx==23
65	&& (zAll = html_attribute(zHeader+ii,"content",&nAll))!=0
66	){
67	for(jj=nSemi=0; jj<nAll; jj++){ if( zAll[jj]==';' ) nSemi++; }
68	azCSP = fossil_malloc( nAll+1 + (nSemi+2)sizeof(char) );
69	zCopy = (char*)&azCSP[nSemi+2];
70	memcpy(zCopy,zAll,nAll);
71	zCopy[nAll] = 0;
72	while( fossil_isspace(zCopy[0]) \|\| zCopy[0]==';' ){ zCopy++; }
73	azCSP[0] = zCopy;
74	nCSP = 1;
75	for(jj=0; zCopy[jj]; jj++){
76	if( zCopy[jj]==';' ){
77	int k;
78	for(k=jj-1; k>0 && fossil_isspace(zCopy[k]); k--){ zCopy[k] = 0; }
79	zCopy[jj] = 0;
80	while( jj+1<nAll
81	&& (fossil_isspace(zCopy[jj+1]) \|\| zCopy[jj+1]==';')
82	){
83	jj++;
84	}
85	assert( nCSP<nSemi+1 );
86	azCSP[nCSP++] = zCopy+jj;
87	}
88	}
89	assert( nCSP<=nSemi+2 );
90	azCSP[nCSP] = 0;
91	return azCSP;
92	}
93	}
94	return 0;
95	}
96
97	/*
98	** WEBPAGE: secaudit0
99	**
100	** Run a security audit of the current Fossil setup, looking
	@@ -50,10 +109,11 @@
109	const char zAnonCap; / Capabilities of user "anonymous" and "nobody" */
110	const char zPubPages; / GLOB pattern for public pages */
111	const char zSelfCap; / Capabilities of self-registered users */
112	char *z;
113	int n;
114	char *azCSP; / Parsed content security policy */
115
116	login_check_credentials();
117	if( !g.perm.Admin ){
118	login_needed(0);
119	return;
	@@ -439,10 +499,30 @@
499	}
500
501	@ <li><p> User capability summary:
502	capability_summary();
503
504
505	azCSP = parse_content_security_policy();
506	if( azCSP==0 ){
507	@ <li><p> WARNING: No Content Security Policy (CSP) is specified in the
508	@ header. Though not required, a strong CSP is recommended. Fossil will
509	@ automatically insert an appropriate CSP if you let it generate the
510	@ HTML <tt><head></tt> element by omitting <tt><body></tt>
511	@ from the header configuration in your customized skin.
512	@
513	}else{
514	int ii;
515	@ <li><p> Content Security Policy:
516	@ <ol type="a">
517	for(ii=0; azCSP[ii]; ii++){
518	@ <li>%h(azCSP[ii])
519	}
520	@ </ol>
521	}
522	fossil_free(azCSP);
523
524	if( alert_enabled() ){
525	@ <li><p> Email alert configuration summary:
526	@ <table class="label-value">
527	stats_for_email();
528	@ </table>
529

M src/stat.c

+3 -1

		--- src/stat.c
		+++ src/stat.c
		@@ -681,10 +681,12 @@
681	681	@ UPDATE artstat SET atype='file'
682	682	@ WHERE id IN (SELECT fid FROM mlink)
683	683	@ AND atype IS NULL;
684	684	@ UPDATE artstat SET atype='manifest'
685	685	@ WHERE id IN (SELECT objid FROM event WHERE type='ci') AND atype IS NULL;
	686	+ @ UPDATE artstat SET atype='forum'
	687	+ @ WHERE id IN (SELECT objid FROM event WHERE type='f') AND atype IS NULL;
686	688	@ UPDATE artstat SET atype='cluster'
687	689	@ WHERE atype IS NULL
688	690	@ AND id IN (SELECT rid FROM tagxref
689	691	@ WHERE tagid=(SELECT tagid FROM tag
690	692	@ WHERE tagname='cluster'));
		@@ -845,11 +847,11 @@
845	847	" LIMIT 1 OFFSET %d", nFull/2);
846	848	@ <tr><th>Full-text artifact sizes:</th>
847	849	@ <td>largest: %,d(mxCmpr), average: %,d((int)r), median: %,d(med)</td>
848	850	@ </table>
849	851
850		- @ <h1>Artifact size distribution facts:</h1>
	852	+ @ <h1>Artifact Size Distribution Facts:</h1>
851	853	@ <ol>
852	854	@ <li><p>The largest %.2f(n50pct*100.0/nTotal)%% of artifacts
853	855	largest_n_artifacts(n50pct);
854	856	@ use 50%% of the total artifact space.
855	857	@ <li><p>The largest 1%% of artifacts
856	858

	--- src/stat.c
	+++ src/stat.c
	@@ -681,10 +681,12 @@
681	@ UPDATE artstat SET atype='file'
682	@ WHERE id IN (SELECT fid FROM mlink)
683	@ AND atype IS NULL;
684	@ UPDATE artstat SET atype='manifest'
685	@ WHERE id IN (SELECT objid FROM event WHERE type='ci') AND atype IS NULL;


686	@ UPDATE artstat SET atype='cluster'
687	@ WHERE atype IS NULL
688	@ AND id IN (SELECT rid FROM tagxref
689	@ WHERE tagid=(SELECT tagid FROM tag
690	@ WHERE tagname='cluster'));
	@@ -845,11 +847,11 @@
845	" LIMIT 1 OFFSET %d", nFull/2);
846	@ <tr><th>Full-text artifact sizes:</th>
847	@ <td>largest: %,d(mxCmpr), average: %,d((int)r), median: %,d(med)</td>
848	@ </table>
849
850	@ <h1>Artifact size distribution facts:</h1>
851	@ <ol>
852	@ <li><p>The largest %.2f(n50pct*100.0/nTotal)%% of artifacts
853	largest_n_artifacts(n50pct);
854	@ use 50%% of the total artifact space.
855	@ <li><p>The largest 1%% of artifacts
856

	--- src/stat.c
	+++ src/stat.c
	@@ -681,10 +681,12 @@
681	@ UPDATE artstat SET atype='file'
682	@ WHERE id IN (SELECT fid FROM mlink)
683	@ AND atype IS NULL;
684	@ UPDATE artstat SET atype='manifest'
685	@ WHERE id IN (SELECT objid FROM event WHERE type='ci') AND atype IS NULL;
686	@ UPDATE artstat SET atype='forum'
687	@ WHERE id IN (SELECT objid FROM event WHERE type='f') AND atype IS NULL;
688	@ UPDATE artstat SET atype='cluster'
689	@ WHERE atype IS NULL
690	@ AND id IN (SELECT rid FROM tagxref
691	@ WHERE tagid=(SELECT tagid FROM tag
692	@ WHERE tagname='cluster'));
	@@ -845,11 +847,11 @@
847	" LIMIT 1 OFFSET %d", nFull/2);
848	@ <tr><th>Full-text artifact sizes:</th>
849	@ <td>largest: %,d(mxCmpr), average: %,d((int)r), median: %,d(med)</td>
850	@ </table>
851
852	@ <h1>Artifact Size Distribution Facts:</h1>
853	@ <ol>
854	@ <li><p>The largest %.2f(n50pct*100.0/nTotal)%% of artifacts
855	largest_n_artifacts(n50pct);
856	@ use 50%% of the total artifact space.
857	@ <li><p>The largest 1%% of artifacts
858

M src/statrep.c

+10 -2

		--- src/statrep.c
		+++ src/statrep.c
		@@ -50,11 +50,11 @@
50	50	** the event list. Note that a filter of "*" or "all" is equivalent to
51	51	** querying against the full event table. The view, however, adds an
52	52	** abstraction level to simplify the implementation code for the
53	53	** various /reports pages.
54	54	**
55		-** Returns one of: 'c', 'w', 'g', 't', 'e', representing the type of
	55	+** Returns one of: 'c', 'f', 'w', 'g', 't', 'e', representing the type of
56	56	** filter it applies, or '*' if no filter is applied (i.e. if "all" is
57	57	** used).
58	58	*/
59	59	static int stats_report_init_view(){
60	60	const char zType = PD("type",""); /* analog to /timeline?y=... */
		@@ -71,10 +71,15 @@
71	71	case 'e':
72	72	case 'E':
73	73	zRealType = "e";
74	74	rc = *zRealType;
75	75	break;
	76	+ case 'f':
	77	+ case 'F':
	78	+ zRealType = "f";
	79	+ rc = *zRealType;
	80	+ break;
76	81	case 'g':
77	82	case 'G':
78	83	zRealType = "g";
79	84	rc = *zRealType;
80	85	break;
		@@ -124,10 +129,12 @@
124	129	switch( statsReportType ){
125	130	case 'c':
126	131	return "check-ins";
127	132	case 'e':
128	133	return "technotes";
	134	+ case 'f':
	135	+ return "forum posts";
129	136	case 'w':
130	137	return "wiki changes";
131	138	case 't':
132	139	return "ticket changes";
133	140	case 'g':
		@@ -718,11 +725,11 @@
718	725	** Query Parameters:
719	726	**
720	727	** view=REPORT_NAME Valid values: bymonth, byyear, byuser
721	728	** user=NAME Restricts statistics to the given user
722	729	** type=TYPE Restricts the report to a specific event type:
723		-** ci (check-in), w (wiki), t (ticket), g (tag)
	730	+** ci (check-in), f (forum), w (wiki), t (ticket), g (tag)
724	731	** Defaulting to all event types.
725	732	**
726	733	** The view-specific query parameters include:
727	734	**
728	735	** view=byweek:
		@@ -750,10 +757,11 @@
750	757	{ "By Year", "byyear", RPT_BYYEAR },
751	758	};
752	759	static const char *const azType[] = {
753	760	"a", "All Changes",
754	761	"ci", "Check-ins",
	762	+ "f", "Forum Posts",
755	763	"g", "Tags",
756	764	"e", "Tech Notes",
757	765	"t", "Tickets",
758	766	"w", "Wiki"
759	767	};
760	768

	--- src/statrep.c
	+++ src/statrep.c
	@@ -50,11 +50,11 @@
50	** the event list. Note that a filter of "*" or "all" is equivalent to
51	** querying against the full event table. The view, however, adds an
52	** abstraction level to simplify the implementation code for the
53	** various /reports pages.
54	**
55	** Returns one of: 'c', 'w', 'g', 't', 'e', representing the type of
56	** filter it applies, or '*' if no filter is applied (i.e. if "all" is
57	** used).
58	*/
59	static int stats_report_init_view(){
60	const char zType = PD("type",""); /* analog to /timeline?y=... */
	@@ -71,10 +71,15 @@
71	case 'e':
72	case 'E':
73	zRealType = "e";
74	rc = *zRealType;
75	break;





76	case 'g':
77	case 'G':
78	zRealType = "g";
79	rc = *zRealType;
80	break;
	@@ -124,10 +129,12 @@
124	switch( statsReportType ){
125	case 'c':
126	return "check-ins";
127	case 'e':
128	return "technotes";


129	case 'w':
130	return "wiki changes";
131	case 't':
132	return "ticket changes";
133	case 'g':
	@@ -718,11 +725,11 @@
718	** Query Parameters:
719	**
720	** view=REPORT_NAME Valid values: bymonth, byyear, byuser
721	** user=NAME Restricts statistics to the given user
722	** type=TYPE Restricts the report to a specific event type:
723	** ci (check-in), w (wiki), t (ticket), g (tag)
724	** Defaulting to all event types.
725	**
726	** The view-specific query parameters include:
727	**
728	** view=byweek:
	@@ -750,10 +757,11 @@
750	{ "By Year", "byyear", RPT_BYYEAR },
751	};
752	static const char *const azType[] = {
753	"a", "All Changes",
754	"ci", "Check-ins",

755	"g", "Tags",
756	"e", "Tech Notes",
757	"t", "Tickets",
758	"w", "Wiki"
759	};
760

	--- src/statrep.c
	+++ src/statrep.c
	@@ -50,11 +50,11 @@
50	** the event list. Note that a filter of "*" or "all" is equivalent to
51	** querying against the full event table. The view, however, adds an
52	** abstraction level to simplify the implementation code for the
53	** various /reports pages.
54	**
55	** Returns one of: 'c', 'f', 'w', 'g', 't', 'e', representing the type of
56	** filter it applies, or '*' if no filter is applied (i.e. if "all" is
57	** used).
58	*/
59	static int stats_report_init_view(){
60	const char zType = PD("type",""); /* analog to /timeline?y=... */
	@@ -71,10 +71,15 @@
71	case 'e':
72	case 'E':
73	zRealType = "e";
74	rc = *zRealType;
75	break;
76	case 'f':
77	case 'F':
78	zRealType = "f";
79	rc = *zRealType;
80	break;
81	case 'g':
82	case 'G':
83	zRealType = "g";
84	rc = *zRealType;
85	break;
	@@ -124,10 +129,12 @@
129	switch( statsReportType ){
130	case 'c':
131	return "check-ins";
132	case 'e':
133	return "technotes";
134	case 'f':
135	return "forum posts";
136	case 'w':
137	return "wiki changes";
138	case 't':
139	return "ticket changes";
140	case 'g':
	@@ -718,11 +725,11 @@
725	** Query Parameters:
726	**
727	** view=REPORT_NAME Valid values: bymonth, byyear, byuser
728	** user=NAME Restricts statistics to the given user
729	** type=TYPE Restricts the report to a specific event type:
730	** ci (check-in), f (forum), w (wiki), t (ticket), g (tag)
731	** Defaulting to all event types.
732	**
733	** The view-specific query parameters include:
734	**
735	** view=byweek:
	@@ -750,10 +757,11 @@
757	{ "By Year", "byyear", RPT_BYYEAR },
758	};
759	static const char *const azType[] = {
760	"a", "All Changes",
761	"ci", "Check-ins",
762	"f", "Forum Posts",
763	"g", "Tags",
764	"e", "Tech Notes",
765	"t", "Tickets",
766	"w", "Wiki"
767	};
768

M src/th.c

+20 -12

		--- src/th.c
		+++ src/th.c
		@@ -202,10 +202,18 @@
202	202	};
203	203	typedef struct Buffer Buffer;
204	204	static int thBufferWrite(Th_Interp interp, Buffer , const char *, int);
205	205	static void thBufferInit(Buffer *);
206	206	static void thBufferFree(Th_Interp interp, Buffer );
	207	+
	208	+/*
	209	+** This version of memcpy() allows the first are second argument to
	210	+** be NULL as long as the number of bytes to copy is zero.
	211	+*/
	212	+static void th_memcpy(void dest, const void *src, size_t n){
	213	+ return n>0 ? memcpy(dest,src,n) : dest;
	214	+}
207	215
208	216	/*
209	217	** Append nAdd bytes of content copied from zAdd to the end of buffer
210	218	** pBuffer. If there is not enough space currently allocated, resize
211	219	** the allocation to make space.
		@@ -227,17 +235,17 @@
227	235	char *zNew;
228	236	int nNew;
229	237
230	238	nNew = nReq*2;
231	239	zNew = (char *)Th_Malloc(interp, nNew);
232		- memcpy(zNew, pBuffer->zBuf, pBuffer->nBuf);
	240	+ th_memcpy(zNew, pBuffer->zBuf, pBuffer->nBuf);
233	241	Th_Free(interp, pBuffer->zBuf);
234	242	pBuffer->nBufAlloc = nNew;
235	243	pBuffer->zBuf = zNew;
236	244	}
237	245
238		- memcpy(&pBuffer->zBuf[pBuffer->nBuf], zAdd, nAdd);
	246	+ th_memcpy(&pBuffer->zBuf[pBuffer->nBuf], zAdd, nAdd);
239	247	pBuffer->nBuf += nAdd;
240	248	pBuffer->zBuf[pBuffer->nBuf] = '\0';
241	249
242	250	return TH_OK;
243	251	}
		@@ -841,12 +849,12 @@
841	849	sizeof(int) * nCount + /* anElem */
842	850	strbuf.nBuf /* space for list element strings */
843	851	);
844	852	anElem = (int *)&azElem[nCount];
845	853	zElem = (char *)&anElem[nCount];
846		- memcpy(anElem, lenbuf.zBuf, lenbuf.nBuf);
847		- memcpy(zElem, strbuf.zBuf, strbuf.nBuf);
	854	+ th_memcpy(anElem, lenbuf.zBuf, lenbuf.nBuf);
	855	+ th_memcpy(zElem, strbuf.zBuf, strbuf.nBuf);
848	856	for(i=0; i<nCount;i++){
849	857	azElem[i] = zElem;
850	858	zElem += (anElem[i] + 1);
851	859	}
852	860	*pazElem = azElem;
		@@ -1293,11 +1301,11 @@
1293	1301	}
1294	1302
1295	1303	assert(zValue \|\| nValue==0);
1296	1304	pValue->zData = Th_Malloc(interp, nValue+1);
1297	1305	pValue->zData[nValue] = '\0';
1298		- memcpy(pValue->zData, zValue, nValue);
	1306	+ th_memcpy(pValue->zData, zValue, nValue);
1299	1307	pValue->nData = nValue;
1300	1308
1301	1309	return TH_OK;
1302	1310	}
1303	1311
		@@ -1412,11 +1420,11 @@
1412	1420	char *zRes;
1413	1421	if( n<0 ){
1414	1422	n = th_strlen(z);
1415	1423	}
1416	1424	zRes = Th_Malloc(interp, n+1);
1417		- memcpy(zRes, z, n);
	1425	+ th_memcpy(zRes, z, n);
1418	1426	zRes[n] = '\0';
1419	1427	return zRes;
1420	1428	}
1421	1429
1422	1430	/*
		@@ -1472,11 +1480,11 @@
1472	1480	}
1473	1481
1474	1482	if( z && n>0 ){
1475	1483	char *zResult;
1476	1484	zResult = Th_Malloc(pInterp, n+1);
1477		- memcpy(zResult, z, n);
	1485	+ th_memcpy(zResult, z, n);
1478	1486	zResult[n] = '\0';
1479	1487	pInterp->zResult = zResult;
1480	1488	pInterp->nResult = n;
1481	1489	}
1482	1490
		@@ -1775,12 +1783,12 @@
1775	1783	nElem = th_strlen(zElem);
1776	1784	}
1777	1785
1778	1786	nNew = *pnStr + nElem;
1779	1787	zNew = Th_Malloc(interp, nNew);
1780		- memcpy(zNew, pzStr, pnStr);
1781		- memcpy(&zNew[*pnStr], zElem, nElem);
	1788	+ th_memcpy(zNew, pzStr, pnStr);
	1789	+ th_memcpy(&zNew[*pnStr], zElem, nElem);
1782	1790
1783	1791	Th_Free(interp, *pzStr);
1784	1792	*pzStr = zNew;
1785	1793	*pnStr = nNew;
1786	1794
		@@ -2335,18 +2343,18 @@
2335	2343	if( pNew->pOp \|\| pNew->nValue ){
2336	2344	if( pNew->nValue ){
2337	2345	/* A terminal. Copy the string value. */
2338	2346	assert( !pNew->pOp );
2339	2347	pNew->zValue = Th_Malloc(interp, pNew->nValue);
2340		- memcpy(pNew->zValue, z, pNew->nValue);
	2348	+ th_memcpy(pNew->zValue, z, pNew->nValue);
2341	2349	i += pNew->nValue;
2342	2350	}
2343	2351	if( (nToken%16)==0 ){
2344	2352	/* Grow the apToken array. */
2345	2353	Expr **apTokenOld = apToken;
2346	2354	apToken = Th_Malloc(interp, sizeof(Expr )(nToken+16));
2347		- memcpy(apToken, apTokenOld, sizeof(Expr )nToken);
	2355	+ th_memcpy(apToken, apTokenOld, sizeof(Expr )nToken);
2348	2356	}
2349	2357
2350	2358	/* Put the new token at the end of the apToken array */
2351	2359	apToken[nToken] = pNew;
2352	2360	nToken++;
		@@ -2513,11 +2521,11 @@
2513	2521
2514	2522	if( op>0 && !pRet ){
2515	2523	pRet = (Th_HashEntry *)Th_Malloc(interp, sizeof(Th_HashEntry) + nKey);
2516	2524	pRet->zKey = (char *)&pRet[1];
2517	2525	pRet->nKey = nKey;
2518		- memcpy(pRet->zKey, zKey, nKey);
	2526	+ th_memcpy(pRet->zKey, zKey, nKey);
2519	2527	pRet->pNext = pHash->a[iKey];
2520	2528	pHash->a[iKey] = pRet;
2521	2529	}
2522	2530
2523	2531	return pRet;
2524	2532

	--- src/th.c
	+++ src/th.c
	@@ -202,10 +202,18 @@
202	};
203	typedef struct Buffer Buffer;
204	static int thBufferWrite(Th_Interp interp, Buffer , const char *, int);
205	static void thBufferInit(Buffer *);
206	static void thBufferFree(Th_Interp interp, Buffer );








207
208	/*
209	** Append nAdd bytes of content copied from zAdd to the end of buffer
210	** pBuffer. If there is not enough space currently allocated, resize
211	** the allocation to make space.
	@@ -227,17 +235,17 @@
227	char *zNew;
228	int nNew;
229
230	nNew = nReq*2;
231	zNew = (char *)Th_Malloc(interp, nNew);
232	memcpy(zNew, pBuffer->zBuf, pBuffer->nBuf);
233	Th_Free(interp, pBuffer->zBuf);
234	pBuffer->nBufAlloc = nNew;
235	pBuffer->zBuf = zNew;
236	}
237
238	memcpy(&pBuffer->zBuf[pBuffer->nBuf], zAdd, nAdd);
239	pBuffer->nBuf += nAdd;
240	pBuffer->zBuf[pBuffer->nBuf] = '\0';
241
242	return TH_OK;
243	}
	@@ -841,12 +849,12 @@
841	sizeof(int) * nCount + /* anElem */
842	strbuf.nBuf /* space for list element strings */
843	);
844	anElem = (int *)&azElem[nCount];
845	zElem = (char *)&anElem[nCount];
846	memcpy(anElem, lenbuf.zBuf, lenbuf.nBuf);
847	memcpy(zElem, strbuf.zBuf, strbuf.nBuf);
848	for(i=0; i<nCount;i++){
849	azElem[i] = zElem;
850	zElem += (anElem[i] + 1);
851	}
852	*pazElem = azElem;
	@@ -1293,11 +1301,11 @@
1293	}
1294
1295	assert(zValue \|\| nValue==0);
1296	pValue->zData = Th_Malloc(interp, nValue+1);
1297	pValue->zData[nValue] = '\0';
1298	memcpy(pValue->zData, zValue, nValue);
1299	pValue->nData = nValue;
1300
1301	return TH_OK;
1302	}
1303
	@@ -1412,11 +1420,11 @@
1412	char *zRes;
1413	if( n<0 ){
1414	n = th_strlen(z);
1415	}
1416	zRes = Th_Malloc(interp, n+1);
1417	memcpy(zRes, z, n);
1418	zRes[n] = '\0';
1419	return zRes;
1420	}
1421
1422	/*
	@@ -1472,11 +1480,11 @@
1472	}
1473
1474	if( z && n>0 ){
1475	char *zResult;
1476	zResult = Th_Malloc(pInterp, n+1);
1477	memcpy(zResult, z, n);
1478	zResult[n] = '\0';
1479	pInterp->zResult = zResult;
1480	pInterp->nResult = n;
1481	}
1482
	@@ -1775,12 +1783,12 @@
1775	nElem = th_strlen(zElem);
1776	}
1777
1778	nNew = *pnStr + nElem;
1779	zNew = Th_Malloc(interp, nNew);
1780	memcpy(zNew, pzStr, pnStr);
1781	memcpy(&zNew[*pnStr], zElem, nElem);
1782
1783	Th_Free(interp, *pzStr);
1784	*pzStr = zNew;
1785	*pnStr = nNew;
1786
	@@ -2335,18 +2343,18 @@
2335	if( pNew->pOp \|\| pNew->nValue ){
2336	if( pNew->nValue ){
2337	/* A terminal. Copy the string value. */
2338	assert( !pNew->pOp );
2339	pNew->zValue = Th_Malloc(interp, pNew->nValue);
2340	memcpy(pNew->zValue, z, pNew->nValue);
2341	i += pNew->nValue;
2342	}
2343	if( (nToken%16)==0 ){
2344	/* Grow the apToken array. */
2345	Expr **apTokenOld = apToken;
2346	apToken = Th_Malloc(interp, sizeof(Expr )(nToken+16));
2347	memcpy(apToken, apTokenOld, sizeof(Expr )nToken);
2348	}
2349
2350	/* Put the new token at the end of the apToken array */
2351	apToken[nToken] = pNew;
2352	nToken++;
	@@ -2513,11 +2521,11 @@
2513
2514	if( op>0 && !pRet ){
2515	pRet = (Th_HashEntry *)Th_Malloc(interp, sizeof(Th_HashEntry) + nKey);
2516	pRet->zKey = (char *)&pRet[1];
2517	pRet->nKey = nKey;
2518	memcpy(pRet->zKey, zKey, nKey);
2519	pRet->pNext = pHash->a[iKey];
2520	pHash->a[iKey] = pRet;
2521	}
2522
2523	return pRet;
2524

	--- src/th.c
	+++ src/th.c
	@@ -202,10 +202,18 @@
202	};
203	typedef struct Buffer Buffer;
204	static int thBufferWrite(Th_Interp interp, Buffer , const char *, int);
205	static void thBufferInit(Buffer *);
206	static void thBufferFree(Th_Interp interp, Buffer );
207
208	/*
209	** This version of memcpy() allows the first are second argument to
210	** be NULL as long as the number of bytes to copy is zero.
211	*/
212	static void th_memcpy(void dest, const void *src, size_t n){
213	return n>0 ? memcpy(dest,src,n) : dest;
214	}
215
216	/*
217	** Append nAdd bytes of content copied from zAdd to the end of buffer
218	** pBuffer. If there is not enough space currently allocated, resize
219	** the allocation to make space.
	@@ -227,17 +235,17 @@
235	char *zNew;
236	int nNew;
237
238	nNew = nReq*2;
239	zNew = (char *)Th_Malloc(interp, nNew);
240	th_memcpy(zNew, pBuffer->zBuf, pBuffer->nBuf);
241	Th_Free(interp, pBuffer->zBuf);
242	pBuffer->nBufAlloc = nNew;
243	pBuffer->zBuf = zNew;
244	}
245
246	th_memcpy(&pBuffer->zBuf[pBuffer->nBuf], zAdd, nAdd);
247	pBuffer->nBuf += nAdd;
248	pBuffer->zBuf[pBuffer->nBuf] = '\0';
249
250	return TH_OK;
251	}
	@@ -841,12 +849,12 @@
849	sizeof(int) * nCount + /* anElem */
850	strbuf.nBuf /* space for list element strings */
851	);
852	anElem = (int *)&azElem[nCount];
853	zElem = (char *)&anElem[nCount];
854	th_memcpy(anElem, lenbuf.zBuf, lenbuf.nBuf);
855	th_memcpy(zElem, strbuf.zBuf, strbuf.nBuf);
856	for(i=0; i<nCount;i++){
857	azElem[i] = zElem;
858	zElem += (anElem[i] + 1);
859	}
860	*pazElem = azElem;
	@@ -1293,11 +1301,11 @@
1301	}
1302
1303	assert(zValue \|\| nValue==0);
1304	pValue->zData = Th_Malloc(interp, nValue+1);
1305	pValue->zData[nValue] = '\0';
1306	th_memcpy(pValue->zData, zValue, nValue);
1307	pValue->nData = nValue;
1308
1309	return TH_OK;
1310	}
1311
	@@ -1412,11 +1420,11 @@
1420	char *zRes;
1421	if( n<0 ){
1422	n = th_strlen(z);
1423	}
1424	zRes = Th_Malloc(interp, n+1);
1425	th_memcpy(zRes, z, n);
1426	zRes[n] = '\0';
1427	return zRes;
1428	}
1429
1430	/*
	@@ -1472,11 +1480,11 @@
1480	}
1481
1482	if( z && n>0 ){
1483	char *zResult;
1484	zResult = Th_Malloc(pInterp, n+1);
1485	th_memcpy(zResult, z, n);
1486	zResult[n] = '\0';
1487	pInterp->zResult = zResult;
1488	pInterp->nResult = n;
1489	}
1490
	@@ -1775,12 +1783,12 @@
1783	nElem = th_strlen(zElem);
1784	}
1785
1786	nNew = *pnStr + nElem;
1787	zNew = Th_Malloc(interp, nNew);
1788	th_memcpy(zNew, pzStr, pnStr);
1789	th_memcpy(&zNew[*pnStr], zElem, nElem);
1790
1791	Th_Free(interp, *pzStr);
1792	*pzStr = zNew;
1793	*pnStr = nNew;
1794
	@@ -2335,18 +2343,18 @@
2343	if( pNew->pOp \|\| pNew->nValue ){
2344	if( pNew->nValue ){
2345	/* A terminal. Copy the string value. */
2346	assert( !pNew->pOp );
2347	pNew->zValue = Th_Malloc(interp, pNew->nValue);
2348	th_memcpy(pNew->zValue, z, pNew->nValue);
2349	i += pNew->nValue;
2350	}
2351	if( (nToken%16)==0 ){
2352	/* Grow the apToken array. */
2353	Expr **apTokenOld = apToken;
2354	apToken = Th_Malloc(interp, sizeof(Expr )(nToken+16));
2355	th_memcpy(apToken, apTokenOld, sizeof(Expr )nToken);
2356	}
2357
2358	/* Put the new token at the end of the apToken array */
2359	apToken[nToken] = pNew;
2360	nToken++;
	@@ -2513,11 +2521,11 @@
2521
2522	if( op>0 && !pRet ){
2523	pRet = (Th_HashEntry *)Th_Malloc(interp, sizeof(Th_HashEntry) + nKey);
2524	pRet->zKey = (char *)&pRet[1];
2525	pRet->nKey = nKey;
2526	th_memcpy(pRet->zKey, zKey, nKey);
2527	pRet->pNext = pHash->a[iKey];
2528	pHash->a[iKey] = pRet;
2529	}
2530
2531	return pRet;
2532

M src/wikiformat.c

+107 -8

		--- src/wikiformat.c
		+++ src/wikiformat.c
		@@ -2014,16 +2014,13 @@
2014	2014	}
2015	2015	free(renderer.aStack);
2016	2016	}
2017	2017
2018	2018	/*
2019		-** Get the next HTML token.
2020		-**
2021		-** z points to the start of a token. Return the number of
2022		-** characters in that token.
	2019	+** Return the length, in bytes, of the HTML token that z is pointing to.
2023	2020	*/
2024		-static int nextHtmlToken(const char *z){
	2021	+int html_token_length(const char *z){
2025	2022	int n;
2026	2023	char c;
2027	2024	if( (c=z[0])=='<' ){
2028	2025	n = htmlTagLength(z);
2029	2026	if( n<=0 ) n = 1;
		@@ -2040,10 +2037,112 @@
2040	2037	if( c=='<' \|\| c=='&' \|\| fossil_isspace(c) \|\| c==0 ) break;
2041	2038	}
2042	2039	}
2043	2040	return n;
2044	2041	}
	2042	+
	2043	+/*
	2044	+** z points to someplace in the middle of HTML markup. Return the length
	2045	+** of the subtoken that starts on z.
	2046	+*/
	2047	+int html_subtoken_length(const char *z){
	2048	+ int n;
	2049	+ char c;
	2050	+ c = z[0];
	2051	+ if( fossil_isspace(c) ){
	2052	+ for(n=1; z[n] && fossil_isspace(z[n]); n++){}
	2053	+ return n;
	2054	+ }
	2055	+ if( c=='"' \|\| c=='\'' ){
	2056	+ for(n=1; z[n] && z[n]!=c && z[n]!='>'; n++){}
	2057	+ if( z[n]==c ) n++;
	2058	+ return n;
	2059	+ }
	2060	+ if( c=='>' ){
	2061	+ return 0;
	2062	+ }
	2063	+ if( c=='=' ){
	2064	+ return 1;
	2065	+ }
	2066	+ if( fossil_isalnum(c) \|\| c=='/' ){
	2067	+ for(n=1; (c=z[n])!=0 && (fossil_isalnum(c) \|\| c=='-' \|\| c=='_'); n++){}
	2068	+ return n;
	2069	+ }
	2070	+ return 1;
	2071	+}
	2072	+
	2073	+/*
	2074	+** z points to an HTML markup token: <TAG ATTR=VALUE ...>
	2075	+** This routine looks for the VALUE associated with zAttr and returns
	2076	+** a pointer to the start of that value and sets *pLen to be the length
	2077	+** in bytes for the value. Or it returns NULL if no such attr exists.
	2078	+*/
	2079	+const char html_attribute(const char zMarkup, const char zAttr, int pLen){
	2080	+ int i = 1;
	2081	+ int n;
	2082	+ int nAttr;
	2083	+ int iMatchCnt = 0;
	2084	+ assert( zMarkup[0]=='<' );
	2085	+ assert( zMarkup[1]!=0 );
	2086	+ n = html_subtoken_length(zMarkup+i);
	2087	+ if( n==0 ) return 0;
	2088	+ i += n;
	2089	+ nAttr = (int)strlen(zAttr);
	2090	+ while( 1 ){
	2091	+ const char *zStart = zMarkup+i;
	2092	+ n = html_subtoken_length(zStart);
	2093	+ if( n==0 ) break;
	2094	+ i += n;
	2095	+ if( fossil_isspace(zStart[0]) ) continue;
	2096	+ if( n==nAttr && fossil_strnicmp(zAttr,zStart,nAttr)==0 ){
	2097	+ iMatchCnt = 1;
	2098	+ }else if( n==1 && zStart[0]=='=' && iMatchCnt==1 ){
	2099	+ iMatchCnt = 2;
	2100	+ }else if( iMatchCnt==2 ){
	2101	+ if( (zStart[0]=='"' \|\| zStart[0]=='\'') && zStart[n-1]==zStart[0] ){
	2102	+ zStart++;
	2103	+ n -= 2;
	2104	+ }
	2105	+ *pLen = n;
	2106	+ return zStart;
	2107	+ }else{
	2108	+ iMatchCnt = 0;
	2109	+ }
	2110	+ }
	2111	+ return 0;
	2112	+}
	2113	+
	2114	+/*
	2115	+** COMMAND: test-html-tokenize
	2116	+**
	2117	+** Tokenize an HTML file. Return the offset and length and text of
	2118	+** each token - one token per line. Omit white-space tokens.
	2119	+*/
	2120	+void test_html_tokenize(void){
	2121	+ Blob in;
	2122	+ char *z;
	2123	+ int i;
	2124	+ int iOfst, n;
	2125	+
	2126	+ for(i=2; i<g.argc; i++){
	2127	+ blob_read_from_file(&in, g.argv[i], ExtFILE);
	2128	+ z = blob_str(&in);
	2129	+ for(iOfst=0; z[iOfst]; iOfst+=n){
	2130	+ n = html_token_length(z+iOfst);
	2131	+ if( fossil_isspace(z[iOfst]) ) continue;
	2132	+ fossil_print("%d %d %.*s\n", iOfst, n, n, z+iOfst);
	2133	+ if( z[iOfst]=='<' && n>1 ){
	2134	+ int j,k;
	2135	+ for(j=iOfst+1; (k = html_subtoken_length(z+j))>0; j+=k){
	2136	+ if( fossil_isspace(z[j]) \|\| z[j]=='=' ) continue;
	2137	+ fossil_print("# %d %d %.*s\n", j, k, k, z+j);
	2138	+ }
	2139	+ }
	2140	+ }
	2141	+ blob_reset(&in);
	2142	+ }
	2143	+}
2045	2144
2046	2145	/*
2047	2146	** Attempt to reformat messy HTML to be easily readable by humans.
2048	2147	**
2049	2148	** * Try to keep lines less than 80 characters in length
		@@ -2062,11 +2161,11 @@
2062	2161	int nPre = 0;
2063	2162	int iCur = 0;
2064	2163	int wantSpace = 0;
2065	2164	int omitSpace = 1;
2066	2165	while( zIn[0] ){
2067		- n = nextHtmlToken(zIn);
	2166	+ n = html_token_length(zIn);
2068	2167	if( zIn[0]=='<' && n>1 ){
2069	2168	int i, j;
2070	2169	int isCloseTag;
2071	2170	int eTag;
2072	2171	int eType;
		@@ -2181,11 +2280,11 @@
2181	2280	int seenText = 0; /* True after first non-whitespace seen */
2182	2281	int nNL = 0; /* Number of \n characters at the end of pOut */
2183	2282	int nWS = 0; /* True if pOut ends with whitespace */
2184	2283	while( fossil_isspace(zIn[0]) ) zIn++;
2185	2284	while( zIn[0] ){
2186		- n = nextHtmlToken(zIn);
	2285	+ n = html_token_length(zIn);
2187	2286	if( zIn[0]=='<' && n>1 ){
2188	2287	int isCloseTag;
2189	2288	int eTag;
2190	2289	int eType;
2191	2290	char zTag[32];
		@@ -2197,11 +2296,11 @@
2197	2296	eTag = findTag(zTag);
2198	2297	eType = aMarkup[eTag].iType;
2199	2298	if( eTag==MARKUP_INVALID && fossil_strnicmp(zIn,"<style",6)==0 ){
2200	2299	zIn += n;
2201	2300	while( zIn[0] ){
2202		- n = nextHtmlToken(zIn);
	2301	+ n = html_token_length(zIn);
2203	2302	if( fossil_strnicmp(zIn, "</style",7)==0 ) break;
2204	2303	zIn += n;
2205	2304	}
2206	2305	if( zIn[0]=='<' ) zIn += n;
2207	2306	continue;
2208	2307

	--- src/wikiformat.c
	+++ src/wikiformat.c
	@@ -2014,16 +2014,13 @@
2014	}
2015	free(renderer.aStack);
2016	}
2017
2018	/*
2019	** Get the next HTML token.
2020	**
2021	** z points to the start of a token. Return the number of
2022	** characters in that token.
2023	*/
2024	static int nextHtmlToken(const char *z){
2025	int n;
2026	char c;
2027	if( (c=z[0])=='<' ){
2028	n = htmlTagLength(z);
2029	if( n<=0 ) n = 1;
	@@ -2040,10 +2037,112 @@
2040	if( c=='<' \|\| c=='&' \|\| fossil_isspace(c) \|\| c==0 ) break;
2041	}
2042	}
2043	return n;
2044	}






































































































2045
2046	/*
2047	** Attempt to reformat messy HTML to be easily readable by humans.
2048	**
2049	** * Try to keep lines less than 80 characters in length
	@@ -2062,11 +2161,11 @@
2062	int nPre = 0;
2063	int iCur = 0;
2064	int wantSpace = 0;
2065	int omitSpace = 1;
2066	while( zIn[0] ){
2067	n = nextHtmlToken(zIn);
2068	if( zIn[0]=='<' && n>1 ){
2069	int i, j;
2070	int isCloseTag;
2071	int eTag;
2072	int eType;
	@@ -2181,11 +2280,11 @@
2181	int seenText = 0; /* True after first non-whitespace seen */
2182	int nNL = 0; /* Number of \n characters at the end of pOut */
2183	int nWS = 0; /* True if pOut ends with whitespace */
2184	while( fossil_isspace(zIn[0]) ) zIn++;
2185	while( zIn[0] ){
2186	n = nextHtmlToken(zIn);
2187	if( zIn[0]=='<' && n>1 ){
2188	int isCloseTag;
2189	int eTag;
2190	int eType;
2191	char zTag[32];
	@@ -2197,11 +2296,11 @@
2197	eTag = findTag(zTag);
2198	eType = aMarkup[eTag].iType;
2199	if( eTag==MARKUP_INVALID && fossil_strnicmp(zIn,"<style",6)==0 ){
2200	zIn += n;
2201	while( zIn[0] ){
2202	n = nextHtmlToken(zIn);
2203	if( fossil_strnicmp(zIn, "</style",7)==0 ) break;
2204	zIn += n;
2205	}
2206	if( zIn[0]=='<' ) zIn += n;
2207	continue;
2208

	--- src/wikiformat.c
	+++ src/wikiformat.c
	@@ -2014,16 +2014,13 @@
2014	}
2015	free(renderer.aStack);
2016	}
2017
2018	/*
2019	** Return the length, in bytes, of the HTML token that z is pointing to.



2020	*/
2021	int html_token_length(const char *z){
2022	int n;
2023	char c;
2024	if( (c=z[0])=='<' ){
2025	n = htmlTagLength(z);
2026	if( n<=0 ) n = 1;
	@@ -2040,10 +2037,112 @@
2037	if( c=='<' \|\| c=='&' \|\| fossil_isspace(c) \|\| c==0 ) break;
2038	}
2039	}
2040	return n;
2041	}
2042
2043	/*
2044	** z points to someplace in the middle of HTML markup. Return the length
2045	** of the subtoken that starts on z.
2046	*/
2047	int html_subtoken_length(const char *z){
2048	int n;
2049	char c;
2050	c = z[0];
2051	if( fossil_isspace(c) ){
2052	for(n=1; z[n] && fossil_isspace(z[n]); n++){}
2053	return n;
2054	}
2055	if( c=='"' \|\| c=='\'' ){
2056	for(n=1; z[n] && z[n]!=c && z[n]!='>'; n++){}
2057	if( z[n]==c ) n++;
2058	return n;
2059	}
2060	if( c=='>' ){
2061	return 0;
2062	}
2063	if( c=='=' ){
2064	return 1;
2065	}
2066	if( fossil_isalnum(c) \|\| c=='/' ){
2067	for(n=1; (c=z[n])!=0 && (fossil_isalnum(c) \|\| c=='-' \|\| c=='_'); n++){}
2068	return n;
2069	}
2070	return 1;
2071	}
2072
2073	/*
2074	** z points to an HTML markup token: <TAG ATTR=VALUE ...>
2075	** This routine looks for the VALUE associated with zAttr and returns
2076	** a pointer to the start of that value and sets *pLen to be the length
2077	** in bytes for the value. Or it returns NULL if no such attr exists.
2078	*/
2079	const char html_attribute(const char zMarkup, const char zAttr, int pLen){
2080	int i = 1;
2081	int n;
2082	int nAttr;
2083	int iMatchCnt = 0;
2084	assert( zMarkup[0]=='<' );
2085	assert( zMarkup[1]!=0 );
2086	n = html_subtoken_length(zMarkup+i);
2087	if( n==0 ) return 0;
2088	i += n;
2089	nAttr = (int)strlen(zAttr);
2090	while( 1 ){
2091	const char *zStart = zMarkup+i;
2092	n = html_subtoken_length(zStart);
2093	if( n==0 ) break;
2094	i += n;
2095	if( fossil_isspace(zStart[0]) ) continue;
2096	if( n==nAttr && fossil_strnicmp(zAttr,zStart,nAttr)==0 ){
2097	iMatchCnt = 1;
2098	}else if( n==1 && zStart[0]=='=' && iMatchCnt==1 ){
2099	iMatchCnt = 2;
2100	}else if( iMatchCnt==2 ){
2101	if( (zStart[0]=='"' \|\| zStart[0]=='\'') && zStart[n-1]==zStart[0] ){
2102	zStart++;
2103	n -= 2;
2104	}
2105	*pLen = n;
2106	return zStart;
2107	}else{
2108	iMatchCnt = 0;
2109	}
2110	}
2111	return 0;
2112	}
2113
2114	/*
2115	** COMMAND: test-html-tokenize
2116	**
2117	** Tokenize an HTML file. Return the offset and length and text of
2118	** each token - one token per line. Omit white-space tokens.
2119	*/
2120	void test_html_tokenize(void){
2121	Blob in;
2122	char *z;
2123	int i;
2124	int iOfst, n;
2125
2126	for(i=2; i<g.argc; i++){
2127	blob_read_from_file(&in, g.argv[i], ExtFILE);
2128	z = blob_str(&in);
2129	for(iOfst=0; z[iOfst]; iOfst+=n){
2130	n = html_token_length(z+iOfst);
2131	if( fossil_isspace(z[iOfst]) ) continue;
2132	fossil_print("%d %d %.*s\n", iOfst, n, n, z+iOfst);
2133	if( z[iOfst]=='<' && n>1 ){
2134	int j,k;
2135	for(j=iOfst+1; (k = html_subtoken_length(z+j))>0; j+=k){
2136	if( fossil_isspace(z[j]) \|\| z[j]=='=' ) continue;
2137	fossil_print("# %d %d %.*s\n", j, k, k, z+j);
2138	}
2139	}
2140	}
2141	blob_reset(&in);
2142	}
2143	}
2144
2145	/*
2146	** Attempt to reformat messy HTML to be easily readable by humans.
2147	**
2148	** * Try to keep lines less than 80 characters in length
	@@ -2062,11 +2161,11 @@
2161	int nPre = 0;
2162	int iCur = 0;
2163	int wantSpace = 0;
2164	int omitSpace = 1;
2165	while( zIn[0] ){
2166	n = html_token_length(zIn);
2167	if( zIn[0]=='<' && n>1 ){
2168	int i, j;
2169	int isCloseTag;
2170	int eTag;
2171	int eType;
	@@ -2181,11 +2280,11 @@
2280	int seenText = 0; /* True after first non-whitespace seen */
2281	int nNL = 0; /* Number of \n characters at the end of pOut */
2282	int nWS = 0; /* True if pOut ends with whitespace */
2283	while( fossil_isspace(zIn[0]) ) zIn++;
2284	while( zIn[0] ){
2285	n = html_token_length(zIn);
2286	if( zIn[0]=='<' && n>1 ){
2287	int isCloseTag;
2288	int eTag;
2289	int eType;
2290	char zTag[32];
	@@ -2197,11 +2296,11 @@
2296	eTag = findTag(zTag);
2297	eType = aMarkup[eTag].iType;
2298	if( eTag==MARKUP_INVALID && fossil_strnicmp(zIn,"<style",6)==0 ){
2299	zIn += n;
2300	while( zIn[0] ){
2301	n = html_token_length(zIn);
2302	if( fossil_strnicmp(zIn, "</style",7)==0 ) break;
2303	zIn += n;
2304	}
2305	if( zIn[0]=='<' ) zIn += n;
2306	continue;
2307

M www/aboutcgi.wiki

+13 -1

		--- www/aboutcgi.wiki
		+++ www/aboutcgi.wiki
		@@ -2,11 +2,11 @@
2	2	<h2>Introduction</h2><blockquote>
3	3	<p>CGI or "Common Gateway Interface" is a venerable yet reliable technique for
4	4	generating dynamic web content. This article gives a quick background on how
5	5	CGI works and describes how Fossil can act as a CGI service.
6	6	<p>This is a "how it works" guide. If you just want to set up Fossil
7		-as a CGI server, see the [./server.wiki \| Fossil Server Setup] page.
	7	+as a CGI server, see the [./server/ \| Fossil Server Setup] page.
8	8	</blockquote>
9	9	<h2>A Quick Review Of CGI</h2><blockquote>
10	10	<p>
11	11	An HTTP request is a block of text that is sent by a client application
12	12	(usually a web browser) and arrives at the web server over a network
		@@ -180,10 +180,18 @@
180	180	a repository. The PATH_INFO is shortened by removing
181	181	"subdir/three/" leaving it at just "timeline".
182	182	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
183	183	requested is "timeline".
184	184	</ol>
	185	+</blockquote>
	186	+<h2>Additional CGI Script Options</h2>
	187	+<blockquote>
	188	+<p>
	189	+The CGI script can have additional options used to fine-tune
	190	+Fossil's behavior. See the [./cgi.wiki\|CGI script documentation]
	191	+for details.
	192	+</p>
185	193	</blockquote>
186	194	<h2>Additional Observations</h2>
187	195	<blockquote><ol type="I">
188	196	<li><p>
189	197	Fossil does not distinguish between the various HTTP methods (GET, PUT,
		@@ -208,7 +216,11 @@
208	216	<p>
209	217	SCGI is processed using the same built-in web server, just modified
210	218	to parse SCGI requests instead of HTTP requests. Each SCGI request is
211	219	converted into CGI, then Fossil creates a separate child Fossil
212	220	process to handle each CGI request.
	221	+<li><p>
	222	+Fossil is itself often launched using CGI. But Fossil can also then
	223	+turn around and launch [./serverext.wiki\|sub-CGI scripts to implement
	224	+extensions].
213	225	</ol>
214	226	</blockquote>
215	227

	--- www/aboutcgi.wiki
	+++ www/aboutcgi.wiki
	@@ -2,11 +2,11 @@
2	<h2>Introduction</h2><blockquote>
3	<p>CGI or "Common Gateway Interface" is a venerable yet reliable technique for
4	generating dynamic web content. This article gives a quick background on how
5	CGI works and describes how Fossil can act as a CGI service.
6	<p>This is a "how it works" guide. If you just want to set up Fossil
7	as a CGI server, see the [./server.wiki \| Fossil Server Setup] page.
8	</blockquote>
9	<h2>A Quick Review Of CGI</h2><blockquote>
10	<p>
11	An HTTP request is a block of text that is sent by a client application
12	(usually a web browser) and arrives at the web server over a network
	@@ -180,10 +180,18 @@
180	a repository. The PATH_INFO is shortened by removing
181	"subdir/three/" leaving it at just "timeline".
182	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
183	requested is "timeline".
184	</ol>








185	</blockquote>
186	<h2>Additional Observations</h2>
187	<blockquote><ol type="I">
188	<li><p>
189	Fossil does not distinguish between the various HTTP methods (GET, PUT,
	@@ -208,7 +216,11 @@
208	<p>
209	SCGI is processed using the same built-in web server, just modified
210	to parse SCGI requests instead of HTTP requests. Each SCGI request is
211	converted into CGI, then Fossil creates a separate child Fossil
212	process to handle each CGI request.




213	</ol>
214	</blockquote>
215

	--- www/aboutcgi.wiki
	+++ www/aboutcgi.wiki
	@@ -2,11 +2,11 @@
2	<h2>Introduction</h2><blockquote>
3	<p>CGI or "Common Gateway Interface" is a venerable yet reliable technique for
4	generating dynamic web content. This article gives a quick background on how
5	CGI works and describes how Fossil can act as a CGI service.
6	<p>This is a "how it works" guide. If you just want to set up Fossil
7	as a CGI server, see the [./server/ \| Fossil Server Setup] page.
8	</blockquote>
9	<h2>A Quick Review Of CGI</h2><blockquote>
10	<p>
11	An HTTP request is a block of text that is sent by a client application
12	(usually a web browser) and arrives at the web server over a network
	@@ -180,10 +180,18 @@
180	a repository. The PATH_INFO is shortened by removing
181	"subdir/three/" leaving it at just "timeline".
182	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
183	requested is "timeline".
184	</ol>
185	</blockquote>
186	<h2>Additional CGI Script Options</h2>
187	<blockquote>
188	<p>
189	The CGI script can have additional options used to fine-tune
190	Fossil's behavior. See the [./cgi.wiki\|CGI script documentation]
191	for details.
192	</p>
193	</blockquote>
194	<h2>Additional Observations</h2>
195	<blockquote><ol type="I">
196	<li><p>
197	Fossil does not distinguish between the various HTTP methods (GET, PUT,
	@@ -208,7 +216,11 @@
216	<p>
217	SCGI is processed using the same built-in web server, just modified
218	to parse SCGI requests instead of HTTP requests. Each SCGI request is
219	converted into CGI, then Fossil creates a separate child Fossil
220	process to handle each CGI request.
221	<li><p>
222	Fossil is itself often launched using CGI. But Fossil can also then
223	turn around and launch [./serverext.wiki\|sub-CGI scripts to implement
224	extensions].
225	</ol>
226	</blockquote>
227

M www/aboutdownload.wiki

+1 -1

		--- www/aboutdownload.wiki
		+++ www/aboutdownload.wiki
		@@ -51,11 +51,11 @@
51	51	With each new release, the "releases" variable in the javascript on
52	52	the [/uv/download.js?mimetype=text/plain\|download.js] page is
53	53	edited (using "[/help?cmd=uv\|fossil uv edit download.js]") to add
54	54	details of the release.
55	55
56		-When the javascript in the "download.js" file runs, it requests
	56	+When the JavaScript in the "download.js" file runs, it requests
57	57	a listing of all unversioned content using the /juvlist URL.
58	58	([/juvlist\|sample /juvlist output]). The content of the download page is
59	59	constructed by matching unversioned files against regular expressions
60	60	in the "releases" variable.
61	61
62	62

	--- www/aboutdownload.wiki
	+++ www/aboutdownload.wiki
	@@ -51,11 +51,11 @@
51	With each new release, the "releases" variable in the javascript on
52	the [/uv/download.js?mimetype=text/plain\|download.js] page is
53	edited (using "[/help?cmd=uv\|fossil uv edit download.js]") to add
54	details of the release.
55
56	When the javascript in the "download.js" file runs, it requests
57	a listing of all unversioned content using the /juvlist URL.
58	([/juvlist\|sample /juvlist output]). The content of the download page is
59	constructed by matching unversioned files against regular expressions
60	in the "releases" variable.
61
62

	--- www/aboutdownload.wiki
	+++ www/aboutdownload.wiki
	@@ -51,11 +51,11 @@
51	With each new release, the "releases" variable in the javascript on
52	the [/uv/download.js?mimetype=text/plain\|download.js] page is
53	edited (using "[/help?cmd=uv\|fossil uv edit download.js]") to add
54	details of the release.
55
56	When the JavaScript in the "download.js" file runs, it requests
57	a listing of all unversioned content using the /juvlist URL.
58	([/juvlist\|sample /juvlist output]). The content of the download page is
59	constructed by matching unversioned files against regular expressions
60	in the "releases" variable.
61
62

M www/alerts.md

+2 -2

		--- www/alerts.md
		+++ www/alerts.md
		@@ -12,11 +12,11 @@
12	12	* Announcements
13	13
14	14	Subscribers can elect to receive emails as soon as these events happen,
15	15	or they can receive a daily digest of the events instead.
16	16
17		-Email alerts are sent by a [Fossil server](./server.wiki), which must be
	17	+Email alerts are sent by a [Fossil server](./server/), which must be
18	18	[set up](#quick) by the Fossil administrator to send email.
19	19
20	20	Email alerts do not currently work if you are only using Fossil from the
21	21	command line.
22	22
		@@ -29,11 +29,11 @@
29	29	## Setup Prerequisites
30	30
31	31	Much of this document describes how to set up Fossil's email alert
32	32	system. To follow this guide, you will need a Fossil UI browser window
33	33	open to the [Admin → Notification](/setup_notification) Fossil UI screen
34		-on the the Fossil server that will be sending these email alerts, logged
	34	+on the Fossil server that will be sending these email alerts, logged
35	35	in as a user with Admin capability. It is not possible to work on a
36	36	clone of the server's repository and push the configuration changes up
37	37	to that repo as an Admin user, [on purpose](#backup).
38	38
39	39	Important: Do not confuse that screen with Admin → Email-Server,
40	40

	--- www/alerts.md
	+++ www/alerts.md
	@@ -12,11 +12,11 @@
12	* Announcements
13
14	Subscribers can elect to receive emails as soon as these events happen,
15	or they can receive a daily digest of the events instead.
16
17	Email alerts are sent by a [Fossil server](./server.wiki), which must be
18	[set up](#quick) by the Fossil administrator to send email.
19
20	Email alerts do not currently work if you are only using Fossil from the
21	command line.
22
	@@ -29,11 +29,11 @@
29	## Setup Prerequisites
30
31	Much of this document describes how to set up Fossil's email alert
32	system. To follow this guide, you will need a Fossil UI browser window
33	open to the [Admin → Notification](/setup_notification) Fossil UI screen
34	on the the Fossil server that will be sending these email alerts, logged
35	in as a user with Admin capability. It is not possible to work on a
36	clone of the server's repository and push the configuration changes up
37	to that repo as an Admin user, [on purpose](#backup).
38
39	Important: Do not confuse that screen with Admin → Email-Server,
40

	--- www/alerts.md
	+++ www/alerts.md
	@@ -12,11 +12,11 @@
12	* Announcements
13
14	Subscribers can elect to receive emails as soon as these events happen,
15	or they can receive a daily digest of the events instead.
16
17	Email alerts are sent by a [Fossil server](./server/), which must be
18	[set up](#quick) by the Fossil administrator to send email.
19
20	Email alerts do not currently work if you are only using Fossil from the
21	command line.
22
	@@ -29,11 +29,11 @@
29	## Setup Prerequisites
30
31	Much of this document describes how to set up Fossil's email alert
32	system. To follow this guide, you will need a Fossil UI browser window
33	open to the [Admin → Notification](/setup_notification) Fossil UI screen
34	on the Fossil server that will be sending these email alerts, logged
35	in as a user with Admin capability. It is not possible to work on a
36	clone of the server's repository and push the configuration changes up
37	to that repo as an Admin user, [on purpose](#backup).
38
39	Important: Do not confuse that screen with Admin → Email-Server,
40

M www/antibot.wiki

+14 -14

		--- www/antibot.wiki
		+++ www/antibot.wiki
		@@ -62,14 +62,14 @@
62	62
63	63	The first two UserAgent strings above identify Firefox 19 and
64	64	Internet Explorer 8.0, both running on Windows NT. The third
65	65	example is the spider used by Google to index the internet.
66	66	The fourth example is the "wget" utility running on OpenBSD.
67		-Thus the first two UserAgent strings above identify the requestor
68		-as human whereas the second two identify the requestor as a spider.
	67	+Thus the first two UserAgent strings above identify the requester
	68	+as human whereas the second two identify the requester as a spider.
69	69	Note that the UserAgent string is completely under the control
70		-of the requestor and so a malicious spider can forge a UserAgent
	70	+of the requester and so a malicious spider can forge a UserAgent
71	71	string that makes it look like a human. But most spiders truly
72	72	seem to desire to "play nicely" on the internet and are quite open
73	73	about the fact that they are a spider. And so the UserAgent string
74	74	provides a good first-guess about whether or not a request originates
75	75	from a human or a spider.
		@@ -82,26 +82,26 @@
82	82	gives humans easy access to the hyperlinks while preventing spiders
83	83	from walking the millions of pages on a typical Fossil site.
84	84
85	85	But the hyperlinks are not enabled directly with the setting above.
86	86	Instead, the HTML code that is generated contains anchor tags ("<a>")
87		-without "href=" attributes. Then, javascript code is added to the
	87	+without "href=" attributes. Then, JavaScript code is added to the
88	88	end of the page that goes back and fills in the "href=" attributes of
89	89	the anchor tags with the hyperlink targets, thus enabling the hyperlinks.
90		-This extra step of using javascript to enable the hyperlink targets
	90	+This extra step of using JavaScript to enable the hyperlink targets
91	91	is a security measure against spiders that forge a human-looking
92		-UserAgent string. Most spiders do not bother to run javascript and
	92	+UserAgent string. Most spiders do not bother to run JavaScript and
93	93	so to the spider the empty anchor tag will be useless. But all modern
94		-web browsers implement javascript, so hyperlinks will show up
	94	+web browsers implement JavaScript, so hyperlinks will show up
95	95	normally for human users.
96	96
97	97	<h2>Further defenses</h2>
98	98
99	99	Recently (as of this writing, in the spring of 2013) the Fossil server
100	100	on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101	101	by Chinese spiders that use forged UserAgent strings to make them look
102		-like normal web browsers and which interpret javascript. We do not
	102	+like normal web browsers and which interpret JavaScript. We do not
103	103	believe these attacks to be nefarious since SQLite is public domain
104	104	and the attackers could obtain all information they ever wanted to
105	105	know about SQLite simply by cloning the repository. Instead, we
106	106	believe these "attacks" are coming from "script kiddies". But regardless
107	107	of whether or not malice is involved, these attacks do present
		@@ -110,31 +110,31 @@
110	110	For this reason, additional defenses against
111	111	spiders have been put in place.
112	112
113	113	On the Admin/Access page of Fossil, just below the
114	114	"<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115		-setting, there are now two additional subsettings that can be optionally
	115	+setting, there are now two additional sub-settings that can be optionally
116	116	enabled to control hyperlinks.
117	117
118		-The first subsetting waits to run the
119		-javascript that sets the "href=" attributes on anchor tags until after
	118	+The first sub-setting waits to run the
	119	+JavaScript that sets the "href=" attributes on anchor tags until after
120	120	at least one "mouseover" event has been detected on the <body>
121	121	element of the page. The thinking here is that spiders will not be
122	122	simulating mouse motion and so no mouseover events will ever occur and
123	123	hence the hyperlinks will never become enabled for spiders.
124	124
125		-The second new subsetting is a delay (in milliseconds) before setting
	125	+The second new sub-setting is a delay (in milliseconds) before setting
126	126	the "href=" attributes on anchor tags. The default value for this
127	127	delay is 10 milliseconds. The idea here is that a spider will try to
128	128	render the page immediately, and will not wait for delayed scripts
129	129	to be run, thus will never enable the hyperlinks.
130	130
131		-These two subsettings can be used separately or together. If used together,
	131	+These two sub-settings can be used separately or together. If used together,
132	132	then the delay timer does not start until after the first mouse movement
133	133	is detected.
134	134
135		-See also [./server.wiki#loadmgmt\|Managing Server Load] for a description
	135	+See also [./loadmgmt.md\|Managing Server Load] for a description
136	136	of how expensive pages can be disabled when the server is under heavy
137	137	load.
138	138
139	139	<h2>The ongoing struggle</h2>
140	140
141	141

	--- www/antibot.wiki
	+++ www/antibot.wiki
	@@ -62,14 +62,14 @@
62
63	The first two UserAgent strings above identify Firefox 19 and
64	Internet Explorer 8.0, both running on Windows NT. The third
65	example is the spider used by Google to index the internet.
66	The fourth example is the "wget" utility running on OpenBSD.
67	Thus the first two UserAgent strings above identify the requestor
68	as human whereas the second two identify the requestor as a spider.
69	Note that the UserAgent string is completely under the control
70	of the requestor and so a malicious spider can forge a UserAgent
71	string that makes it look like a human. But most spiders truly
72	seem to desire to "play nicely" on the internet and are quite open
73	about the fact that they are a spider. And so the UserAgent string
74	provides a good first-guess about whether or not a request originates
75	from a human or a spider.
	@@ -82,26 +82,26 @@
82	gives humans easy access to the hyperlinks while preventing spiders
83	from walking the millions of pages on a typical Fossil site.
84
85	But the hyperlinks are not enabled directly with the setting above.
86	Instead, the HTML code that is generated contains anchor tags ("<a>")
87	without "href=" attributes. Then, javascript code is added to the
88	end of the page that goes back and fills in the "href=" attributes of
89	the anchor tags with the hyperlink targets, thus enabling the hyperlinks.
90	This extra step of using javascript to enable the hyperlink targets
91	is a security measure against spiders that forge a human-looking
92	UserAgent string. Most spiders do not bother to run javascript and
93	so to the spider the empty anchor tag will be useless. But all modern
94	web browsers implement javascript, so hyperlinks will show up
95	normally for human users.
96
97	<h2>Further defenses</h2>
98
99	Recently (as of this writing, in the spring of 2013) the Fossil server
100	on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101	by Chinese spiders that use forged UserAgent strings to make them look
102	like normal web browsers and which interpret javascript. We do not
103	believe these attacks to be nefarious since SQLite is public domain
104	and the attackers could obtain all information they ever wanted to
105	know about SQLite simply by cloning the repository. Instead, we
106	believe these "attacks" are coming from "script kiddies". But regardless
107	of whether or not malice is involved, these attacks do present
	@@ -110,31 +110,31 @@
110	For this reason, additional defenses against
111	spiders have been put in place.
112
113	On the Admin/Access page of Fossil, just below the
114	"<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115	setting, there are now two additional subsettings that can be optionally
116	enabled to control hyperlinks.
117
118	The first subsetting waits to run the
119	javascript that sets the "href=" attributes on anchor tags until after
120	at least one "mouseover" event has been detected on the <body>
121	element of the page. The thinking here is that spiders will not be
122	simulating mouse motion and so no mouseover events will ever occur and
123	hence the hyperlinks will never become enabled for spiders.
124
125	The second new subsetting is a delay (in milliseconds) before setting
126	the "href=" attributes on anchor tags. The default value for this
127	delay is 10 milliseconds. The idea here is that a spider will try to
128	render the page immediately, and will not wait for delayed scripts
129	to be run, thus will never enable the hyperlinks.
130
131	These two subsettings can be used separately or together. If used together,
132	then the delay timer does not start until after the first mouse movement
133	is detected.
134
135	See also [./server.wiki#loadmgmt\|Managing Server Load] for a description
136	of how expensive pages can be disabled when the server is under heavy
137	load.
138
139	<h2>The ongoing struggle</h2>
140
141

	--- www/antibot.wiki
	+++ www/antibot.wiki
	@@ -62,14 +62,14 @@
62
63	The first two UserAgent strings above identify Firefox 19 and
64	Internet Explorer 8.0, both running on Windows NT. The third
65	example is the spider used by Google to index the internet.
66	The fourth example is the "wget" utility running on OpenBSD.
67	Thus the first two UserAgent strings above identify the requester
68	as human whereas the second two identify the requester as a spider.
69	Note that the UserAgent string is completely under the control
70	of the requester and so a malicious spider can forge a UserAgent
71	string that makes it look like a human. But most spiders truly
72	seem to desire to "play nicely" on the internet and are quite open
73	about the fact that they are a spider. And so the UserAgent string
74	provides a good first-guess about whether or not a request originates
75	from a human or a spider.
	@@ -82,26 +82,26 @@
82	gives humans easy access to the hyperlinks while preventing spiders
83	from walking the millions of pages on a typical Fossil site.
84
85	But the hyperlinks are not enabled directly with the setting above.
86	Instead, the HTML code that is generated contains anchor tags ("<a>")
87	without "href=" attributes. Then, JavaScript code is added to the
88	end of the page that goes back and fills in the "href=" attributes of
89	the anchor tags with the hyperlink targets, thus enabling the hyperlinks.
90	This extra step of using JavaScript to enable the hyperlink targets
91	is a security measure against spiders that forge a human-looking
92	UserAgent string. Most spiders do not bother to run JavaScript and
93	so to the spider the empty anchor tag will be useless. But all modern
94	web browsers implement JavaScript, so hyperlinks will show up
95	normally for human users.
96
97	<h2>Further defenses</h2>
98
99	Recently (as of this writing, in the spring of 2013) the Fossil server
100	on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101	by Chinese spiders that use forged UserAgent strings to make them look
102	like normal web browsers and which interpret JavaScript. We do not
103	believe these attacks to be nefarious since SQLite is public domain
104	and the attackers could obtain all information they ever wanted to
105	know about SQLite simply by cloning the repository. Instead, we
106	believe these "attacks" are coming from "script kiddies". But regardless
107	of whether or not malice is involved, these attacks do present
	@@ -110,31 +110,31 @@
110	For this reason, additional defenses against
111	spiders have been put in place.
112
113	On the Admin/Access page of Fossil, just below the
114	"<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115	setting, there are now two additional sub-settings that can be optionally
116	enabled to control hyperlinks.
117
118	The first sub-setting waits to run the
119	JavaScript that sets the "href=" attributes on anchor tags until after
120	at least one "mouseover" event has been detected on the <body>
121	element of the page. The thinking here is that spiders will not be
122	simulating mouse motion and so no mouseover events will ever occur and
123	hence the hyperlinks will never become enabled for spiders.
124
125	The second new sub-setting is a delay (in milliseconds) before setting
126	the "href=" attributes on anchor tags. The default value for this
127	delay is 10 milliseconds. The idea here is that a spider will try to
128	render the page immediately, and will not wait for delayed scripts
129	to be run, thus will never enable the hyperlinks.
130
131	These two sub-settings can be used separately or together. If used together,
132	then the delay timer does not start until after the first mouse movement
133	is detected.
134
135	See also [./loadmgmt.md\|Managing Server Load] for a description
136	of how expensive pages can be disabled when the server is under heavy
137	load.
138
139	<h2>The ongoing struggle</h2>
140
141

M www/backoffice.md

+3 -3

		--- www/backoffice.md
		+++ www/backoffice.md
		@@ -9,11 +9,11 @@
9	9
10	10	What Is The Backoffice
11	11	----------------------
12	12
13	13	The backoffice is a mechanism used by a
14		-[Fossil server](/doc/trunk/www/server.wiki) to do low-priority
	14	+[Fossil server](./server/) to do low-priority
15	15	background work that is not directly related to the user interface. Here
16	16	are some examples of the kinds of work that backoffice performs:
17	17
18	18	1. Sending email alerts and notifications
19	19	2. Sending out daily digests of email notifications
		@@ -39,12 +39,12 @@
39	39	server for "[fossil sync](/help?cmd=sync)" and
40	40	[fossil clone](/help?cmd=clone)" commands which are implemented as
41	41	web requests - albeit requests that the human user never sees.
42	42	Web requests can arrive at the Fossil server via direct TCP/IP (for example
43	43	when Fossil is started using commands like "[fossil server](/help?cmd=server)")
44		-or via [CGI](/doc/trunk/www/server.wiki) or
45		-[SCGI](/doc/trunk/www/scgi.wiki) or via SSH.
	44	+or via [CGI](./server/any/cgi.md) or
	45	+[SCGI](./server/any/scgi.md) or via SSH.
46	46	A backoffice process might be started regardless of the origin of the
47	47	request.
48	48
49	49	The backoffice is not a daemon. Each backoffice process runs for a short
50	50	while and then exits. This helps keep Fossil easy to manage, since there
51	51

	--- www/backoffice.md
	+++ www/backoffice.md
	@@ -9,11 +9,11 @@
9
10	What Is The Backoffice
11	----------------------
12
13	The backoffice is a mechanism used by a
14	[Fossil server](/doc/trunk/www/server.wiki) to do low-priority
15	background work that is not directly related to the user interface. Here
16	are some examples of the kinds of work that backoffice performs:
17
18	1. Sending email alerts and notifications
19	2. Sending out daily digests of email notifications
	@@ -39,12 +39,12 @@
39	server for "[fossil sync](/help?cmd=sync)" and
40	[fossil clone](/help?cmd=clone)" commands which are implemented as
41	web requests - albeit requests that the human user never sees.
42	Web requests can arrive at the Fossil server via direct TCP/IP (for example
43	when Fossil is started using commands like "[fossil server](/help?cmd=server)")
44	or via [CGI](/doc/trunk/www/server.wiki) or
45	[SCGI](/doc/trunk/www/scgi.wiki) or via SSH.
46	A backoffice process might be started regardless of the origin of the
47	request.
48
49	The backoffice is not a daemon. Each backoffice process runs for a short
50	while and then exits. This helps keep Fossil easy to manage, since there
51

	--- www/backoffice.md
	+++ www/backoffice.md
	@@ -9,11 +9,11 @@
9
10	What Is The Backoffice
11	----------------------
12
13	The backoffice is a mechanism used by a
14	[Fossil server](./server/) to do low-priority
15	background work that is not directly related to the user interface. Here
16	are some examples of the kinds of work that backoffice performs:
17
18	1. Sending email alerts and notifications
19	2. Sending out daily digests of email notifications
	@@ -39,12 +39,12 @@
39	server for "[fossil sync](/help?cmd=sync)" and
40	[fossil clone](/help?cmd=clone)" commands which are implemented as
41	web requests - albeit requests that the human user never sees.
42	Web requests can arrive at the Fossil server via direct TCP/IP (for example
43	when Fossil is started using commands like "[fossil server](/help?cmd=server)")
44	or via [CGI](./server/any/cgi.md) or
45	[SCGI](./server/any/scgi.md) or via SSH.
46	A backoffice process might be started regardless of the origin of the
47	request.
48
49	The backoffice is not a daemon. Each backoffice process runs for a short
50	while and then exits. This helps keep Fossil easy to manage, since there
51

M www/branching.wiki

+2 -2

		--- www/branching.wiki
		+++ www/branching.wiki
		@@ -239,11 +239,11 @@
239	239	<li><p id="offline">By Fossil itself when two users check in children to the same
240	240	leaf of a branch, as in Figure 2. If the fork occurs because
241	241	autosync is disabled on one or both of the repositories or because
242	242	the user doing the check-in has no network connection at the moment
243	243	of the commit, Fossil has no way of knowing that it is creating a
244		- fork until the two repositories are later sync'd.</p></li>
	244	+ fork until the two repositories are later synchronized.</p></li>
245	245
246	246	<li><p id="dist-clone">By Fossil when the cloning hierarchy is more
247	247	than 2 levels deep.
248	248	<br><br>
249	249	[./sync.wiki\|Fossil's synchronization protocol] is a two-party
		@@ -591,10 +591,10 @@
591	591	workaround for Fossil's [./shunning.wiki\|normal inability to forget
592	592	history]: we usually don't want to actually <i>remove</i> history, but
593	593	would like to sometimes set some of it aside under a new label.
594	594
595	595	Because some VCSes can't cope with duplicate branch names, Fossil
596		-collapses such names down on export using the same timestamp based
	596	+collapses such names down on export using the same time stamp based
597	597	arbitration logic, so that only the branch with the newest checkin gets
598	598	the branch name in the export.
599	599
600	600	All of the above is true of tags in general, not just branches.
601	601
602	602	ADDED www/cgi.wiki

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -239,11 +239,11 @@
239	<li><p id="offline">By Fossil itself when two users check in children to the same
240	leaf of a branch, as in Figure 2. If the fork occurs because
241	autosync is disabled on one or both of the repositories or because
242	the user doing the check-in has no network connection at the moment
243	of the commit, Fossil has no way of knowing that it is creating a
244	fork until the two repositories are later sync'd.</p></li>
245
246	<li><p id="dist-clone">By Fossil when the cloning hierarchy is more
247	than 2 levels deep.
248	<br><br>
249	[./sync.wiki\|Fossil's synchronization protocol] is a two-party
	@@ -591,10 +591,10 @@
591	workaround for Fossil's [./shunning.wiki\|normal inability to forget
592	history]: we usually don't want to actually <i>remove</i> history, but
593	would like to sometimes set some of it aside under a new label.
594
595	Because some VCSes can't cope with duplicate branch names, Fossil
596	collapses such names down on export using the same timestamp based
597	arbitration logic, so that only the branch with the newest checkin gets
598	the branch name in the export.
599
600	All of the above is true of tags in general, not just branches.
601
602	DDED www/cgi.wiki

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -239,11 +239,11 @@
239	<li><p id="offline">By Fossil itself when two users check in children to the same
240	leaf of a branch, as in Figure 2. If the fork occurs because
241	autosync is disabled on one or both of the repositories or because
242	the user doing the check-in has no network connection at the moment
243	of the commit, Fossil has no way of knowing that it is creating a
244	fork until the two repositories are later synchronized.</p></li>
245
246	<li><p id="dist-clone">By Fossil when the cloning hierarchy is more
247	than 2 levels deep.
248	<br><br>
249	[./sync.wiki\|Fossil's synchronization protocol] is a two-party
	@@ -591,10 +591,10 @@
591	workaround for Fossil's [./shunning.wiki\|normal inability to forget
592	history]: we usually don't want to actually <i>remove</i> history, but
593	would like to sometimes set some of it aside under a new label.
594
595	Because some VCSes can't cope with duplicate branch names, Fossil
596	collapses such names down on export using the same time stamp based
597	arbitration logic, so that only the branch with the newest checkin gets
598	the branch name in the export.
599
600	All of the above is true of tags in general, not just branches.
601
602	DDED www/cgi.wiki

M www/cgi.wiki

+57

		--- a/www/cgi.wiki
		+++ b/www/cgi.wiki
		@@ -0,0 +1,57 @@
	1	+<title>CGI Script Configuration Options</title>
	2	+
	3	+<h1>Summary</h1>
	4	+
	5	+It is not necessary to have a central server in order to use Fossil.
	6	+But a central server can help a project run more smoothly by giving developers
	7	+a common point of rendezvous for syncing, and by providing a web-based
	8	+portal where developers and non-developers alike can learn about the
	9	+project and its current state.
	10	+
	11	+Setting up a server using Fossil is easy.
	12	+A [./server/\|separate document] talks about all of the many different methods for
	13	+setting up a Fossil server, one of which is [./server/any/cgi.md \| as a CGI
	14	+script]. CGI is the technique that the three
	15	+[./selfhost.wiki\|self-hosting Fossil repositories] all use.
	16	+
	17	+Setting up a Fossil server using CGI is mostly about writing a short
	18	+script (usually just 2 lines line) in the cgi-bin folder of an ordinary
	19	+web-browser. But there are a lot of extra options that can be added
	20	+to this script, to customize the configuration. This article descripb<title>CGI Script Configuration Opt<title>CGI Script Configuration Options</title>
	21	+
	22	+<h1>Summary</h1>
	23	+
	24	+It is not necessary to have a central server in order to use Fossil.
	25	+But a central server can help a project run more smoothly by giving developers
	26	+a common point of rendezvous for syncing, and by providing a web-based
	27	+portal where developers and non-developers alike can learn about the
	28	+project and its current state.
	29	+
	30	+Setting up a server using Fossil is easy.
	31	+A [./server/\|separate document] talks about all of the many different methods for
	32	+setting up a Fossil server, one of which is [./server/any/cgi.md \| as a CGI
	33	+script]. CGI is the technique that the three
	34	+[./selfhost.wiki\|self-hosting Fossil repositories] all use.
	35	+
	36	+Setting up a Fossil server using CGI is mostly about writing a short
	37	+script (usually just 2 lines line) in the cgi-bin folder of an ordinary
	38	+web-browser. But there are a lot of extra options that can be added
	39	+to this script, to customize the configuration. This article descripts
	40	+those options.
	41	+
	42	+<h1>CGI Script Options</h1>
	43	+
	44	+The CGI script used to launch a Fossil server will usually look something
	45	+like this:
	46	+
	47	+<blockquote><verbatim>
	48	+#!/usr/bin/fossil
	49	+repository: /home/www/fossils/myproje?cmd=t.fossil
	50	+</erbat</blockquotemyproje?cmd=t.fossil
	51	+</erbatim>
	52	+
	53	+Of course, pathnames will likely (the "shebangirst lb<title>CGI Script Configuration Opt<title>CGI Script Configurationlike this:
	54	+
	55	+<blockquote><verbatim>
	56	+#!/usr/bin/fossil
	57	+repository: /home/www/

	--- a/www/cgi.wiki
	+++ b/www/cgi.wiki
	@@ -0,0 +1,57 @@

	--- a/www/cgi.wiki
	+++ b/www/cgi.wiki
	@@ -0,0 +1,57 @@
1	<title>CGI Script Configuration Options</title>
2
3	<h1>Summary</h1>
4
5	It is not necessary to have a central server in order to use Fossil.
6	But a central server can help a project run more smoothly by giving developers
7	a common point of rendezvous for syncing, and by providing a web-based
8	portal where developers and non-developers alike can learn about the
9	project and its current state.
10
11	Setting up a server using Fossil is easy.
12	A [./server/\|separate document] talks about all of the many different methods for
13	setting up a Fossil server, one of which is [./server/any/cgi.md \| as a CGI
14	script]. CGI is the technique that the three
15	[./selfhost.wiki\|self-hosting Fossil repositories] all use.
16
17	Setting up a Fossil server using CGI is mostly about writing a short
18	script (usually just 2 lines line) in the cgi-bin folder of an ordinary
19	web-browser. But there are a lot of extra options that can be added
20	to this script, to customize the configuration. This article descripb<title>CGI Script Configuration Opt<title>CGI Script Configuration Options</title>
21
22	<h1>Summary</h1>
23
24	It is not necessary to have a central server in order to use Fossil.
25	But a central server can help a project run more smoothly by giving developers
26	a common point of rendezvous for syncing, and by providing a web-based
27	portal where developers and non-developers alike can learn about the
28	project and its current state.
29
30	Setting up a server using Fossil is easy.
31	A [./server/\|separate document] talks about all of the many different methods for
32	setting up a Fossil server, one of which is [./server/any/cgi.md \| as a CGI
33	script]. CGI is the technique that the three
34	[./selfhost.wiki\|self-hosting Fossil repositories] all use.
35
36	Setting up a Fossil server using CGI is mostly about writing a short
37	script (usually just 2 lines line) in the cgi-bin folder of an ordinary
38	web-browser. But there are a lot of extra options that can be added
39	to this script, to customize the configuration. This article descripts
40	those options.
41
42	<h1>CGI Script Options</h1>
43
44	The CGI script used to launch a Fossil server will usually look something
45	like this:
46
47	<blockquote><verbatim>
48	#!/usr/bin/fossil
49	repository: /home/www/fossils/myproje?cmd=t.fossil
50	</erbat</blockquotemyproje?cmd=t.fossil
51	</erbatim>
52
53	Of course, pathnames will likely (the "shebangirst lb<title>CGI Script Configuration Opt<title>CGI Script Configurationlike this:
54
55	<blockquote><verbatim>
56	#!/usr/bin/fossil
57	repository: /home/www/

M www/changes.wiki

+7

		--- www/changes.wiki
		+++ www/changes.wiki
		@@ -8,11 +8,18 @@
8	8	add style to repository list pages.
9	9	* Enhance the hierarchical display of Forum threads to do less
10	10	indentation and to provide links back to the previous message
11	11	in the thread. Provide sequential numbers for all messages in
12	12	a forum thread.
	13	+ * Add support for fenced code blocks and improved hyperlink
	14	+ processing to the [/md_rules\|markdown formatter].
	15	+ * Enhance the [/help?cmd=/stat\|/stat] page so that it gives the
	16	+ option to show a breakdown of forum posts.
13	17	* Change the default [./hashpolicy.wiki\|hash policy] to SHA3.
	18	+ * Timeout [./server/any/cgi.md\|CGI requests] after 300 seconds, or
	19	+ some other value set by the
	20	+ [./cgi.wiki#timeout\|"timeout:" property] in the CGI script.
14	21	* Documentation improvements
15	22
16	23	<a name='v2_9'></a>
17	24	<h2>Changes for Version 2.9 (2019-07-13)</h2>
18	25
19	26
20	27	ADDED www/chroot.md

	--- www/changes.wiki
	+++ www/changes.wiki
	@@ -8,11 +8,18 @@
8	add style to repository list pages.
9	* Enhance the hierarchical display of Forum threads to do less
10	indentation and to provide links back to the previous message
11	in the thread. Provide sequential numbers for all messages in
12	a forum thread.




13	* Change the default [./hashpolicy.wiki\|hash policy] to SHA3.



14	* Documentation improvements
15
16	<a name='v2_9'></a>
17	<h2>Changes for Version 2.9 (2019-07-13)</h2>
18
19
20	DDED www/chroot.md

	--- www/changes.wiki
	+++ www/changes.wiki
	@@ -8,11 +8,18 @@
8	add style to repository list pages.
9	* Enhance the hierarchical display of Forum threads to do less
10	indentation and to provide links back to the previous message
11	in the thread. Provide sequential numbers for all messages in
12	a forum thread.
13	* Add support for fenced code blocks and improved hyperlink
14	processing to the [/md_rules\|markdown formatter].
15	* Enhance the [/help?cmd=/stat\|/stat] page so that it gives the
16	option to show a breakdown of forum posts.
17	* Change the default [./hashpolicy.wiki\|hash policy] to SHA3.
18	* Timeout [./server/any/cgi.md\|CGI requests] after 300 seconds, or
19	some other value set by the
20	[./cgi.wiki#timeout\|"timeout:" property] in the CGI script.
21	* Documentation improvements
22
23	<a name='v2_9'></a>
24	<h2>Changes for Version 2.9 (2019-07-13)</h2>
25
26
27	DDED www/chroot.md

M www/chroot.md

+38

		--- a/www/chroot.md
		+++ b/www/chroot.md
		@@ -0,0 +1,38 @@
	1	+# The Server Chroot Jail
	2	+
	3	+If you run Fossil as root in any mode that [serves data on the
	4	+network][srv], and you're running it on Unix or a compatible OS, Fossil
	5	+will drop itself into a [`chroot(2)` jail][cj, once it's done everything that requires root access. Most commonly,
	6	+you run Fossil as root to allow it to bind to TCP port 80 for HTTP
	7	+service, since normal users are reup on OSes.
	8	+
	9	+Fossil uses the owner of the Fossil repository file as its new user
	10	+ID when it drops root privileges.
	11	+
	12	+When Fossil enters a chroot jail, it needs to have all of its dependencies
	13	+inside the chroot jail in order to continue work. There are several
	14	+resources that need to be inside the chroot jail with Fossil in order for
	15	+Fossil to work correctly:
	16	+
	17	+* the repository file(s)
	18	+
	19	+* `/dev/null` — create it with `mknod(8)` inside the jail directory
	20	+ ([Linux example][mnl], [OpenBSD example][obsd])
	21	+
	22	+* `/d `/proc` — you might need to mount this virtual filesystem inside the
	23	+ jail on Linux systems that make use of [Fossil’s server load
	24	+ shedding feature][fls]
	25	+
	26	+* any shared libraries your `fossil` binary is linked to, unless you
	27	+ [configured Fossil with `--static`][bld] to avoid it
	28	+
	29	+Fossil does all of this as one of many layers of defense against
	30	+hacks and exploits. You can prevent Fossil from entering the chroot
	31	+jail using the <tt>--nojail</tt> option to the
	32	+[fossil server command](/help?cmd=server)
	33	+but you cannot make Fossil hold onto root privileges. Fossiwww.fossil-scm.org/fossil. Fossil always drops
	34	+root privilege before accepting inputs, for security.
	35	+
	36	+
	37	+[bld]: https://fossil-scm.org/home/doc/trunk/www/build.wiki
	38	+[cj]: https://en.wikipeht

	--- a/www/chroot.md
	+++ b/www/chroot.md
	@@ -0,0 +1,38 @@

	--- a/www/chroot.md
	+++ b/www/chroot.md
	@@ -0,0 +1,38 @@
1	# The Server Chroot Jail
2
3	If you run Fossil as root in any mode that [serves data on the
4	network][srv], and you're running it on Unix or a compatible OS, Fossil
5	will drop itself into a [`chroot(2)` jail][cj, once it's done everything that requires root access. Most commonly,
6	you run Fossil as root to allow it to bind to TCP port 80 for HTTP
7	service, since normal users are reup on OSes.
8
9	Fossil uses the owner of the Fossil repository file as its new user
10	ID when it drops root privileges.
11
12	When Fossil enters a chroot jail, it needs to have all of its dependencies
13	inside the chroot jail in order to continue work. There are several
14	resources that need to be inside the chroot jail with Fossil in order for
15	Fossil to work correctly:
16
17	* the repository file(s)
18
19	* `/dev/null` — create it with `mknod(8)` inside the jail directory
20	([Linux example][mnl], [OpenBSD example][obsd])
21
22	* `/d `/proc` — you might need to mount this virtual filesystem inside the
23	jail on Linux systems that make use of [Fossil’s server load
24	shedding feature][fls]
25
26	* any shared libraries your `fossil` binary is linked to, unless you
27	[configured Fossil with `--static`][bld] to avoid it
28
29	Fossil does all of this as one of many layers of defense against
30	hacks and exploits. You can prevent Fossil from entering the chroot
31	jail using the <tt>--nojail</tt> option to the
32	[fossil server command](/help?cmd=server)
33	but you cannot make Fossil hold onto root privileges. Fossiwww.fossil-scm.org/fossil. Fossil always drops
34	root privilege before accepting inputs, for security.
35
36
37	[bld]: https://fossil-scm.org/home/doc/trunk/www/build.wiki
38	[cj]: https://en.wikipeht

M www/concepts.wiki

+2 -2

		--- www/concepts.wiki
		+++ www/concepts.wiki
		@@ -196,11 +196,11 @@
196	196	or [./build.wiki \| compiling it yourself]) and then
197	197	putting that file somewhere on your PATH.
198	198
199	199	Fossil is completely self-contained. It is not necessary to
200	200	install any other software in order to use Fossil. You do <u>not</u> need
201		-CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL,
	201	+CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, Apache, PostgreSQL, MySQL,
202	202	SQLite, patch, or any similar software on your system in order to use
203	203	Fossil effectively. You will want to have some kind of text editor
204	204	for entering check-in comments. Fossil will use whatever text editor
205	205	is identified by your VISUAL environment variable. Fossil will also
206	206	use GPG to clearsign your manifests if you happen to have it installed,
		@@ -423,11 +423,11 @@
423	423	<li><p><b>Inetd or Stunnel.</b>
424	424	Configure programs like inetd, xinetd, or stunnel to hand off HTTP requests
425	425	directly to the [/help?cmd=http\|fossil http] command.
426	426	</ol>
427	427
428		-See the [./server.wiki \| How To Configure A Fossil Server] document
	428	+See the [./server/ \| How To Configure A Fossil Server] document
429	429	for details.
430	430
431	431	<h2>6.0 Review Of Key Concepts</h2>
432	432
433	433	<ul>
434	434

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -196,11 +196,11 @@
196	or [./build.wiki \| compiling it yourself]) and then
197	putting that file somewhere on your PATH.
198
199	Fossil is completely self-contained. It is not necessary to
200	install any other software in order to use Fossil. You do <u>not</u> need
201	CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL,
202	SQLite, patch, or any similar software on your system in order to use
203	Fossil effectively. You will want to have some kind of text editor
204	for entering check-in comments. Fossil will use whatever text editor
205	is identified by your VISUAL environment variable. Fossil will also
206	use GPG to clearsign your manifests if you happen to have it installed,
	@@ -423,11 +423,11 @@
423	<li><p><b>Inetd or Stunnel.</b>
424	Configure programs like inetd, xinetd, or stunnel to hand off HTTP requests
425	directly to the [/help?cmd=http\|fossil http] command.
426	</ol>
427
428	See the [./server.wiki \| How To Configure A Fossil Server] document
429	for details.
430
431	<h2>6.0 Review Of Key Concepts</h2>
432
433	<ul>
434

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -196,11 +196,11 @@
196	or [./build.wiki \| compiling it yourself]) and then
197	putting that file somewhere on your PATH.
198
199	Fossil is completely self-contained. It is not necessary to
200	install any other software in order to use Fossil. You do <u>not</u> need
201	CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, Apache, PostgreSQL, MySQL,
202	SQLite, patch, or any similar software on your system in order to use
203	Fossil effectively. You will want to have some kind of text editor
204	for entering check-in comments. Fossil will use whatever text editor
205	is identified by your VISUAL environment variable. Fossil will also
206	use GPG to clearsign your manifests if you happen to have it installed,
	@@ -423,11 +423,11 @@
423	<li><p><b>Inetd or Stunnel.</b>
424	Configure programs like inetd, xinetd, or stunnel to hand off HTTP requests
425	directly to the [/help?cmd=http\|fossil http] command.
426	</ol>
427
428	See the [./server/ \| How To Configure A Fossil Server] document
429	for details.
430
431	<h2>6.0 Review Of Key Concepts</h2>
432
433	<ul>
434

M www/contribute.wiki

+1 -1

		--- www/contribute.wiki
		+++ www/contribute.wiki
		@@ -55,11 +55,11 @@
55	55	Contributors are required to following the
56	56	[./checkin.wiki \| pre-checkin checklist] prior to every check-in to
57	57	the Fossil self-hosting repository. This checklist is short and succinct
58	58	and should only require a few seconds to follow. Contributors
59	59	should print out a copy of the pre-checkin checklist and keep
60		-it on a notecard beside their workstations, for quick reference.
	60	+it on a note card beside their workstations, for quick reference.
61	61
62	62	Contributors should review the
63	63	[./style.wiki \| Coding Style Guidelines] and mimic the coding style
64	64	used through the rest of the Fossil source code. Your code should
65	65	blend in. A third-party reader should be unable to distinguish your
66	66

	--- www/contribute.wiki
	+++ www/contribute.wiki
	@@ -55,11 +55,11 @@
55	Contributors are required to following the
56	[./checkin.wiki \| pre-checkin checklist] prior to every check-in to
57	the Fossil self-hosting repository. This checklist is short and succinct
58	and should only require a few seconds to follow. Contributors
59	should print out a copy of the pre-checkin checklist and keep
60	it on a notecard beside their workstations, for quick reference.
61
62	Contributors should review the
63	[./style.wiki \| Coding Style Guidelines] and mimic the coding style
64	used through the rest of the Fossil source code. Your code should
65	blend in. A third-party reader should be unable to distinguish your
66

	--- www/contribute.wiki
	+++ www/contribute.wiki
	@@ -55,11 +55,11 @@
55	Contributors are required to following the
56	[./checkin.wiki \| pre-checkin checklist] prior to every check-in to
57	the Fossil self-hosting repository. This checklist is short and succinct
58	and should only require a few seconds to follow. Contributors
59	should print out a copy of the pre-checkin checklist and keep
60	it on a note card beside their workstations, for quick reference.
61
62	Contributors should review the
63	[./style.wiki \| Coding Style Guidelines] and mimic the coding style
64	used through the rest of the Fossil source code. Your code should
65	blend in. A third-party reader should be unable to distinguish your
66

M www/customskin.md

+76 -64

		--- www/customskin.md
		+++ www/customskin.md
		@@ -1,7 +1,6 @@
1		-Theming
2		-=======
	1	+# Skinning the Fossil Web Interface
3	2
4	3	Every HTML page generated by Fossil has the following basic structure:
5	4
6	5	<blockquote><table border=1 cellpadding=10><tbody>
7	6	<tr><td style='background-color:lightblue;text-align:center;'>Header</td></tr>
		@@ -9,43 +8,54 @@
9	8	Fossil-Generated Content</td></tr>
10	9	<tr><td style='background-color:lightblue;text-align:center;'>Footer</td></tr>
11	10	<tr><td style='background-color:lightyellow;text-align:center;'>Javascript (optional)</td></tr>
12	11	</tbody></table></blockquote>
13	12
14		-The header and footer control the "look" of Fossil pages. Those
15		-two sections can be customized separately for each repository to
16		-develop a new theme.
17		-
18		-The header will normally look something like this:
19		-
20		- <html>
21		- <head> ... </head>
22		- <body>
23		- ... top banner and menu bar ...
24		- <div class='content'>
25		-
26		-And the footer will look something like this:
27		-
	13	+The default header looks something like this:
	14	+
	15	+ <div class="header">
	16	+ <div class="title"><h1>$<project_name></h1>$<title></div>
	17	+ ... top banner and menu bar ...
	18	+
	19	+The Fossil-generated content section looks like this:
	20	+
	21	+ <div class="content">
	22	+ ... generated content here ...
	23	+ </div>
	24	+
	25	+And the footer looks like this:
	26	+
	27	+ <div class="footer">
	28	+ ... skin-specific stuff here ...
28	29	</div>
29		- ... bottom material ...
30		- </body>
31		- </html>
32		-
33		-The <head> element in the header will normally reference the
34		-/style.css CSS file that Fossil stores internally. (The $stylesheet_url
35		-TH1 variable, described below, is useful for accomplishing this.)
36		-
37		-The middle "content" section comprised the bulk of most pages and
	30	+ <script nonce=$nonce>
	31	+ <th1>styleScript</th1>
	32	+ </script>
	33	+
	34	+Notice that there are no `<html>` or `<head>` elements in the header,
	35	+nor is there an `</html>` closing tag in the footer. Fossil generates
	36	+this material automatically unless it sees that you have provided your
	37	+own HTML document header within the skin’s Header section.
	38	+
	39	+This design lets most users get the benefit of Fossil’s automatic HTML
	40	+document header, which takes care of quite a few different things for
	41	+you, while still allowing you to [override if at need](#headfoot).
	42	+
	43	+When overriding the default document header, you might want to use some
	44	+of the [TH1 variables documented below](#vars) such as `$stylesheet_url`
	45	+to avoid hand-writing code that Fossil can generate for you.
	46	+
	47	+The middle "content" section comprises the bulk of most pages and
38	48	contains the actual Fossil-generated data
39	49	that the user is interested in seeing. The text of this content
40	50	section is not normally configurable. The content text can be styled
41		-using CSS, but it otherwise fixed. Hence it is the header and footer
	51	+using CSS, but it is otherwise fixed. Hence it is the header, the footer,
42	52	and the CSS that determine the look of a repository.
43	53	We call the bundle of built-in CSS, header, and footer a "skin".
44	54
45		-Built-in Skins
		---------------
	55	+
	56	+## <a name="builtin"></a>Built-in Skins
46	57
47	58	Fossil comes with several built-in skins. The sources to these built-ins can
48	59	be found in the Fossil source tree under the skins/ folder. The skins/
49	60	folder contains a separate subfolder for each built-in skin, with each
50	61	subfolders holding four files, "css.txt", "details.txt",
		@@ -59,12 +69,12 @@
59	69	line option can be used for the
60	70	[fossil ui](../../../help?cmd=ui) or
61	71	[fossil server](../../../help?cmd=server) commands to force that particular
62	72	instance of Fossil to use the specified built-in skin.
63	73
64		-Sharing Skins
		--------------
	74	+
	75	+## <a name="sharing"></a>Sharing Skins
65	76
66	77	The skin of a repository is not part of the versioned state and does not
67	78	"push" or "pull" like checked-in files. The skin is local to the
68	79	repository. However, skins can be shared between repositories using
69	80	the [fossil config](../../../help?cmd=configuration) command.
		@@ -88,58 +98,51 @@
88	98	necessary.
89	99
90	100	When cloning a repository, the skin of new repository is initialized to
91	101	the skin of the repository from which it was cloned.
92	102
93		-Header And Footer Processing
		-----------------------------
	103	+
	104	+## <a name="headfoot"></a>Header and Footer Processing
94	105
95		-The header.txt and footer.txt files of a skin are merely the HTML text
96		-of the header and footer. Except, before being prepended and appended to
97		-the content, the header and footer text are run through a
	106	+The `header.txt` and `footer.txt` files of a skin are merely the HTML text
	107	+of the header and footer, except that before being prepended and appended to
	108	+the content, their text content is run through a
98	109	[TH1 interpreter](./th1.md) that might adjust the text as follows:
99	110
100	111	* All text within <th1>...</th1> is elided from the
101	112	output and that text is instead run as a TH1 script. That TH1
102	113	script has the opportunity to insert new text in place of itself,
103	114	or to inhibit or enable the output of subsequent text.
104	115
105		- * Text for the form "$NAME" or "$<NAME>" is replace with
	116	+ * Text of the form "$NAME" or "$<NAME>" is replaced with
106	117	the value of the TH1 variable NAME.
107	118
108		-For example, the following is the first few lines of a typical
109		-header file:
110		-
111		- <html>
112		- <head>
113		- <base href="$baseurl/$current_page" />
114		- <title>$<project_name>: $<title></title>
115		- <link rel="alternate" type="application/rss+xml" title="RSS Feed"
116		- href="$home/timeline.rss" />
117		- <link rel="stylesheet" href="$stylesheet_url" type="text/css"
118		- media="screen" />
119		- </head>
120		-
121		-After variables are substituted by TH1, the final header text
122		-delivered to the web browser might look something like this:
123		-
124		- <html>
125		- <head>
126		- <base href="https://www.fossil-scm.org/skin2/timeline" />
127		- <title>Fossil: Timeline</title>
128		- <link rel="alternate" type="application/rss+xml" title="RSS Feed"
129		- href="/skin2/timeline.rss" />
130		- <link rel="stylesheet" href="/skin2/style.css?default" type="text/css"
131		- media="screen" />
132		- </head>
	119	+Above, we saw the first few lines of a typical Fossil skin header:
	120	+
	121	+ <div class="header">
	122	+ <div class="title"><h1>$<project_name></h1>$<title>/div>
	123	+
	124	+After variables are substituted by TH1, that will look more like this:
	125	+
	126	+ <div class="header">
	127	+ <div class="title"><h1>Project Name</h1>Page Title</div>
	128	+
	129	+As you can see, two TH1 variable substitutions were done.
133	130
134	131	The same TH1 interpreter is used for both the header and the footer
135	132	and for all scripts contained within them both. Hence, any global
136	133	TH1 variables that are set by the header are available to the footer.
137	134
138		-Customizing the ≡ Hamburger Menu
		---------------------------------
	135	+Fossil provides the HTML
	136	+document container tags `<html>`, `<head>`, and their inner content when
	137	+your skin’s header and footer don’t include them. This default header
	138	+declares the repository’s Content Security Policy (CSP) which is well
	139	+worth understanding, but since it is not strictly about skinning, we
	140	+cover that in [a separate document](./defcsp.md).
	141	+
	142	+
	143	+## <a name="menu"></a>Customizing the ≡ Hamburger Menu
139	144
140	145	The menu bar of the default skin has an entry to open a drop-down menu with
141	146	additional navigation links, represented by the ≡ button (hence the name
142	147	"hamburger menu"). The Javascript logic to open and close the hamburger menu
143	148	when the button is clicked is contained in the optional Javascript part (js.txt)
		@@ -193,12 +196,12 @@
193	196	The custom `data-anim-ms` attribute can be added to the panel element to direct
194	197	the Javascript logic to override the default menu animation duration of 400 ms.
195	198	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
196	199	animation is disabled by setting the attribute to `"0"`.
197	200
198		-TH1 Variables
		--------------
	201	+
	202	+## <a name="vars"></a>TH1 Variables
199	203
200	204	Before expanding the TH1 within the header and footer, Fossil first
201	205	initializes a number of TH1 variables to values that depend on
202	206	repository settings and the specific page being generated.
203	207
		@@ -234,12 +237,14 @@
234	237	without the leading "/" and without query parameters.
235	238	Examples: "timeline", "doc/trunk/README.txt", "wiki".
236	239
237	240	* csrf_token - A token used to prevent cross-site request forgery.
238	241
239		- * default_csp - The content to be used within the default header
240		- for the "Content-Security-Policy" meta tag.
	242	+ * default_csp - [Fossil’s default CSP](./defcsp.md) unless
	243	+ [overridden by custom TH1 code](./defcsp.md#th1). Useful within
	244	+ the skin for inserting the CSP into a `<meta>` tag within [a
	245	+ custom `<head>` element](#headfoot).
241	246
242	247	* nonce - The value of the cryptographic nonce for the request
243	248	being processed.
244	249
245	250	* release_version - The release version of Fossil. Ex: "1.31"
		@@ -268,12 +273,12 @@
268	273	All of the above are variables in the sense that either the header or the
269	274	footer is free to change or erase them. But they should probably be treated
270	275	as constants. New predefined values are likely to be added in future
271	276	releases of Fossil.
272	277
273		-Suggested Skin Customization Procedure
		---------------------------------------
	278	+
	279	+## <a name="procedure"></a>Suggested Skin Customization Procedure
274	280
275	281	Developers are free, of course, to develop new skins using any method they
276	282	want, but the following is a technique that has worked well in the past and
277	283	can serve as a starting point for future work:
278	284
		@@ -302,9 +307,9 @@
302	307	4. Copy/paste the resulting css.txt, details.txt,
303	308	header.txt, and footer.txt files
304	309	into the CSS, details, header, and footer configuration screens
305	310	under the Admin/Skins menu.
306	311
307		-See Also
		---------
	312	+
	313	+## See Also
308	314
309	315	* [Customizing the Timeline Graph](customgraph.md)
310	316
311	317	ADDED www/defcsp.md

	--- www/customskin.md
	+++ www/customskin.md
	@@ -1,7 +1,6 @@
1	Theming
2	=======
3
4	Every HTML page generated by Fossil has the following basic structure:
5
6	<blockquote><table border=1 cellpadding=10><tbody>
7	<tr><td style='background-color:lightblue;text-align:center;'>Header</td></tr>
	@@ -9,43 +8,54 @@
9	Fossil-Generated Content</td></tr>
10	<tr><td style='background-color:lightblue;text-align:center;'>Footer</td></tr>
11	<tr><td style='background-color:lightyellow;text-align:center;'>Javascript (optional)</td></tr>
12	</tbody></table></blockquote>
13
14	The header and footer control the "look" of Fossil pages. Those
15	two sections can be customized separately for each repository to
16	develop a new theme.
17
18	The header will normally look something like this:
19
20	<html>
21	<head> ... </head>
22	<body>
23	... top banner and menu bar ...
24	<div class='content'>
25
26	And the footer will look something like this:
27


28	</div>
29	... bottom material ...
30	</body>
31	</html>
32
33	The <head> element in the header will normally reference the
34	/style.css CSS file that Fossil stores internally. (The $stylesheet_url
35	TH1 variable, described below, is useful for accomplishing this.)
36
37	The middle "content" section comprised the bulk of most pages and









38	contains the actual Fossil-generated data
39	that the user is interested in seeing. The text of this content
40	section is not normally configurable. The content text can be styled
41	using CSS, but it otherwise fixed. Hence it is the header and footer
42	and the CSS that determine the look of a repository.
43	We call the bundle of built-in CSS, header, and footer a "skin".
44
45	Built-in Skins
	---------------


46
47	Fossil comes with several built-in skins. The sources to these built-ins can
48	be found in the Fossil source tree under the skins/ folder. The skins/
49	folder contains a separate subfolder for each built-in skin, with each
50	subfolders holding four files, "css.txt", "details.txt",
	@@ -59,12 +69,12 @@
59	line option can be used for the
60	[fossil ui](../../../help?cmd=ui) or
61	[fossil server](../../../help?cmd=server) commands to force that particular
62	instance of Fossil to use the specified built-in skin.
63
64	Sharing Skins
	--------------


65
66	The skin of a repository is not part of the versioned state and does not
67	"push" or "pull" like checked-in files. The skin is local to the
68	repository. However, skins can be shared between repositories using
69	the [fossil config](../../../help?cmd=configuration) command.
	@@ -88,58 +98,51 @@
88	necessary.
89
90	When cloning a repository, the skin of new repository is initialized to
91	the skin of the repository from which it was cloned.
92
93	Header And Footer Processing
	-----------------------------


94
95	The header.txt and footer.txt files of a skin are merely the HTML text
96	of the header and footer. Except, before being prepended and appended to
97	the content, the header and footer text are run through a
98	[TH1 interpreter](./th1.md) that might adjust the text as follows:
99
100	* All text within <th1>...</th1> is elided from the
101	output and that text is instead run as a TH1 script. That TH1
102	script has the opportunity to insert new text in place of itself,
103	or to inhibit or enable the output of subsequent text.
104
105	* Text for the form "$NAME" or "$<NAME>" is replace with
106	the value of the TH1 variable NAME.
107
108	For example, the following is the first few lines of a typical
109	header file:
110
111	<html>
112	<head>
113	<base href="$baseurl/$current_page" />
114	<title>$<project_name>: $<title></title>
115	<link rel="alternate" type="application/rss+xml" title="RSS Feed"
116	href="$home/timeline.rss" />
117	<link rel="stylesheet" href="$stylesheet_url" type="text/css"
118	media="screen" />
119	</head>
120
121	After variables are substituted by TH1, the final header text
122	delivered to the web browser might look something like this:
123
124	<html>
125	<head>
126	<base href="https://www.fossil-scm.org/skin2/timeline" />
127	<title>Fossil: Timeline</title>
128	<link rel="alternate" type="application/rss+xml" title="RSS Feed"
129	href="/skin2/timeline.rss" />
130	<link rel="stylesheet" href="/skin2/style.css?default" type="text/css"
131	media="screen" />
132	</head>
133
134	The same TH1 interpreter is used for both the header and the footer
135	and for all scripts contained within them both. Hence, any global
136	TH1 variables that are set by the header are available to the footer.
137
138	Customizing the ≡ Hamburger Menu
	---------------------------------









139
140	The menu bar of the default skin has an entry to open a drop-down menu with
141	additional navigation links, represented by the ≡ button (hence the name
142	"hamburger menu"). The Javascript logic to open and close the hamburger menu
143	when the button is clicked is contained in the optional Javascript part (js.txt)
	@@ -193,12 +196,12 @@
193	The custom `data-anim-ms` attribute can be added to the panel element to direct
194	the Javascript logic to override the default menu animation duration of 400 ms.
195	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
196	animation is disabled by setting the attribute to `"0"`.
197
198	TH1 Variables
	--------------


199
200	Before expanding the TH1 within the header and footer, Fossil first
201	initializes a number of TH1 variables to values that depend on
202	repository settings and the specific page being generated.
203
	@@ -234,12 +237,14 @@
234	without the leading "/" and without query parameters.
235	Examples: "timeline", "doc/trunk/README.txt", "wiki".
236
237	* csrf_token - A token used to prevent cross-site request forgery.
238
239	* default_csp - The content to be used within the default header
240	for the "Content-Security-Policy" meta tag.


241
242	* nonce - The value of the cryptographic nonce for the request
243	being processed.
244
245	* release_version - The release version of Fossil. Ex: "1.31"
	@@ -268,12 +273,12 @@
268	All of the above are variables in the sense that either the header or the
269	footer is free to change or erase them. But they should probably be treated
270	as constants. New predefined values are likely to be added in future
271	releases of Fossil.
272
273	Suggested Skin Customization Procedure
	---------------------------------------


274
275	Developers are free, of course, to develop new skins using any method they
276	want, but the following is a technique that has worked well in the past and
277	can serve as a starting point for future work:
278
	@@ -302,9 +307,9 @@
302	4. Copy/paste the resulting css.txt, details.txt,
303	header.txt, and footer.txt files
304	into the CSS, details, header, and footer configuration screens
305	under the Admin/Skins menu.
306
307	See Also
	---------


308
309	* [Customizing the Timeline Graph](customgraph.md)
310
311	DDED www/defcsp.md

	--- www/customskin.md
	+++ www/customskin.md
	@@ -1,7 +1,6 @@
1	# Skinning the Fossil Web Interface

2
3	Every HTML page generated by Fossil has the following basic structure:
4
5	<blockquote><table border=1 cellpadding=10><tbody>
6	<tr><td style='background-color:lightblue;text-align:center;'>Header</td></tr>
	@@ -9,43 +8,54 @@
8	Fossil-Generated Content</td></tr>
9	<tr><td style='background-color:lightblue;text-align:center;'>Footer</td></tr>
10	<tr><td style='background-color:lightyellow;text-align:center;'>Javascript (optional)</td></tr>
11	</tbody></table></blockquote>
12
13	The default header looks something like this:
14
15	<div class="header">
16	<div class="title"><h1>$<project_name></h1>$<title></div>
17	... top banner and menu bar ...
18
19	The Fossil-generated content section looks like this:
20
21	<div class="content">
22	... generated content here ...
23	</div>
24
25	And the footer looks like this:
26
27	<div class="footer">
28	... skin-specific stuff here ...
29	</div>
30	<script nonce=$nonce>
31	<th1>styleScript</th1>
32	</script>
33
34	Notice that there are no `<html>` or `<head>` elements in the header,
35	nor is there an `</html>` closing tag in the footer. Fossil generates
36	this material automatically unless it sees that you have provided your
37	own HTML document header within the skin’s Header section.
38
39	This design lets most users get the benefit of Fossil’s automatic HTML
40	document header, which takes care of quite a few different things for
41	you, while still allowing you to [override if at need](#headfoot).
42
43	When overriding the default document header, you might want to use some
44	of the [TH1 variables documented below](#vars) such as `$stylesheet_url`
45	to avoid hand-writing code that Fossil can generate for you.
46
47	The middle "content" section comprises the bulk of most pages and
48	contains the actual Fossil-generated data
49	that the user is interested in seeing. The text of this content
50	section is not normally configurable. The content text can be styled
51	using CSS, but it is otherwise fixed. Hence it is the header, the footer,
52	and the CSS that determine the look of a repository.
53	We call the bundle of built-in CSS, header, and footer a "skin".
54

	---------------
55
56	## <a name="builtin"></a>Built-in Skins
57
58	Fossil comes with several built-in skins. The sources to these built-ins can
59	be found in the Fossil source tree under the skins/ folder. The skins/
60	folder contains a separate subfolder for each built-in skin, with each
61	subfolders holding four files, "css.txt", "details.txt",
	@@ -59,12 +69,12 @@
69	line option can be used for the
70	[fossil ui](../../../help?cmd=ui) or
71	[fossil server](../../../help?cmd=server) commands to force that particular
72	instance of Fossil to use the specified built-in skin.
73

	--------------
74
75	## <a name="sharing"></a>Sharing Skins
76
77	The skin of a repository is not part of the versioned state and does not
78	"push" or "pull" like checked-in files. The skin is local to the
79	repository. However, skins can be shared between repositories using
80	the [fossil config](../../../help?cmd=configuration) command.
	@@ -88,58 +98,51 @@
98	necessary.
99
100	When cloning a repository, the skin of new repository is initialized to
101	the skin of the repository from which it was cloned.
102

	-----------------------------
103
104	## <a name="headfoot"></a>Header and Footer Processing
105
106	The `header.txt` and `footer.txt` files of a skin are merely the HTML text
107	of the header and footer, except that before being prepended and appended to
108	the content, their text content is run through a
109	[TH1 interpreter](./th1.md) that might adjust the text as follows:
110
111	* All text within <th1>...</th1> is elided from the
112	output and that text is instead run as a TH1 script. That TH1
113	script has the opportunity to insert new text in place of itself,
114	or to inhibit or enable the output of subsequent text.
115
116	* Text of the form "$NAME" or "$<NAME>" is replaced with
117	the value of the TH1 variable NAME.
118
119	Above, we saw the first few lines of a typical Fossil skin header:
120
121	<div class="header">
122	<div class="title"><h1>$<project_name></h1>$<title>/div>
123
124	After variables are substituted by TH1, that will look more like this:
125
126	<div class="header">
127	<div class="title"><h1>Project Name</h1>Page Title</div>
128
129	As you can see, two TH1 variable substitutions were done.














130
131	The same TH1 interpreter is used for both the header and the footer
132	and for all scripts contained within them both. Hence, any global
133	TH1 variables that are set by the header are available to the footer.
134

	---------------------------------
135	Fossil provides the HTML
136	document container tags `<html>`, `<head>`, and their inner content when
137	your skin’s header and footer don’t include them. This default header
138	declares the repository’s Content Security Policy (CSP) which is well
139	worth understanding, but since it is not strictly about skinning, we
140	cover that in [a separate document](./defcsp.md).
141
142
143	## <a name="menu"></a>Customizing the ≡ Hamburger Menu
144
145	The menu bar of the default skin has an entry to open a drop-down menu with
146	additional navigation links, represented by the ≡ button (hence the name
147	"hamburger menu"). The Javascript logic to open and close the hamburger menu
148	when the button is clicked is contained in the optional Javascript part (js.txt)
	@@ -193,12 +196,12 @@
196	The custom `data-anim-ms` attribute can be added to the panel element to direct
197	the Javascript logic to override the default menu animation duration of 400 ms.
198	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
199	animation is disabled by setting the attribute to `"0"`.
200

	--------------
201
202	## <a name="vars"></a>TH1 Variables
203
204	Before expanding the TH1 within the header and footer, Fossil first
205	initializes a number of TH1 variables to values that depend on
206	repository settings and the specific page being generated.
207
	@@ -234,12 +237,14 @@
237	without the leading "/" and without query parameters.
238	Examples: "timeline", "doc/trunk/README.txt", "wiki".
239
240	* csrf_token - A token used to prevent cross-site request forgery.
241
242	* default_csp - [Fossil’s default CSP](./defcsp.md) unless
243	[overridden by custom TH1 code](./defcsp.md#th1). Useful within
244	the skin for inserting the CSP into a `<meta>` tag within [a
245	custom `<head>` element](#headfoot).
246
247	* nonce - The value of the cryptographic nonce for the request
248	being processed.
249
250	* release_version - The release version of Fossil. Ex: "1.31"
	@@ -268,12 +273,12 @@
273	All of the above are variables in the sense that either the header or the
274	footer is free to change or erase them. But they should probably be treated
275	as constants. New predefined values are likely to be added in future
276	releases of Fossil.
277

	---------------------------------------
278
279	## <a name="procedure"></a>Suggested Skin Customization Procedure
280
281	Developers are free, of course, to develop new skins using any method they
282	want, but the following is a technique that has worked well in the past and
283	can serve as a starting point for future work:
284
	@@ -302,9 +307,9 @@
307	4. Copy/paste the resulting css.txt, details.txt,
308	header.txt, and footer.txt files
309	into the CSS, details, header, and footer configuration screens
310	under the Admin/Skins menu.
311

	---------
312
313	## See Also
314
315	* [Customizing the Timeline Graph](customgraph.md)
316
317	DDED www/defcsp.md

M www/defcsp.md

+27

		--- a/www/defcsp.md
		+++ b/www/defcsp.md
		@@ -0,0 +1,27 @@
	1	+javas=` attribute the
	2	+matches the %s section of the CSP. Fossil provides
	3	+normally includes a [ute the
	4	+matches the %s ][csp] (CSP)
	5	+in , CSS,
	6	+from where the
	7	+content may be sourced.
	8	+
	9	+CSP is a security measure designed to prevent
	10	+(XSS) and other similar code injection attacks.
	11	+The CSP defines a “white list” of content types and origins that
	12	+are considered safe. Any references to resources that are not
	13	+on the white list are ignored.
	14	+
	15	+If Fossil were perfect and bug-free and never allowed any kind of
	16	+code injection on the pages it generates, then the CSP would not
	17	+be useful. The Fossil developers are not aware of any defects
	18	+in Fossil that allow code injection, and will promptly fix any defects
	19	+that are brought to their attention. Lots of eyeballs are looking at
	20	+Fossil to find problems in the code, and the Fossil build process uses
	21	+custom static analysis techniques to help identify code injection problems
	22	+at compile-time. Nevertheless, problems do sometimes (rarely) slip
	23	+through. The CSP serves as a final line of defense, preventing
	24	+code injection defects in Fossil from turning into actual
	25	+vulnerabilities the %s section of the CSP. Fossil provides a different
	26	+random nonce for every page it generates, and since an attacker has
	27	+no way of predicting what that nonce w

	--- a/www/defcsp.md
	+++ b/www/defcsp.md
	@@ -0,0 +1,27 @@

	--- a/www/defcsp.md
	+++ b/www/defcsp.md
	@@ -0,0 +1,27 @@
1	javas=` attribute the
2	matches the %s section of the CSP. Fossil provides
3	normally includes a [ute the
4	matches the %s ][csp] (CSP)
5	in , CSS,
6	from where the
7	content may be sourced.
8
9	CSP is a security measure designed to prevent
10	(XSS) and other similar code injection attacks.
11	The CSP defines a “white list” of content types and origins that
12	are considered safe. Any references to resources that are not
13	on the white list are ignored.
14
15	If Fossil were perfect and bug-free and never allowed any kind of
16	code injection on the pages it generates, then the CSP would not
17	be useful. The Fossil developers are not aware of any defects
18	in Fossil that allow code injection, and will promptly fix any defects
19	that are brought to their attention. Lots of eyeballs are looking at
20	Fossil to find problems in the code, and the Fossil build process uses
21	custom static analysis techniques to help identify code injection problems
22	at compile-time. Nevertheless, problems do sometimes (rarely) slip
23	through. The CSP serves as a final line of defense, preventing
24	code injection defects in Fossil from turning into actual
25	vulnerabilities the %s section of the CSP. Fossil provides a different
26	random nonce for every page it generates, and since an attacker has
27	no way of predicting what that nonce w

M www/embeddeddoc.wiki

+48 -3

		--- www/embeddeddoc.wiki
		+++ www/embeddeddoc.wiki
		@@ -80,11 +80,11 @@
80	80	Wiki, markdown, and plain text documentation files
81	81	are rendered with the standard fossil header and footer added.
82	82	Most other mimetypes are delivered directly to the requesting
83	83	web browser without interpretation, additions, or changes.
84	84
85		-Files with the mimetype "text/html" (the .html or .htm suffix) are
	85	+<a name="html"></a>Files with the mimetype "text/html" (the .html or .htm suffix) are
86	86	usually rendered directly to the browser without interpretation.
87	87	However, if the file begins with a <div> element like this:
88	88
89	89	<b><div class='fossil-doc' data-title='<i>Title Text</i>'></b>
90	90
		@@ -93,10 +93,55 @@
93	93	required for this to occur. The "data-title='...'" attribute is
94	94	optional, but if it is present the text will become the title displayed
95	95	in the Fossil header. An example of this can be seen in the text
96	96	of the [/artifact/84b4b3d041d93a?txt=1 \| Index Of Fossil Documentation]
97	97	document.
	98	+
	99	+Beware that such HTML files render in the same browser security context
	100	+as all other embedded documentation served from Fossil; they are not
	101	+fully-independent web pages. One practical consequence of this is that
	102	+embedded <tt><script></tt> tags will cause a
	103	+[https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP \| Content
	104	+Security Policy] error in your browser with the default CSP as served by
	105	+Fossil. See the documentation on [./customskin.md#headfoot \| Header and
	106	+Footer Processing] and [./defcsp.md \| The Default CSP].
	107	+
	108	+
	109	+<h2>Server-Side Text Substitution</h2>
	110	+
	111	+Fossil can do a few types of substitution of server-side information
	112	+into the embedded document.
	113	+
	114	+<h3>1. $ROOT</h3>
	115	+
	116	+To allow for repositories [./server/ \| served deeper than the root of the
	117	+URL hierarchy], Fossil can substitute the repository's root in the URL
	118	+scheme into HTML <tt>href</tt> and <tt>action</tt> attributes. For
	119	+example:
	120	+
	121	+<nowiki><pre>
	122	+ [$ROOT/doc.wiki \| doc at project root]
	123	+</pre></nowiki>
	124	+
	125	+might become this in the rendered HTML:
	126	+
	127	+<nowiki><pre>
	128	+ <a href="/project/root/doc.wiki">doc at project root</a>
	129	+</pre></nowiki>
	130	+
	131	+As you can see, this happens for all source document types that end up
	132	+rendering as HTML, not just source documents in the HTML
	133	+<tt>fossil-doc</tt> format described at the end of the prior section.
	134	+
	135	+
	136	+<h3 id="th1">2. TH1 Documents</h3>
	137	+
	138	+Fossil will substitute the value of [./th1.md \| TH1 expressions] within
	139	+<tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have
	140	+configured it with the <tt>--with-th1-docs</tt> option, which is
	141	+disabled by default.
	142	+
98	143
99	144	<h2>Examples</h2>
100	145
101	146	This file that you are currently reading is an example of
102	147	embedded documentation. The name of this file in the fossil
		@@ -117,12 +162,12 @@
117	162	<blockquote><pre>
118	163	#!/usr/bin/fossil
119	164	repository: /fossil/fossil.fossil
120	165	</pre></blockquote>
121	166
122		-This is one of four ways to set up a
123		-<a href="./server.wiki">fossil web server</a>.
	167	+This is one of the many ways to set up a
	168	+<a href="./server/">Fossil server</a>.
124	169
125	170	The "<b>/trunk/</b>" part of the URL tells fossil to use
126	171	the documentation files from the most recent trunk check-in.
127	172	If you wanted to see an historical version of this document,
128	173	you could substitute the name of a check-in for "<b>/trunk/</b>".
129	174

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -80,11 +80,11 @@
80	Wiki, markdown, and plain text documentation files
81	are rendered with the standard fossil header and footer added.
82	Most other mimetypes are delivered directly to the requesting
83	web browser without interpretation, additions, or changes.
84
85	Files with the mimetype "text/html" (the .html or .htm suffix) are
86	usually rendered directly to the browser without interpretation.
87	However, if the file begins with a <div> element like this:
88
89	<b><div class='fossil-doc' data-title='<i>Title Text</i>'></b>
90
	@@ -93,10 +93,55 @@
93	required for this to occur. The "data-title='...'" attribute is
94	optional, but if it is present the text will become the title displayed
95	in the Fossil header. An example of this can be seen in the text
96	of the [/artifact/84b4b3d041d93a?txt=1 \| Index Of Fossil Documentation]
97	document.













































98
99	<h2>Examples</h2>
100
101	This file that you are currently reading is an example of
102	embedded documentation. The name of this file in the fossil
	@@ -117,12 +162,12 @@
117	<blockquote><pre>
118	#!/usr/bin/fossil
119	repository: /fossil/fossil.fossil
120	</pre></blockquote>
121
122	This is one of four ways to set up a
123	<a href="./server.wiki">fossil web server</a>.
124
125	The "<b>/trunk/</b>" part of the URL tells fossil to use
126	the documentation files from the most recent trunk check-in.
127	If you wanted to see an historical version of this document,
128	you could substitute the name of a check-in for "<b>/trunk/</b>".
129

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -80,11 +80,11 @@
80	Wiki, markdown, and plain text documentation files
81	are rendered with the standard fossil header and footer added.
82	Most other mimetypes are delivered directly to the requesting
83	web browser without interpretation, additions, or changes.
84
85	<a name="html"></a>Files with the mimetype "text/html" (the .html or .htm suffix) are
86	usually rendered directly to the browser without interpretation.
87	However, if the file begins with a <div> element like this:
88
89	<b><div class='fossil-doc' data-title='<i>Title Text</i>'></b>
90
	@@ -93,10 +93,55 @@
93	required for this to occur. The "data-title='...'" attribute is
94	optional, but if it is present the text will become the title displayed
95	in the Fossil header. An example of this can be seen in the text
96	of the [/artifact/84b4b3d041d93a?txt=1 \| Index Of Fossil Documentation]
97	document.
98
99	Beware that such HTML files render in the same browser security context
100	as all other embedded documentation served from Fossil; they are not
101	fully-independent web pages. One practical consequence of this is that
102	embedded <tt><script></tt> tags will cause a
103	[https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP \| Content
104	Security Policy] error in your browser with the default CSP as served by
105	Fossil. See the documentation on [./customskin.md#headfoot \| Header and
106	Footer Processing] and [./defcsp.md \| The Default CSP].
107
108
109	<h2>Server-Side Text Substitution</h2>
110
111	Fossil can do a few types of substitution of server-side information
112	into the embedded document.
113
114	<h3>1. $ROOT</h3>
115
116	To allow for repositories [./server/ \| served deeper than the root of the
117	URL hierarchy], Fossil can substitute the repository's root in the URL
118	scheme into HTML <tt>href</tt> and <tt>action</tt> attributes. For
119	example:
120
121	<nowiki><pre>
122	[$ROOT/doc.wiki \| doc at project root]
123	</pre></nowiki>
124
125	might become this in the rendered HTML:
126
127	<nowiki><pre>
128	<a href="/project/root/doc.wiki">doc at project root</a>
129	</pre></nowiki>
130
131	As you can see, this happens for all source document types that end up
132	rendering as HTML, not just source documents in the HTML
133	<tt>fossil-doc</tt> format described at the end of the prior section.
134
135
136	<h3 id="th1">2. TH1 Documents</h3>
137
138	Fossil will substitute the value of [./th1.md \| TH1 expressions] within
139	<tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have
140	configured it with the <tt>--with-th1-docs</tt> option, which is
141	disabled by default.
142
143
144	<h2>Examples</h2>
145
146	This file that you are currently reading is an example of
147	embedded documentation. The name of this file in the fossil
	@@ -117,12 +162,12 @@
162	<blockquote><pre>
163	#!/usr/bin/fossil
164	repository: /fossil/fossil.fossil
165	</pre></blockquote>
166
167	This is one of the many ways to set up a
168	<a href="./server/">Fossil server</a>.
169
170	The "<b>/trunk/</b>" part of the URL tells fossil to use
171	the documentation files from the most recent trunk check-in.
172	If you wanted to see an historical version of this document,
173	you could substitute the name of a check-in for "<b>/trunk/</b>".
174

M www/env-opts.md

+36 -51

		--- www/env-opts.md
		+++ www/env-opts.md
		@@ -112,16 +112,25 @@
112	112
113	113
114	114	Environment Variables
115	115	---------------------
116	116
	117	+On most platforms, the location of the user’s account-wide `.fossil`
	118	+file is either `FOSSIL_HOME` or `HOME`, in that order. This ordering
	119	+lets you put this file somewhere other than at the top of your user’s
	120	+home directory by defining `FOSSIL_HOME` to mask the always-defined
	121	+`HOME`.
117	122
118		-`APPDATA`: (Windows) Location of the `~/.fossil` file. The first
119		-environment variable found in the environment from the list
120		-`FOSSIL_HOME`, `LOCALAPPDATA` (Windows), `APPDATA` (Windows),
121		-`HOMEDRIVE` and `HOMEPATH` (Windows, used together), and `HOME` is
122		-used as the location of the `~/.fossil` file.
	123	+For native Windows builds and for Cygwin builds, the file is called
	124	+`_fossil` instead to avoid problems with old programs that assume file
	125	+names cannot begin with a dot, as was true in old versions of Windows
	126	+and in MS-DOS. (Newer Microsoft OSes and file systems don’t have a
	127	+problem with such files, but still we take the safe path in case you’re
	128	+on a system with software that can’t cope.) We start our search with
	129	+`FOSSIL_HOME` again, but instead of falling back to `HOME`, we instead
	130	+try `USERPROFILE`, then `LOCALAPPDATA`, then `APPDATA`, and finally we
	131	+concatenate `HOMEDRIVE` + `HOMEPATH`.
123	132
124	133	`EDITOR`: Name the editor to use for check-in and stash comments.
125	134	Overridden by the local or global `editor` setting or the `VISUAL`
126	135	environment variable.
127	136
		@@ -175,25 +184,15 @@
175	184
176	185	`FOSSIL_TCL_PATH`: When Tcl stubs support is configured, point to a
177	186	specific file or folder containing the version of Tcl to load at run
178	187	time.
179	188
180		-`FOSSIL_TEMP`: Fallback location of the temporary directories and files
181		-created and deleted when running the test suite. The first environment
182		-variable found in the environment from the list `FOSSIL_TEST_TEMP`,
183		-`FOSSIL_TEMP`, `TEMP`, and `TMP` is used.
184		-
185	189	`FOSSIL_TEST_DANGEROUS_IGNORE_OPEN_CHECKOUT`: When set to the literal
186	190	value `YES_DO_IT`, the test suite will relax the constraint that some
187	191	tests may not run within an open checkout. This is subject to removal
188	192	in the future.
189	193
190		-`FOSSIL_TEST_TEMP`: Primary location of the temporary directories
191		-and files created and deleted when running the test suite. The
192		-first environment variable found in the environment from the list
193		-`FOSSIL_TEST_TEMP`, `FOSSIL_TEMP`, `TEMP`, and `TMP` is used.
194		-
195	194	`FOSSIL_VFS`: Name a VFS to load into SQLite.
196	195
197	196	`GATEWAY_INTERFACE`: If present and the `--nocgi` option is not, assume
198	197	fossil is invoked from a web server as a CGI command, and act
199	198	accordingly.
		@@ -259,16 +258,10 @@
259	258
260	259
261	260	`SYSTEMROOT`: (Windows) Used to locate `notepad.exe` as a
262	261	fall back comment editor.
263	262
264		-`TEMP`: On Windows, the location of temporary files. The first
265		-environment variable found in the environment that names an existing
266		-directory from the list `TMP`, `TEMP`, `USERPROFILE`, the Windows
267		-directory (usually `C:\WINDOWS`), `TEMP`, `TMP`, and the current
268		-directory (aka `.`) is the temporary folder.
269		-
270	263	`TERM`: If the linenoise library is used (almost certainly not on
271	264	Windows), it will check `TERM` to verify that the interactive terminal
272	265	is not named on a short list on terminals known to not work with
273	266	linenoise. Linenoise is a library that provides command history and
274	267	command line editing to interactive programs, and can be used in the
		@@ -296,16 +289,10 @@
296	289
297	290	`TH1_TEST_USER_CAPS`: Override the default user permissions used when
298	291	processing the `--set-user-caps` option for the `test-th-eval`,
299	292	`test-th-render`, and `test-th-source` test commands.
300	293
301		-`TMP`: On Windows, the location of temporary files. The first
302		-environment variable found in the environment that names an existing
303		-directory from the list `TMP`, `TEMP`, `USERPROFILE`, the Windows
304		-directory (usually `C:\WINDOWS`), `TEMP`, `TMP`, and the current
305		-directory (aka `.`) is the temporary folder.
306		-
307	294	`TMPDIR`: Names the temporary file location for SQLite.
308	295
309	296
310	297	`USER`: Name of the logged in user on many Unix-like platforms.
311	298	Used as the fossil user name if `FOSSIL_USER` is not specified. See
		@@ -313,16 +300,10 @@
313	300
314	301	`USERNAME`: Name of the logged in user on Windows platforms.
315	302	Used as the fossil user name if `FOSSIL_USER` is not specified. See
316	303	the discussion of Fossil Username below for a lot more detail.
317	304
318		-`USERPROFILE`: On Windows, the location of temporary files. The first
319		-environment variable found in the environment that names an existing
320		-directory from the list `TMP`, `TEMP`, `USERPROFILE`, the Windows
321		-directory (usually `C:\WINDOWS`), `TEMP`, `TMP`, and the current
322		-directory (aka `.`) is the temporary folder.
323		-
324	305	`VISUAL`: Name the editor to use for check-in and stash comments.
325	306	Overrides the `EDITOR` environment variable. Overridden by the local
326	307	or global `editor` setting.
327	308
328	309
		@@ -451,32 +432,36 @@
451	432	can be selected with either the `--vfs VFSNAME` option or the
452	433	`FOSSIL_VFS` environment variable. The `--vfs` option takes
453	434	precedence.
454	435
455	436
456		-### Temporary File Location
	437	+### <a name="temp"></a>Temporary File Location
457	438
458		-Fossil places some temporary files in the current directory, notably
	439	+Fossil places some temporary files in the checkout directory. Most notably,
459	440	supporting files related to merge conflicts are placed in the same
460	441	folder as the merge result.
461	442
462		-Other temporary files need a home. On Unix-like systems, the first
463		-folder from the hard coded list `/var/tmp`, `/usr/tmp`, `/tmp`,
464		-`/temp`, and `.` that is found to exist in the file system is used by
465		-fossil. The SQLite library has its own code for finding a safe place for
466		-temporary files. It checks the environment variables `SQLITE_TMPDIR`
467		-and `TMPDIR` ahead of the hard coded list `/var/tmp`, `/usr/tmp`,
468		-`/tmp`, and `.` for the first directory that exists.
469		-
470		-On Windows, fossil calls [`GetTempPath`][gtp], and also queries the
471		-environment variables `TEMP`, and `TMP`. If none of those three places
472		-exist, then it uses `.`. Notice that `GetTempPath` itself used `TMP`,
473		-`TEMP`, `USERPROFILE`, and the Windows folder (named in the variable
474		-`SystemRoot`). Since the Windows folder always exists, but in modern
475		-versions of Windows is generally not writable by the logged in user,
476		-not having `TEMP`, `TMP`, or `USERPROFILE` set is almost guaranteed to
477		-cause trouble.
	443	+Other temporary files need a different home. The rules for choosing one are
	444	+complicated.
	445	+
	446	+Fossil-specific code uses `FOSSIL_TEMP`, `TEMP`, and `TMP`, in that
	447	+order. Fossil’s own test suite prepends `FOSSIL_TEST_TEMP` to that list.
	448	+
	449	+The underlying SQLite code uses several different path sets for its temp
	450	+files, depending on the platform type.
	451	+
	452	+On Unix-like platforms, excepting Cygwin, SQLite first checks the
	453	+environment variables `SQLITE_TMPDIR` and `TMPDIR`, in that order. If
	454	+neither is defined, it falls back to a hard-coded list of paths:
	455	+`/var/tmp`, `/usr/tmp`, and `/tmp`. If all of that fails, it uses the
	456	+current working directory.
	457	+
	458	+For Cygwin builds, SQLite instead uses the first defined variable in
	459	+this list: `SQLITE_TMPDIR`, `TMPDIR`, `TMP`, `TEMP`, and `USERPROFILE`.
	460	+
	461	+For native Windows builds, SQLite simply calls the OS’s [`GetTempPath()`
	462	+API][gtp]. See that reference page for details.
478	463
479	464	[gtp]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx
480	465
481	466
482	467
483	468

	--- www/env-opts.md
	+++ www/env-opts.md
	@@ -112,16 +112,25 @@
112
113
114	Environment Variables
115	---------------------
116





117
118	`APPDATA`: (Windows) Location of the `~/.fossil` file. The first
119	environment variable found in the environment from the list
120	`FOSSIL_HOME`, `LOCALAPPDATA` (Windows), `APPDATA` (Windows),
121	`HOMEDRIVE` and `HOMEPATH` (Windows, used together), and `HOME` is
122	used as the location of the `~/.fossil` file.




123
124	`EDITOR`: Name the editor to use for check-in and stash comments.
125	Overridden by the local or global `editor` setting or the `VISUAL`
126	environment variable.
127
	@@ -175,25 +184,15 @@
175
176	`FOSSIL_TCL_PATH`: When Tcl stubs support is configured, point to a
177	specific file or folder containing the version of Tcl to load at run
178	time.
179
180	`FOSSIL_TEMP`: Fallback location of the temporary directories and files
181	created and deleted when running the test suite. The first environment
182	variable found in the environment from the list `FOSSIL_TEST_TEMP`,
183	`FOSSIL_TEMP`, `TEMP`, and `TMP` is used.
184
185	`FOSSIL_TEST_DANGEROUS_IGNORE_OPEN_CHECKOUT`: When set to the literal
186	value `YES_DO_IT`, the test suite will relax the constraint that some
187	tests may not run within an open checkout. This is subject to removal
188	in the future.
189
190	`FOSSIL_TEST_TEMP`: Primary location of the temporary directories
191	and files created and deleted when running the test suite. The
192	first environment variable found in the environment from the list
193	`FOSSIL_TEST_TEMP`, `FOSSIL_TEMP`, `TEMP`, and `TMP` is used.
194
195	`FOSSIL_VFS`: Name a VFS to load into SQLite.
196
197	`GATEWAY_INTERFACE`: If present and the `--nocgi` option is not, assume
198	fossil is invoked from a web server as a CGI command, and act
199	accordingly.
	@@ -259,16 +258,10 @@
259
260
261	`SYSTEMROOT`: (Windows) Used to locate `notepad.exe` as a
262	fall back comment editor.
263
264	`TEMP`: On Windows, the location of temporary files. The first
265	environment variable found in the environment that names an existing
266	directory from the list `TMP`, `TEMP`, `USERPROFILE`, the Windows
267	directory (usually `C:\WINDOWS`), `TEMP`, `TMP`, and the current
268	directory (aka `.`) is the temporary folder.
269
270	`TERM`: If the linenoise library is used (almost certainly not on
271	Windows), it will check `TERM` to verify that the interactive terminal
272	is not named on a short list on terminals known to not work with
273	linenoise. Linenoise is a library that provides command history and
274	command line editing to interactive programs, and can be used in the
	@@ -296,16 +289,10 @@
296
297	`TH1_TEST_USER_CAPS`: Override the default user permissions used when
298	processing the `--set-user-caps` option for the `test-th-eval`,
299	`test-th-render`, and `test-th-source` test commands.
300
301	`TMP`: On Windows, the location of temporary files. The first
302	environment variable found in the environment that names an existing
303	directory from the list `TMP`, `TEMP`, `USERPROFILE`, the Windows
304	directory (usually `C:\WINDOWS`), `TEMP`, `TMP`, and the current
305	directory (aka `.`) is the temporary folder.
306
307	`TMPDIR`: Names the temporary file location for SQLite.
308
309
310	`USER`: Name of the logged in user on many Unix-like platforms.
311	Used as the fossil user name if `FOSSIL_USER` is not specified. See
	@@ -313,16 +300,10 @@
313
314	`USERNAME`: Name of the logged in user on Windows platforms.
315	Used as the fossil user name if `FOSSIL_USER` is not specified. See
316	the discussion of Fossil Username below for a lot more detail.
317
318	`USERPROFILE`: On Windows, the location of temporary files. The first
319	environment variable found in the environment that names an existing
320	directory from the list `TMP`, `TEMP`, `USERPROFILE`, the Windows
321	directory (usually `C:\WINDOWS`), `TEMP`, `TMP`, and the current
322	directory (aka `.`) is the temporary folder.
323
324	`VISUAL`: Name the editor to use for check-in and stash comments.
325	Overrides the `EDITOR` environment variable. Overridden by the local
326	or global `editor` setting.
327
328
	@@ -451,32 +432,36 @@
451	can be selected with either the `--vfs VFSNAME` option or the
452	`FOSSIL_VFS` environment variable. The `--vfs` option takes
453	precedence.
454
455
456	### Temporary File Location
457
458	Fossil places some temporary files in the current directory, notably
459	supporting files related to merge conflicts are placed in the same
460	folder as the merge result.
461
462	Other temporary files need a home. On Unix-like systems, the first
463	folder from the hard coded list `/var/tmp`, `/usr/tmp`, `/tmp`,
464	`/temp`, and `.` that is found to exist in the file system is used by
465	fossil. The SQLite library has its own code for finding a safe place for
466	temporary files. It checks the environment variables `SQLITE_TMPDIR`
467	and `TMPDIR` ahead of the hard coded list `/var/tmp`, `/usr/tmp`,
468	`/tmp`, and `.` for the first directory that exists.
469
470	On Windows, fossil calls [`GetTempPath`][gtp], and also queries the
471	environment variables `TEMP`, and `TMP`. If none of those three places
472	exist, then it uses `.`. Notice that `GetTempPath` itself used `TMP`,
473	`TEMP`, `USERPROFILE`, and the Windows folder (named in the variable
474	`SystemRoot`). Since the Windows folder always exists, but in modern
475	versions of Windows is generally not writable by the logged in user,
476	not having `TEMP`, `TMP`, or `USERPROFILE` set is almost guaranteed to
477	cause trouble.




478
479	[gtp]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx
480
481
482
483

	--- www/env-opts.md
	+++ www/env-opts.md
	@@ -112,16 +112,25 @@
112
113
114	Environment Variables
115	---------------------
116
117	On most platforms, the location of the user’s account-wide `.fossil`
118	file is either `FOSSIL_HOME` or `HOME`, in that order. This ordering
119	lets you put this file somewhere other than at the top of your user’s
120	home directory by defining `FOSSIL_HOME` to mask the always-defined
121	`HOME`.
122
123	For native Windows builds and for Cygwin builds, the file is called
124	`_fossil` instead to avoid problems with old programs that assume file
125	names cannot begin with a dot, as was true in old versions of Windows
126	and in MS-DOS. (Newer Microsoft OSes and file systems don’t have a
127	problem with such files, but still we take the safe path in case you’re
128	on a system with software that can’t cope.) We start our search with
129	`FOSSIL_HOME` again, but instead of falling back to `HOME`, we instead
130	try `USERPROFILE`, then `LOCALAPPDATA`, then `APPDATA`, and finally we
131	concatenate `HOMEDRIVE` + `HOMEPATH`.
132
133	`EDITOR`: Name the editor to use for check-in and stash comments.
134	Overridden by the local or global `editor` setting or the `VISUAL`
135	environment variable.
136
	@@ -175,25 +184,15 @@
184
185	`FOSSIL_TCL_PATH`: When Tcl stubs support is configured, point to a
186	specific file or folder containing the version of Tcl to load at run
187	time.
188





189	`FOSSIL_TEST_DANGEROUS_IGNORE_OPEN_CHECKOUT`: When set to the literal
190	value `YES_DO_IT`, the test suite will relax the constraint that some
191	tests may not run within an open checkout. This is subject to removal
192	in the future.
193





194	`FOSSIL_VFS`: Name a VFS to load into SQLite.
195
196	`GATEWAY_INTERFACE`: If present and the `--nocgi` option is not, assume
197	fossil is invoked from a web server as a CGI command, and act
198	accordingly.
	@@ -259,16 +258,10 @@
258
259
260	`SYSTEMROOT`: (Windows) Used to locate `notepad.exe` as a
261	fall back comment editor.
262






263	`TERM`: If the linenoise library is used (almost certainly not on
264	Windows), it will check `TERM` to verify that the interactive terminal
265	is not named on a short list on terminals known to not work with
266	linenoise. Linenoise is a library that provides command history and
267	command line editing to interactive programs, and can be used in the
	@@ -296,16 +289,10 @@
289
290	`TH1_TEST_USER_CAPS`: Override the default user permissions used when
291	processing the `--set-user-caps` option for the `test-th-eval`,
292	`test-th-render`, and `test-th-source` test commands.
293






294	`TMPDIR`: Names the temporary file location for SQLite.
295
296
297	`USER`: Name of the logged in user on many Unix-like platforms.
298	Used as the fossil user name if `FOSSIL_USER` is not specified. See
	@@ -313,16 +300,10 @@
300
301	`USERNAME`: Name of the logged in user on Windows platforms.
302	Used as the fossil user name if `FOSSIL_USER` is not specified. See
303	the discussion of Fossil Username below for a lot more detail.
304






305	`VISUAL`: Name the editor to use for check-in and stash comments.
306	Overrides the `EDITOR` environment variable. Overridden by the local
307	or global `editor` setting.
308
309
	@@ -451,32 +432,36 @@
432	can be selected with either the `--vfs VFSNAME` option or the
433	`FOSSIL_VFS` environment variable. The `--vfs` option takes
434	precedence.
435
436
437	### <a name="temp"></a>Temporary File Location
438
439	Fossil places some temporary files in the checkout directory. Most notably,
440	supporting files related to merge conflicts are placed in the same
441	folder as the merge result.
442
443	Other temporary files need a different home. The rules for choosing one are
444	complicated.
445
446	Fossil-specific code uses `FOSSIL_TEMP`, `TEMP`, and `TMP`, in that
447	order. Fossil’s own test suite prepends `FOSSIL_TEST_TEMP` to that list.
448
449	The underlying SQLite code uses several different path sets for its temp
450	files, depending on the platform type.
451
452	On Unix-like platforms, excepting Cygwin, SQLite first checks the
453	environment variables `SQLITE_TMPDIR` and `TMPDIR`, in that order. If
454	neither is defined, it falls back to a hard-coded list of paths:
455	`/var/tmp`, `/usr/tmp`, and `/tmp`. If all of that fails, it uses the
456	current working directory.
457
458	For Cygwin builds, SQLite instead uses the first defined variable in
459	this list: `SQLITE_TMPDIR`, `TMPDIR`, `TMP`, `TEMP`, and `USERPROFILE`.
460
461	For native Windows builds, SQLite simply calls the OS’s [`GetTempPath()`
462	API][gtp]. See that reference page for details.
463
464	[gtp]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx
465
466
467
468

M www/event.wiki

+1 -1

		--- www/event.wiki
		+++ www/event.wiki
		@@ -33,11 +33,11 @@
33	33	various process steps. For example, a technote can be used to record
34	34	the successful completion of a long-running test, perhaps with
35	35	performance results and details of where the test was run and who
36	36	ran it recorded in the wiki content.
37	37
38		- * <b>News Articles</b>. Significant occurrences in the lifecycle of
	38	+ * <b>News Articles</b>. Significant occurrences in the life cycle of
39	39	a project can be recorded as news articles using technotes. Perhaps the
40	40	domain name of the canonical website for a project changes, or new
41	41	server hardware is obtained. Such happenings are appropriate for
42	42	reporting as news.
43	43
44	44

	--- www/event.wiki
	+++ www/event.wiki
	@@ -33,11 +33,11 @@
33	various process steps. For example, a technote can be used to record
34	the successful completion of a long-running test, perhaps with
35	performance results and details of where the test was run and who
36	ran it recorded in the wiki content.
37
38	* <b>News Articles</b>. Significant occurrences in the lifecycle of
39	a project can be recorded as news articles using technotes. Perhaps the
40	domain name of the canonical website for a project changes, or new
41	server hardware is obtained. Such happenings are appropriate for
42	reporting as news.
43
44

	--- www/event.wiki
	+++ www/event.wiki
	@@ -33,11 +33,11 @@
33	various process steps. For example, a technote can be used to record
34	the successful completion of a long-running test, perhaps with
35	performance results and details of where the test was run and who
36	ran it recorded in the wiki content.
37
38	* <b>News Articles</b>. Significant occurrences in the life cycle of
39	a project can be recorded as news articles using technotes. Perhaps the
40	domain name of the canonical website for a project changes, or new
41	server hardware is obtained. Such happenings are appropriate for
42	reporting as news.
43
44

M www/forum.wiki

+1 -1

		--- www/forum.wiki
		+++ www/forum.wiki
		@@ -59,11 +59,11 @@
59	59	* <b>Contribute Off-Line:</b> Fossil forum posts work like any other
60	60	insertion into the repository, so a user can create new threads and
61	61	reply to existing ones while off-line, then sync their
62	62	contributions to the server they cloned from when back on-line.
63	63	Yes, you can post to the forum from inside a tent, miles from the
64		- nearest wifi router or cellular data tower.
	64	+ nearest WiFi router or cellular data tower.
65	65
66	66	* <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum
67	67	posts are normal Fossil artifacts, you can interlink them with
68	68	other Fossil artifacts using short internal links: link to forum
69	69	threads from a [./tickets.wiki \| ticket], link to a wiki document
70	70

	--- www/forum.wiki
	+++ www/forum.wiki
	@@ -59,11 +59,11 @@
59	* <b>Contribute Off-Line:</b> Fossil forum posts work like any other
60	insertion into the repository, so a user can create new threads and
61	reply to existing ones while off-line, then sync their
62	contributions to the server they cloned from when back on-line.
63	Yes, you can post to the forum from inside a tent, miles from the
64	nearest wifi router or cellular data tower.
65
66	* <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum
67	posts are normal Fossil artifacts, you can interlink them with
68	other Fossil artifacts using short internal links: link to forum
69	threads from a [./tickets.wiki \| ticket], link to a wiki document
70

	--- www/forum.wiki
	+++ www/forum.wiki
	@@ -59,11 +59,11 @@
59	* <b>Contribute Off-Line:</b> Fossil forum posts work like any other
60	insertion into the repository, so a user can create new threads and
61	reply to existing ones while off-line, then sync their
62	contributions to the server they cloned from when back on-line.
63	Yes, you can post to the forum from inside a tent, miles from the
64	nearest WiFi router or cellular data tower.
65
66	* <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum
67	posts are normal Fossil artifacts, you can interlink them with
68	other Fossil artifacts using short internal links: link to forum
69	threads from a [./tickets.wiki \| ticket], link to a wiki document
70

M www/fossil-v-git.wiki

+16 -13

		--- www/fossil-v-git.wiki
		+++ www/fossil-v-git.wiki
		@@ -8,11 +8,11 @@
8	8	version control systems] which store a tree of check-in objects to a
9	9	local repository clone. In both systems, the local clone starts out as a
10	10	full copy of the remote parent. New content gets added to the local
11	11	clone and then later optionally pushed up to the remote, and changes to
12	12	the remote can be pulled down to the local clone at will. Both systems
13		-offer diffing, patching, branching, merging, cherrypicking, bisecting,
	13	+offer diffing, patching, branching, merging, cherry-picking, bisecting,
14	14	private branches, a stash, etc.
15	15
16	16	Fossil has inbound and outbound Git conversion features, so if you start
17	17	out using one DVCS and later decide you like the other better, you can
18	18	easily [./inout.wiki \| move your version-controlled file content].¹
		@@ -75,11 +75,11 @@
75	75	the design. One way to describe Fossil is that it is
76	76	"[https://github.com/ \| GitHub]-in-a-box."
77	77
78	78	For developers who choose to self-host projects (rather than using a
79	79	3rd-party service such as GitHub) Fossil is much easier to set up, since
80		-the stand-alone Fossil executable together with a [./server.wiki#cgi\|2-line CGI script]
	80	+the stand-alone Fossil executable together with a [./server/any/cgi.md\|2-line CGI script]
81	81	suffice to instantiate a full-featured developer website. To accomplish
82	82	the same using Git requires locating, installing, configuring, integrating,
83	83	and managing a wide assortment of separate tools. Standing up a developer
84	84	website using Fossil can be done in minutes, whereas doing the same using
85	85	Git requires hours or days.
		@@ -234,14 +234,14 @@
234	234	an expressive, declarative language, it has an outsized contribution to
235	235	Fossil's user-visible functionality.
236	236
237	237	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
238	238	necessary.⁵ The server-side
239		-UI scripting usse a custom minimal
	239	+UI scripting uses a custom minimal
240	240	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
241	241	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
242		-embedeed into Fossil itself. Fossil's build system and test suite are
	242	+embedded into Fossil itself. Fossil's build system and test suite are
243	243	largely based on Tcl.⁶ All of this is quite portable.
244	244
245	245	About half of Git's code is POSIX C, and about a third is POSIX shell
246	246	code. This is largely why the so-called "Git for Windows" distributions
247	247	(both [https://git-scm.com/download/win\|first-party] and
		@@ -298,11 +298,11 @@
298	298
299	299	Git promotes the Linux kernel's bazaar development style, in which a
300	300	loosely-associated mass of developers contribute their work through
301	301	[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|a
302	302	hierarchy of lieutenants] who manage and clean up these contributions
303		-for consideration by Linus Torvalds, who has the power to cherrypick
	303	+for consideration by Linus Torvalds, who has the power to cherry-pick
304	304	individual contributions into his version of the Linux kernel. Git
305	305	allows an anonymous developer to rebase and push specific locally-named
306	306	private branches, so that a Git repo clone often isn't really a clone at
307	307	all: it may have an arbitrary number of differences relative to the
308	308	repository it originally cloned from. Git encourages siloed development.
		@@ -320,11 +320,11 @@
320	320	<li><p><b>Personal engagement:</b> SQLite's developers know each
321	321	other by name and work together daily on the project.</p></li>
322	322
323	323	<li><p><b>Trust over hierarchy:</b> SQLite's developers check
324	324	changes into their local repository, and these are immediately and
325		- automatically sync'd up to the central repository; there is no
	325	+ automatically synchronized up to the central repository; there is no
326	326	"[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|dictator
327	327	and lieutenants]" hierarchy as with Linux kernel contributions. D.
328	328	Richard Hipp rarely overrides decisions made by those he has trusted
329	329	with commit access on his repositories. Fossil allows you to give
330	330	[/doc/trunk/www/admin-v-setup.md\|some users] more power over what
		@@ -470,11 +470,11 @@
470	470	get paid more by mastering arcane features of my DVCS?" Unless you have
471	471	a good answer to that, you probably do not want to be choosing a DVCS
472	472	based on how many arcane features it has.
473	473
474	474	The argument is similar for other types of users: if you are a hobbyist,
475		-how much time do you want to spend mastering your DVCSs instead of on
	475	+how much time do you want to spend mastering your DVCS instead of on
476	476	the hobby supported by use of that DVCS?
477	477
478	478	There is some minimal set of features required to achieve the purposes
479	479	that drive our selection of a DVCS, but there is a level beyond which
480	480	more features only slow us down while we're learning the tool, since we
		@@ -526,11 +526,11 @@
526	526	<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
527	527
528	528	A "repository" in Git is a pile-of-files in the <tt>.git</tt>
529	529	subdirectory of a single check-out. The working check-out directory and
530	530	the <tt>.git</tt> repository subdirectory are normally in the same
531		-directory within the filesystem.
	531	+directory within the file system.
532	532
533	533	With Fossil, a "repository" is a single SQLite database file that can be
534	534	stored anywhere. There can be multiple active check-outs from the same
535	535	repository, perhaps open on different branches or on different snapshots
536	536	of the same branch. It is common in Fossil to switch branches with a
		@@ -603,14 +603,17 @@
603	603	[https://en.wikipedia.org/wiki/SHA-3\|256-bit SHA-3] with
604	604	[./hashpolicy.wiki\|full backwards compatibility] to old SHA-1 based
605	605	repositories.
606	606
607	607	Here in mid-2019, that feature is now in every OS and package repository
608		-known to include Fossil so that the next release as of this writing
609		-(Fossil 2.10) will default to enforcing SHA-3 hashes by default. This
	608	+known to include Fossil so that the next release
	609	+(Fossil 2.10) will begin using SHA-3 hashes even on repos currently
	610	+limited to SHA-1 for compatibility with Fossil 1.<i>x</i>,
	611	+effectively upgrading them to require Fossil 2.1 or newer. This
610	612	not only solves the SHAttered problem, it should prevent a reoccurrence
611		-for the foreseeable future. Only repositories created before the
	613	+for the foreseeable future. With the current release (Fossil 2.9) only
	614	+repositories created before the
612	615	transition to Fossil 2 are still using SHA-1, and then only if the
613	616	repository's maintainer chose not to switch them into SHA-3 mode some
614	617	time over the past 2 years.
615	618
616	619	Meanwhile, the Git community took until August 2018 to announce
		@@ -698,11 +701,11 @@
698	701	several parts, so that it is not strictly true that "everything" on
699	702	it is in the self-hosting Fossil project repo. The web forum is
700	703	hosted as [https://fossil-scm.org/forum/\|a separate Fossil repo]
701	704	from the [https://fossil-scm.org/fossil/\|main Fossil self-hosting
702	705	repo] for administration reasons, and the Download page content
703		- isn't normally sync'd with a "<tt>fossil clone</tt>" command unless
	706	+ isn't normally synchronized with a "<tt>fossil clone</tt>" command unless
704	707	you add the "-u" option. (See "[./aboutdownload.wiki\|How the
705	708	Download Page Works]" for details.) There may also be some purely
706	709	static elements of the web site served via D. Richard Hipp's own
707	710	lightweight web server,
708	711	<tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|althttpd]</tt>,
		@@ -718,11 +721,11 @@
718	721	<li><p>This means you can give up waiting for Fossil to be ported to
719	722	the PDP-11, but we remain hopeful that someone may eventually port
720	723	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
721	724
722	725	<li><p>We try to keep use of Javascript to a minimum in the web UI,
723		- and we always try to provide sensible fallbacks for those that run
	726	+ and we always try to provide sensible fall-backs for those that run
724	727	their browsers with Javascript disabled. Some features of the web UI
725	728	simply won't run without Javascript, but the UI behavior does
726	729	degrade gracefully.
727	730
728	731	<li><p>"Why is there all this Tcl in and around Fossil?" you may
729	732

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -8,11 +8,11 @@
8	version control systems] which store a tree of check-in objects to a
9	local repository clone. In both systems, the local clone starts out as a
10	full copy of the remote parent. New content gets added to the local
11	clone and then later optionally pushed up to the remote, and changes to
12	the remote can be pulled down to the local clone at will. Both systems
13	offer diffing, patching, branching, merging, cherrypicking, bisecting,
14	private branches, a stash, etc.
15
16	Fossil has inbound and outbound Git conversion features, so if you start
17	out using one DVCS and later decide you like the other better, you can
18	easily [./inout.wiki \| move your version-controlled file content].¹
	@@ -75,11 +75,11 @@
75	the design. One way to describe Fossil is that it is
76	"[https://github.com/ \| GitHub]-in-a-box."
77
78	For developers who choose to self-host projects (rather than using a
79	3rd-party service such as GitHub) Fossil is much easier to set up, since
80	the stand-alone Fossil executable together with a [./server.wiki#cgi\|2-line CGI script]
81	suffice to instantiate a full-featured developer website. To accomplish
82	the same using Git requires locating, installing, configuring, integrating,
83	and managing a wide assortment of separate tools. Standing up a developer
84	website using Fossil can be done in minutes, whereas doing the same using
85	Git requires hours or days.
	@@ -234,14 +234,14 @@
234	an expressive, declarative language, it has an outsized contribution to
235	Fossil's user-visible functionality.
236
237	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
238	necessary.⁵ The server-side
239	UI scripting usse a custom minimal
240	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
241	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
242	embedeed into Fossil itself. Fossil's build system and test suite are
243	largely based on Tcl.⁶ All of this is quite portable.
244
245	About half of Git's code is POSIX C, and about a third is POSIX shell
246	code. This is largely why the so-called "Git for Windows" distributions
247	(both [https://git-scm.com/download/win\|first-party] and
	@@ -298,11 +298,11 @@
298
299	Git promotes the Linux kernel's bazaar development style, in which a
300	loosely-associated mass of developers contribute their work through
301	[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|a
302	hierarchy of lieutenants] who manage and clean up these contributions
303	for consideration by Linus Torvalds, who has the power to cherrypick
304	individual contributions into his version of the Linux kernel. Git
305	allows an anonymous developer to rebase and push specific locally-named
306	private branches, so that a Git repo clone often isn't really a clone at
307	all: it may have an arbitrary number of differences relative to the
308	repository it originally cloned from. Git encourages siloed development.
	@@ -320,11 +320,11 @@
320	<li><p><b>Personal engagement:</b> SQLite's developers know each
321	other by name and work together daily on the project.</p></li>
322
323	<li><p><b>Trust over hierarchy:</b> SQLite's developers check
324	changes into their local repository, and these are immediately and
325	automatically sync'd up to the central repository; there is no
326	"[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|dictator
327	and lieutenants]" hierarchy as with Linux kernel contributions. D.
328	Richard Hipp rarely overrides decisions made by those he has trusted
329	with commit access on his repositories. Fossil allows you to give
330	[/doc/trunk/www/admin-v-setup.md\|some users] more power over what
	@@ -470,11 +470,11 @@
470	get paid more by mastering arcane features of my DVCS?" Unless you have
471	a good answer to that, you probably do not want to be choosing a DVCS
472	based on how many arcane features it has.
473
474	The argument is similar for other types of users: if you are a hobbyist,
475	how much time do you want to spend mastering your DVCSs instead of on
476	the hobby supported by use of that DVCS?
477
478	There is some minimal set of features required to achieve the purposes
479	that drive our selection of a DVCS, but there is a level beyond which
480	more features only slow us down while we're learning the tool, since we
	@@ -526,11 +526,11 @@
526	<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
527
528	A "repository" in Git is a pile-of-files in the <tt>.git</tt>
529	subdirectory of a single check-out. The working check-out directory and
530	the <tt>.git</tt> repository subdirectory are normally in the same
531	directory within the filesystem.
532
533	With Fossil, a "repository" is a single SQLite database file that can be
534	stored anywhere. There can be multiple active check-outs from the same
535	repository, perhaps open on different branches or on different snapshots
536	of the same branch. It is common in Fossil to switch branches with a
	@@ -603,14 +603,17 @@
603	[https://en.wikipedia.org/wiki/SHA-3\|256-bit SHA-3] with
604	[./hashpolicy.wiki\|full backwards compatibility] to old SHA-1 based
605	repositories.
606
607	Here in mid-2019, that feature is now in every OS and package repository
608	known to include Fossil so that the next release as of this writing
609	(Fossil 2.10) will default to enforcing SHA-3 hashes by default. This


610	not only solves the SHAttered problem, it should prevent a reoccurrence
611	for the foreseeable future. Only repositories created before the

612	transition to Fossil 2 are still using SHA-1, and then only if the
613	repository's maintainer chose not to switch them into SHA-3 mode some
614	time over the past 2 years.
615
616	Meanwhile, the Git community took until August 2018 to announce
	@@ -698,11 +701,11 @@
698	several parts, so that it is not strictly true that "everything" on
699	it is in the self-hosting Fossil project repo. The web forum is
700	hosted as [https://fossil-scm.org/forum/\|a separate Fossil repo]
701	from the [https://fossil-scm.org/fossil/\|main Fossil self-hosting
702	repo] for administration reasons, and the Download page content
703	isn't normally sync'd with a "<tt>fossil clone</tt>" command unless
704	you add the "-u" option. (See "[./aboutdownload.wiki\|How the
705	Download Page Works]" for details.) There may also be some purely
706	static elements of the web site served via D. Richard Hipp's own
707	lightweight web server,
708	<tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|althttpd]</tt>,
	@@ -718,11 +721,11 @@
718	<li><p>This means you can give up waiting for Fossil to be ported to
719	the PDP-11, but we remain hopeful that someone may eventually port
720	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
721
722	<li><p>We try to keep use of Javascript to a minimum in the web UI,
723	and we always try to provide sensible fallbacks for those that run
724	their browsers with Javascript disabled. Some features of the web UI
725	simply won't run without Javascript, but the UI behavior does
726	degrade gracefully.
727
728	<li><p>"Why is there all this Tcl in and around Fossil?" you may
729

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -8,11 +8,11 @@
8	version control systems] which store a tree of check-in objects to a
9	local repository clone. In both systems, the local clone starts out as a
10	full copy of the remote parent. New content gets added to the local
11	clone and then later optionally pushed up to the remote, and changes to
12	the remote can be pulled down to the local clone at will. Both systems
13	offer diffing, patching, branching, merging, cherry-picking, bisecting,
14	private branches, a stash, etc.
15
16	Fossil has inbound and outbound Git conversion features, so if you start
17	out using one DVCS and later decide you like the other better, you can
18	easily [./inout.wiki \| move your version-controlled file content].¹
	@@ -75,11 +75,11 @@
75	the design. One way to describe Fossil is that it is
76	"[https://github.com/ \| GitHub]-in-a-box."
77
78	For developers who choose to self-host projects (rather than using a
79	3rd-party service such as GitHub) Fossil is much easier to set up, since
80	the stand-alone Fossil executable together with a [./server/any/cgi.md\|2-line CGI script]
81	suffice to instantiate a full-featured developer website. To accomplish
82	the same using Git requires locating, installing, configuring, integrating,
83	and managing a wide assortment of separate tools. Standing up a developer
84	website using Fossil can be done in minutes, whereas doing the same using
85	Git requires hours or days.
	@@ -234,14 +234,14 @@
234	an expressive, declarative language, it has an outsized contribution to
235	Fossil's user-visible functionality.
236
237	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
238	necessary.⁵ The server-side
239	UI scripting uses a custom minimal
240	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
241	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
242	embedded into Fossil itself. Fossil's build system and test suite are
243	largely based on Tcl.⁶ All of this is quite portable.
244
245	About half of Git's code is POSIX C, and about a third is POSIX shell
246	code. This is largely why the so-called "Git for Windows" distributions
247	(both [https://git-scm.com/download/win\|first-party] and
	@@ -298,11 +298,11 @@
298
299	Git promotes the Linux kernel's bazaar development style, in which a
300	loosely-associated mass of developers contribute their work through
301	[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|a
302	hierarchy of lieutenants] who manage and clean up these contributions
303	for consideration by Linus Torvalds, who has the power to cherry-pick
304	individual contributions into his version of the Linux kernel. Git
305	allows an anonymous developer to rebase and push specific locally-named
306	private branches, so that a Git repo clone often isn't really a clone at
307	all: it may have an arbitrary number of differences relative to the
308	repository it originally cloned from. Git encourages siloed development.
	@@ -320,11 +320,11 @@
320	<li><p><b>Personal engagement:</b> SQLite's developers know each
321	other by name and work together daily on the project.</p></li>
322
323	<li><p><b>Trust over hierarchy:</b> SQLite's developers check
324	changes into their local repository, and these are immediately and
325	automatically synchronized up to the central repository; there is no
326	"[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|dictator
327	and lieutenants]" hierarchy as with Linux kernel contributions. D.
328	Richard Hipp rarely overrides decisions made by those he has trusted
329	with commit access on his repositories. Fossil allows you to give
330	[/doc/trunk/www/admin-v-setup.md\|some users] more power over what
	@@ -470,11 +470,11 @@
470	get paid more by mastering arcane features of my DVCS?" Unless you have
471	a good answer to that, you probably do not want to be choosing a DVCS
472	based on how many arcane features it has.
473
474	The argument is similar for other types of users: if you are a hobbyist,
475	how much time do you want to spend mastering your DVCS instead of on
476	the hobby supported by use of that DVCS?
477
478	There is some minimal set of features required to achieve the purposes
479	that drive our selection of a DVCS, but there is a level beyond which
480	more features only slow us down while we're learning the tool, since we
	@@ -526,11 +526,11 @@
526	<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
527
528	A "repository" in Git is a pile-of-files in the <tt>.git</tt>
529	subdirectory of a single check-out. The working check-out directory and
530	the <tt>.git</tt> repository subdirectory are normally in the same
531	directory within the file system.
532
533	With Fossil, a "repository" is a single SQLite database file that can be
534	stored anywhere. There can be multiple active check-outs from the same
535	repository, perhaps open on different branches or on different snapshots
536	of the same branch. It is common in Fossil to switch branches with a
	@@ -603,14 +603,17 @@
603	[https://en.wikipedia.org/wiki/SHA-3\|256-bit SHA-3] with
604	[./hashpolicy.wiki\|full backwards compatibility] to old SHA-1 based
605	repositories.
606
607	Here in mid-2019, that feature is now in every OS and package repository
608	known to include Fossil so that the next release
609	(Fossil 2.10) will begin using SHA-3 hashes even on repos currently
610	limited to SHA-1 for compatibility with Fossil 1.<i>x</i>,
611	effectively upgrading them to require Fossil 2.1 or newer. This
612	not only solves the SHAttered problem, it should prevent a reoccurrence
613	for the foreseeable future. With the current release (Fossil 2.9) only
614	repositories created before the
615	transition to Fossil 2 are still using SHA-1, and then only if the
616	repository's maintainer chose not to switch them into SHA-3 mode some
617	time over the past 2 years.
618
619	Meanwhile, the Git community took until August 2018 to announce
	@@ -698,11 +701,11 @@
701	several parts, so that it is not strictly true that "everything" on
702	it is in the self-hosting Fossil project repo. The web forum is
703	hosted as [https://fossil-scm.org/forum/\|a separate Fossil repo]
704	from the [https://fossil-scm.org/fossil/\|main Fossil self-hosting
705	repo] for administration reasons, and the Download page content
706	isn't normally synchronized with a "<tt>fossil clone</tt>" command unless
707	you add the "-u" option. (See "[./aboutdownload.wiki\|How the
708	Download Page Works]" for details.) There may also be some purely
709	static elements of the web site served via D. Richard Hipp's own
710	lightweight web server,
711	<tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|althttpd]</tt>,
	@@ -718,11 +721,11 @@
721	<li><p>This means you can give up waiting for Fossil to be ported to
722	the PDP-11, but we remain hopeful that someone may eventually port
723	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
724
725	<li><p>We try to keep use of Javascript to a minimum in the web UI,
726	and we always try to provide sensible fall-backs for those that run
727	their browsers with Javascript disabled. Some features of the web UI
728	simply won't run without Javascript, but the UI behavior does
729	degrade gracefully.
730
731	<li><p>"Why is there all this Tcl in and around Fossil?" you may
732

M www/fossil_prompt.wiki

+1 -1

		--- www/fossil_prompt.wiki
		+++ www/fossil_prompt.wiki
		@@ -3,11 +3,11 @@
3	3
4	4	Dan Kennedy has contributed a
5	5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	6	that manipulates the bash prompt to show the status of
7	7	the Fossil repository that the user is currently visiting.
8		-The prompt shows the branch, version, and timestamp for the
	8	+The prompt shows the branch, version, and time stamp for the
9	9	current checkout, and the prompt changes colors from blue to
10	10	red when there are uncommitted changes.
11	11
12	12	To try out this script, simply download it from the link above, then
13	13	type:
14	14

	--- www/fossil_prompt.wiki
	+++ www/fossil_prompt.wiki
	@@ -3,11 +3,11 @@
3
4	Dan Kennedy has contributed a
5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	that manipulates the bash prompt to show the status of
7	the Fossil repository that the user is currently visiting.
8	The prompt shows the branch, version, and timestamp for the
9	current checkout, and the prompt changes colors from blue to
10	red when there are uncommitted changes.
11
12	To try out this script, simply download it from the link above, then
13	type:
14

	--- www/fossil_prompt.wiki
	+++ www/fossil_prompt.wiki
	@@ -3,11 +3,11 @@
3
4	Dan Kennedy has contributed a
5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	that manipulates the bash prompt to show the status of
7	the Fossil repository that the user is currently visiting.
8	The prompt shows the branch, version, and time stamp for the
9	current checkout, and the prompt changes colors from blue to
10	red when there are uncommitted changes.
11
12	To try out this script, simply download it from the link above, then
13	type:
14

M www/index.wiki

+5 -4

		--- www/index.wiki
		+++ www/index.wiki
		@@ -61,13 +61,14 @@
61	61	The protocol is
62	62	[./stats.wiki \| bandwidth efficient] to the point that Fossil can be
63	63	used comfortably over dial-up or over the exceedingly slow Wifi on
64	64	airliners.
65	65
66		- 5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to
67		- set one up, Fossil supports four easy [./server.wiki \| server configurations].
68		- You can also easily set up your server to automatically
	66	+ 5. <b>Simple Server Setup</b> - No server is required, but if you want to
	67	+ set one up, Fossil supports [./server/ \| several different server
	68	+ configurations] including CGI, SCGI, and direct HTTP.
	69	+ You can also easily set up your Fossil repository to automatically
69	70	[./mirrortogithub.md \| mirror content on GitHub].
70	71
71	72	6. <b>Autosync</b> -
72	73	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
73	74	which helps to keep projects moving
		@@ -128,11 +129,11 @@
128	129	its key functionality to TH1 scripts.
129	130	* List of [./th1-hooks.md \| TH1 hooks exposed by Fossil] that enable
130	131	customization of commands and web pages.
131	132	* A free hosting server for Fossil repositories is available at
132	133	[http://chiselapp.com/].
133		- * How to [./server.wiki \| set up a server] for your repository.
	134	+ * How to [./server/ \| set up a server] for your repository.
134	135	* Customizing the [./custom_ticket.wiki \| ticket system].
135	136	* Methods to [./checkin_names.wiki \| identify a specific check-in].
136	137	* [./inout.wiki \| Import and export] from and to Git.
137	138	* [./fossil-v-git.wiki \| Fossil versus Git].
138	139	* [./fiveminutes.wiki \| Up and running in 5 minutes as a single user]
139	140
140	141	ADDED www/loadmgmt.md

	--- www/index.wiki
	+++ www/index.wiki
	@@ -61,13 +61,14 @@
61	The protocol is
62	[./stats.wiki \| bandwidth efficient] to the point that Fossil can be
63	used comfortably over dial-up or over the exceedingly slow Wifi on
64	airliners.
65
66	5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to
67	set one up, Fossil supports four easy [./server.wiki \| server configurations].
68	You can also easily set up your server to automatically

69	[./mirrortogithub.md \| mirror content on GitHub].
70
71	6. <b>Autosync</b> -
72	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
73	which helps to keep projects moving
	@@ -128,11 +129,11 @@
128	its key functionality to TH1 scripts.
129	* List of [./th1-hooks.md \| TH1 hooks exposed by Fossil] that enable
130	customization of commands and web pages.
131	* A free hosting server for Fossil repositories is available at
132	[http://chiselapp.com/].
133	* How to [./server.wiki \| set up a server] for your repository.
134	* Customizing the [./custom_ticket.wiki \| ticket system].
135	* Methods to [./checkin_names.wiki \| identify a specific check-in].
136	* [./inout.wiki \| Import and export] from and to Git.
137	* [./fossil-v-git.wiki \| Fossil versus Git].
138	* [./fiveminutes.wiki \| Up and running in 5 minutes as a single user]
139
140	DDED www/loadmgmt.md

	--- www/index.wiki
	+++ www/index.wiki
	@@ -61,13 +61,14 @@
61	The protocol is
62	[./stats.wiki \| bandwidth efficient] to the point that Fossil can be
63	used comfortably over dial-up or over the exceedingly slow Wifi on
64	airliners.
65
66	5. <b>Simple Server Setup</b> - No server is required, but if you want to
67	set one up, Fossil supports [./server/ \| several different server
68	configurations] including CGI, SCGI, and direct HTTP.
69	You can also easily set up your Fossil repository to automatically
70	[./mirrortogithub.md \| mirror content on GitHub].
71
72	6. <b>Autosync</b> -
73	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
74	which helps to keep projects moving
	@@ -128,11 +129,11 @@
129	its key functionality to TH1 scripts.
130	* List of [./th1-hooks.md \| TH1 hooks exposed by Fossil] that enable
131	customization of commands and web pages.
132	* A free hosting server for Fossil repositories is available at
133	[http://chiselapp.com/].
134	* How to [./server/ \| set up a server] for your repository.
135	* Customizing the [./custom_ticket.wiki \| ticket system].
136	* Methods to [./checkin_names.wiki \| identify a specific check-in].
137	* [./inout.wiki \| Import and export] from and to Git.
138	* [./fossil-v-git.wiki \| Fossil versus Git].
139	* [./fiveminutes.wiki \| Up and running in 5 minutes as a single user]
140
141	DDED www/loadmgmt.md

M www/loadmgmt.md

+2

		--- a/www/loadmgmt.md
		+++ b/www/loadmgmt.md
		@@ -0,0 +1,2 @@
	1	+
	2	+

	--- a/www/loadmgmt.md
	+++ b/www/loadmgmt.md
	@@ -0,0 +1,2 @@

	--- a/www/loadmgmt.md
	+++ b/www/loadmgmt.md
	@@ -0,0 +1,2 @@
1
2

M www/mirrortogithub.md

+1

		--- www/mirrortogithub.md
		+++ www/mirrortogithub.md
		@@ -116,10 +116,11 @@
116	116	on tag and branch names in Git. If any of your Fossil tag or branch names
117	117	violate these rules, then the names are translated prior to being exported
118	118	to Git. The translation usually involves converting the offending characters
119	119	into underscores.
120	120
	121	+<a name='ex1'></a>
121	122	## Example GitHub Mirrors
122	123
123	124	As of this writing (2019-03-16) Fossil’s own repository is mirrored
124	125	on GitHub at:
125	126
126	127

	--- www/mirrortogithub.md
	+++ www/mirrortogithub.md
	@@ -116,10 +116,11 @@
116	on tag and branch names in Git. If any of your Fossil tag or branch names
117	violate these rules, then the names are translated prior to being exported
118	to Git. The translation usually involves converting the offending characters
119	into underscores.
120

121	## Example GitHub Mirrors
122
123	As of this writing (2019-03-16) Fossil’s own repository is mirrored
124	on GitHub at:
125
126

	--- www/mirrortogithub.md
	+++ www/mirrortogithub.md
	@@ -116,10 +116,11 @@
116	on tag and branch names in Git. If any of your Fossil tag or branch names
117	violate these rules, then the names are translated prior to being exported
118	to Git. The translation usually involves converting the offending characters
119	into underscores.
120
121	<a name='ex1'></a>
122	## Example GitHub Mirrors
123
124	As of this writing (2019-03-16) Fossil’s own repository is mirrored
125	on GitHub at:
126
127

M www/mkindex.tcl

+3 -1

		--- www/mkindex.tcl
		+++ www/mkindex.tcl
		@@ -18,10 +18,11 @@
18	18	blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19	19	blockchain.md {Fossil As Blockchain}
20	20	branching.wiki {Branching, Forking, Merging, and Tagging}
21	21	bugtheory.wiki {Bug Tracking In Fossil}
22	22	build.wiki {Compiling and Installing Fossil}
	23	+ cgi.wiki {CGI Script Configuration Options}
23	24	changes.wiki {Fossil Changelog}
24	25	checkin_names.wiki {Check-in And Version Names}
25	26	checkin.wiki {Check-in Checklist}
26	27	childprojects.wiki {Child Projects}
27	28	copyright-release.html {Contributor License Agreement}
		@@ -29,10 +30,11 @@
29	30	contribute.wiki {Contributing Code or Documentation To The Fossil Project}
30	31	customgraph.md {Theming: Customizing the Timeline Graph}
31	32	customskin.md {Theming: Customizing The Appearance of Web Pages}
32	33	customskin.md {Custom Skins}
33	34	custom_ticket.wiki {Customizing The Ticket System}
	35	+ defcsp.md {The Default Content Security Policy}
34	36	delta_encoder_algorithm.wiki {Fossil Delta Encoding Algorithm}
35	37	delta_format.wiki {Fossil Delta Format}
36	38	embeddeddoc.wiki {Embedded Project Documentation}
37	39	encryptedrepos.wiki {How To Use Encrypted Repositories}
38	40	env-opts.md {Environment Variables and Global Options}
		@@ -68,11 +70,11 @@
68	70	{Quotes: What People Are Saying About Fossil, Git, and DVCSes in General}
69	71	../test/release-checklist.wiki {Pre-Release Testing Checklist}
70	72	reviews.wiki {Reviews}
71	73	selfcheck.wiki {Fossil Repository Integrity Self Checks}
72	74	selfhost.wiki {Fossil Self Hosting Repositories}
73		- server.wiki {How To Configure A Fossil Server}
	75	+ server/ {How To Configure A Fossil Server}
74	76	serverext.wiki {CGI Server Extensions}
75	77	serverext.wiki {Adding Extensions To A Fossil Server Using CGI Scripts}
76	78	settings.wiki {Fossil Settings}
77	79	/sitemap {Site Map}
78	80	shunning.wiki {Shunning: Deleting Content From Fossil}
79	81

	--- www/mkindex.tcl
	+++ www/mkindex.tcl
	@@ -18,10 +18,11 @@
18	blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19	blockchain.md {Fossil As Blockchain}
20	branching.wiki {Branching, Forking, Merging, and Tagging}
21	bugtheory.wiki {Bug Tracking In Fossil}
22	build.wiki {Compiling and Installing Fossil}

23	changes.wiki {Fossil Changelog}
24	checkin_names.wiki {Check-in And Version Names}
25	checkin.wiki {Check-in Checklist}
26	childprojects.wiki {Child Projects}
27	copyright-release.html {Contributor License Agreement}
	@@ -29,10 +30,11 @@
29	contribute.wiki {Contributing Code or Documentation To The Fossil Project}
30	customgraph.md {Theming: Customizing the Timeline Graph}
31	customskin.md {Theming: Customizing The Appearance of Web Pages}
32	customskin.md {Custom Skins}
33	custom_ticket.wiki {Customizing The Ticket System}

34	delta_encoder_algorithm.wiki {Fossil Delta Encoding Algorithm}
35	delta_format.wiki {Fossil Delta Format}
36	embeddeddoc.wiki {Embedded Project Documentation}
37	encryptedrepos.wiki {How To Use Encrypted Repositories}
38	env-opts.md {Environment Variables and Global Options}
	@@ -68,11 +70,11 @@
68	{Quotes: What People Are Saying About Fossil, Git, and DVCSes in General}
69	../test/release-checklist.wiki {Pre-Release Testing Checklist}
70	reviews.wiki {Reviews}
71	selfcheck.wiki {Fossil Repository Integrity Self Checks}
72	selfhost.wiki {Fossil Self Hosting Repositories}
73	server.wiki {How To Configure A Fossil Server}
74	serverext.wiki {CGI Server Extensions}
75	serverext.wiki {Adding Extensions To A Fossil Server Using CGI Scripts}
76	settings.wiki {Fossil Settings}
77	/sitemap {Site Map}
78	shunning.wiki {Shunning: Deleting Content From Fossil}
79

	--- www/mkindex.tcl
	+++ www/mkindex.tcl
	@@ -18,10 +18,11 @@
18	blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19	blockchain.md {Fossil As Blockchain}
20	branching.wiki {Branching, Forking, Merging, and Tagging}
21	bugtheory.wiki {Bug Tracking In Fossil}
22	build.wiki {Compiling and Installing Fossil}
23	cgi.wiki {CGI Script Configuration Options}
24	changes.wiki {Fossil Changelog}
25	checkin_names.wiki {Check-in And Version Names}
26	checkin.wiki {Check-in Checklist}
27	childprojects.wiki {Child Projects}
28	copyright-release.html {Contributor License Agreement}
	@@ -29,10 +30,11 @@
30	contribute.wiki {Contributing Code or Documentation To The Fossil Project}
31	customgraph.md {Theming: Customizing the Timeline Graph}
32	customskin.md {Theming: Customizing The Appearance of Web Pages}
33	customskin.md {Custom Skins}
34	custom_ticket.wiki {Customizing The Ticket System}
35	defcsp.md {The Default Content Security Policy}
36	delta_encoder_algorithm.wiki {Fossil Delta Encoding Algorithm}
37	delta_format.wiki {Fossil Delta Format}
38	embeddeddoc.wiki {Embedded Project Documentation}
39	encryptedrepos.wiki {How To Use Encrypted Repositories}
40	env-opts.md {Environment Variables and Global Options}
	@@ -68,11 +70,11 @@
70	{Quotes: What People Are Saying About Fossil, Git, and DVCSes in General}
71	../test/release-checklist.wiki {Pre-Release Testing Checklist}
72	reviews.wiki {Reviews}
73	selfcheck.wiki {Fossil Repository Integrity Self Checks}
74	selfhost.wiki {Fossil Self Hosting Repositories}
75	server/ {How To Configure A Fossil Server}
76	serverext.wiki {CGI Server Extensions}
77	serverext.wiki {Adding Extensions To A Fossil Server Using CGI Scripts}
78	settings.wiki {Fossil Settings}
79	/sitemap {Site Map}
80	shunning.wiki {Shunning: Deleting Content From Fossil}
81

M www/password.wiki

+1 -1

		--- www/password.wiki
		+++ www/password.wiki
		@@ -97,11 +97,11 @@
97	97	write information into the repository database. Hence, login is not
98	98	possible on a Fossil repository with a read-only database file.
99	99
100	100	The user password is sent over the wire as cleartext on the initial
101	101	login attempt. The plan moving forward is to compute the SHA1 hash of
102		-the password on the client using javascript and then send only the hash
	102	+the password on the client using JavaScript and then send only the hash
103	103	over the wire, but that plan has not yet been set in code.
104	104
105	105	<h2>Sync Protocol Authentication</h2>
106	106
107	107	A different authentication mechanism is used when one repository wants
108	108

	--- www/password.wiki
	+++ www/password.wiki
	@@ -97,11 +97,11 @@
97	write information into the repository database. Hence, login is not
98	possible on a Fossil repository with a read-only database file.
99
100	The user password is sent over the wire as cleartext on the initial
101	login attempt. The plan moving forward is to compute the SHA1 hash of
102	the password on the client using javascript and then send only the hash
103	over the wire, but that plan has not yet been set in code.
104
105	<h2>Sync Protocol Authentication</h2>
106
107	A different authentication mechanism is used when one repository wants
108

	--- www/password.wiki
	+++ www/password.wiki
	@@ -97,11 +97,11 @@
97	write information into the repository database. Hence, login is not
98	possible on a Fossil repository with a read-only database file.
99
100	The user password is sent over the wire as cleartext on the initial
101	login attempt. The plan moving forward is to compute the SHA1 hash of
102	the password on the client using JavaScript and then send only the hash
103	over the wire, but that plan has not yet been set in code.
104
105	<h2>Sync Protocol Authentication</h2>
106
107	A different authentication mechanism is used when one repository wants
108

M www/permutedindex.html

+12 -3

		--- www/permutedindex.html
		+++ www/permutedindex.html
		@@ -44,10 +44,11 @@
44	44	<li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li>
45	45	<li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
46	46	<li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
47	47	<li><a href="makefile.wiki">Build Process — The Fossil</a></li>
48	48	<li><a href="admin-v-setup.md">Capabilities — The Differences Between the Setup and Admin User</a></li>
	49	+<li><a href="cgi.wiki"><b>CGI Script Configuration Options</b></a></li>
49	50	<li><a href="serverext.wiki">CGI Scripts — Adding Extensions To A Fossil Server Using</a></li>
50	51	<li><a href="serverext.wiki"><b>CGI Server Extensions</b></a></li>
51	52	<li><a href="aboutcgi.wiki">CGI Works In Fossil — How</a></li>
52	53	<li><a href="changes.wiki">Changelog — Fossil</a></li>
53	54	<li><a href="checkin_names.wiki"><b>Check-in And Version Names</b></a></li>
		@@ -61,12 +62,14 @@
61	62	<li><a href="contribute.wiki">Code or Documentation To The Fossil Project — Contributing</a></li>
62	63	<li><a href="style.wiki">Code Style Guidelines — Source</a></li>
63	64	<li><a href="../../../help">Commands and Webpages — Lists of</a></li>
64	65	<li><a href="build.wiki"><b>Compiling and Installing Fossil</b></a></li>
65	66	<li><a href="concepts.wiki">Concepts — Fossil Core</a></li>
66		-<li><a href="server.wiki">Configure A Fossil Server — How To</a></li>
	67	+<li><a href="cgi.wiki">Configuration Options — CGI Script</a></li>
	68	+<li><a href="server/">Configure A Fossil Server — How To</a></li>
67	69	<li><a href="shunning.wiki">Content From Fossil — Shunning: Deleting</a></li>
	70	+<li><a href="defcsp.md">Content Security Policy — The Default</a></li>
68	71	<li><a href="contribute.wiki"><b>Contributing Code or Documentation To The Fossil Project</b></a></li>
69	72	<li><a href="copyright-release.html"><b>Contributor License Agreement</b></a></li>
70	73	<li><a href="whyusefossil.wiki">Control — Benefits Of Version</a></li>
71	74	<li><a href="concepts.wiki">Core Concepts — Fossil</a></li>
72	75	<li><a href="newrepo.wiki">Create A New Fossil Repository — How To</a></li>
		@@ -75,10 +78,11 @@
75	78	<li><a href="customskin.md"><b>Custom Skins</b></a></li>
76	79	<li><a href="customskin.md">Customizing The Appearance of Web Pages — Theming:</a></li>
77	80	<li><a href="custom_ticket.wiki"><b>Customizing The Ticket System</b></a></li>
78	81	<li><a href="customgraph.md">Customizing the Timeline Graph — Theming:</a></li>
79	82	<li><a href="tech_overview.wiki">Databases Used By Fossil — SQLite</a></li>
	83	+<li><a href="defcsp.md">Default Content Security Policy — The</a></li>
80	84	<li><a href="antibot.wiki"><b>Defense against Spiders and Bots</b></a></li>
81	85	<li><a href="shunning.wiki">Deleting Content From Fossil — Shunning:</a></li>
82	86	<li><a href="private.wiki">Deleting Private Branches — Creating, Syncing, and</a></li>
83	87	<li><a href="delta_encoder_algorithm.wiki">Delta Encoding Algorithm — Fossil</a></li>
84	88	<li><a href="delta_format.wiki">Delta Format — Fossil</a></li>
		@@ -148,11 +152,11 @@
148	152	<li><a href="hints.wiki">Hints — Fossil Tips And Usage</a></li>
149	153	<li><a href="index.wiki"><b>Home Page</b></a></li>
150	154	<li><a href="selfhost.wiki">Hosting Repositories — Fossil Self</a></li>
151	155	<li><a href="aboutcgi.wiki"><b>How CGI Works In Fossil</b></a></li>
152	156	<li><a href="aboutdownload.wiki"><b>How The Download Page Works</b></a></li>
153		-<li><a href="server.wiki"><b>How To Configure A Fossil Server</b></a></li>
	157	+<li><a href="server/"><b>How To Configure A Fossil Server</b></a></li>
154	158	<li><a href="newrepo.wiki"><b>How To Create A New Fossil Repository</b></a></li>
155	159	<li><a href="mirrortogithub.md"><b>How To Mirror A Fossil Repository On GitHub</b></a></li>
156	160	<li><a href="encryptedrepos.wiki"><b>How To Use Encrypted Repositories</b></a></li>
157	161	<li><a href="hacker-howto.wiki">How-To — Hacker</a></li>
158	162	<li><a href="tls-nginx.md">HTTPS with nginx — Proxying Fossil via</a></li>
		@@ -183,19 +187,21 @@
183	187	<li><a href="newrepo.wiki">New Fossil Repository — How To Create A</a></li>
184	188	<li><a href="tls-nginx.md">nginx — Proxying Fossil via HTTPS with</a></li>
185	189	<li><a href="alerts.md">Notifications — Email Alerts And</a></li>
186	190	<li><a href="foss-cklist.wiki">Open-Source Projects — Checklist For Successful</a></li>
187	191	<li><a href="pop.wiki">Operation — Principles Of</a></li>
	192	+<li><a href="cgi.wiki">Options — CGI Script Configuration</a></li>
188	193	<li><a href="env-opts.md">Options — Environment Variables and Global</a></li>
189	194	<li><a href="tech_overview.wiki">Overview Of The Design And Implementation Of Fossil — A Technical</a></li>
190	195	<li><a href="index.wiki">Page — Home</a></li>
191	196	<li><a href="aboutdownload.wiki">Page Works — How The Download</a></li>
192	197	<li><a href="customskin.md">Pages — Theming: Customizing The Appearance of Web</a></li>
193	198	<li><a href="password.wiki"><b>Password Management And Authentication</b></a></li>
194	199	<li><a href="globs.md">Patterns — File Name Glob</a></li>
195	200	<li><a href="quotes.wiki">People Are Saying About Fossil, Git, and DVCSes in General — Quotes: What</a></li>
196	201	<li><a href="stats.wiki"><b>Performance Statistics</b></a></li>
	202	+<li><a href="defcsp.md">Policy — The Default Content Security</a></li>
197	203	<li><a href="hashpolicy.wiki">Policy: Choosing Between SHA1 and SHA3-256 — Hash</a></li>
198	204	<li><a href="grep.md">POSIX grep — Fossil grep vs</a></li>
199	205	<li><a href="../test/release-checklist.wiki"><b>Pre-Release Testing Checklist</b></a></li>
200	206	<li><a href="pop.wiki"><b>Principles Of Operation</b></a></li>
201	207	<li><a href="private.wiki">Private Branches — Creating, Syncing, and Deleting</a></li>
		@@ -220,15 +226,17 @@
220	226	<li><a href="reviews.wiki"><b>Reviews</b></a></li>
221	227	<li><a href="../../../md_rules">Rules — Markdown Formatting</a></li>
222	228	<li><a href="../../../wiki_rules">Rules — Wiki Formatting</a></li>
223	229	<li><a href="fiveminutes.wiki">Running in 5 Minutes as a Single User — Up and</a></li>
224	230	<li><a href="quotes.wiki">Saying About Fossil, Git, and DVCSes in General — Quotes: What People Are</a></li>
	231	+<li><a href="cgi.wiki">Script Configuration Options — CGI</a></li>
225	232	<li><a href="th1.md">Scripting Language — The TH1</a></li>
226	233	<li><a href="serverext.wiki">Scripts — Adding Extensions To A Fossil Server Using CGI</a></li>
	234	+<li><a href="defcsp.md">Security Policy — The Default Content</a></li>
227	235	<li><a href="selfcheck.wiki">Self Checks — Fossil Repository Integrity</a></li>
228	236	<li><a href="selfhost.wiki">Self Hosting Repositories — Fossil</a></li>
229		-<li><a href="server.wiki">Server — How To Configure A Fossil</a></li>
	237	+<li><a href="server/">Server — How To Configure A Fossil</a></li>
230	238	<li><a href="serverext.wiki">Server Extensions — CGI</a></li>
231	239	<li><a href="serverext.wiki">Server Using CGI Scripts — Adding Extensions To A Fossil</a></li>
232	240	<li><a href="settings.wiki">Settings — Fossil</a></li>
233	241	<li><a href="admin-v-setup.md">Setup and Admin User Capabilities — The Differences Between the</a></li>
234	242	<li><a href="hashpolicy.wiki">SHA1 and SHA3-256 — Hash Policy: Choosing Between</a></li>
		@@ -254,10 +262,11 @@
254	262	<li><a href="tech_overview.wiki">Technical Overview Of The Design And Implementation Of Fossil — A</a></li>
255	263	<li><a href="../test/release-checklist.wiki">Testing Checklist — Pre-Release</a></li>
256	264	<li><a href="th1.md">TH1 Scripting Language — The</a></li>
257	265	<li><a href="backoffice.md"><b>The "Backoffice" mechanism of Fossil</b></a></li>
258	266	<li><a href="blame.wiki"><b>The Annotate/Blame Algorithm Of Fossil</b></a></li>
	267	+<li><a href="defcsp.md"><b>The Default Content Security Policy</b></a></li>
259	268	<li><a href="admin-v-setup.md"><b>The Differences Between the Setup and Admin User Capabilities</b></a></li>
260	269	<li><a href="makefile.wiki"><b>The Fossil Build Process</b></a></li>
261	270	<li><a href="sync.wiki"><b>The Fossil Sync Protocol</b></a></li>
262	271	<li><a href="tickets.wiki"><b>The Fossil Ticket System</b></a></li>
263	272	<li><a href="webui.wiki"><b>The Fossil Web Interface</b></a></li>
264	273

	--- www/permutedindex.html
	+++ www/permutedindex.html
	@@ -44,10 +44,11 @@
44	<li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li>
45	<li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
46	<li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
47	<li><a href="makefile.wiki">Build Process — The Fossil</a></li>
48	<li><a href="admin-v-setup.md">Capabilities — The Differences Between the Setup and Admin User</a></li>

49	<li><a href="serverext.wiki">CGI Scripts — Adding Extensions To A Fossil Server Using</a></li>
50	<li><a href="serverext.wiki"><b>CGI Server Extensions</b></a></li>
51	<li><a href="aboutcgi.wiki">CGI Works In Fossil — How</a></li>
52	<li><a href="changes.wiki">Changelog — Fossil</a></li>
53	<li><a href="checkin_names.wiki"><b>Check-in And Version Names</b></a></li>
	@@ -61,12 +62,14 @@
61	<li><a href="contribute.wiki">Code or Documentation To The Fossil Project — Contributing</a></li>
62	<li><a href="style.wiki">Code Style Guidelines — Source</a></li>
63	<li><a href="../../../help">Commands and Webpages — Lists of</a></li>
64	<li><a href="build.wiki"><b>Compiling and Installing Fossil</b></a></li>
65	<li><a href="concepts.wiki">Concepts — Fossil Core</a></li>
66	<li><a href="server.wiki">Configure A Fossil Server — How To</a></li>

67	<li><a href="shunning.wiki">Content From Fossil — Shunning: Deleting</a></li>

68	<li><a href="contribute.wiki"><b>Contributing Code or Documentation To The Fossil Project</b></a></li>
69	<li><a href="copyright-release.html"><b>Contributor License Agreement</b></a></li>
70	<li><a href="whyusefossil.wiki">Control — Benefits Of Version</a></li>
71	<li><a href="concepts.wiki">Core Concepts — Fossil</a></li>
72	<li><a href="newrepo.wiki">Create A New Fossil Repository — How To</a></li>
	@@ -75,10 +78,11 @@
75	<li><a href="customskin.md"><b>Custom Skins</b></a></li>
76	<li><a href="customskin.md">Customizing The Appearance of Web Pages — Theming:</a></li>
77	<li><a href="custom_ticket.wiki"><b>Customizing The Ticket System</b></a></li>
78	<li><a href="customgraph.md">Customizing the Timeline Graph — Theming:</a></li>
79	<li><a href="tech_overview.wiki">Databases Used By Fossil — SQLite</a></li>

80	<li><a href="antibot.wiki"><b>Defense against Spiders and Bots</b></a></li>
81	<li><a href="shunning.wiki">Deleting Content From Fossil — Shunning:</a></li>
82	<li><a href="private.wiki">Deleting Private Branches — Creating, Syncing, and</a></li>
83	<li><a href="delta_encoder_algorithm.wiki">Delta Encoding Algorithm — Fossil</a></li>
84	<li><a href="delta_format.wiki">Delta Format — Fossil</a></li>
	@@ -148,11 +152,11 @@
148	<li><a href="hints.wiki">Hints — Fossil Tips And Usage</a></li>
149	<li><a href="index.wiki"><b>Home Page</b></a></li>
150	<li><a href="selfhost.wiki">Hosting Repositories — Fossil Self</a></li>
151	<li><a href="aboutcgi.wiki"><b>How CGI Works In Fossil</b></a></li>
152	<li><a href="aboutdownload.wiki"><b>How The Download Page Works</b></a></li>
153	<li><a href="server.wiki"><b>How To Configure A Fossil Server</b></a></li>
154	<li><a href="newrepo.wiki"><b>How To Create A New Fossil Repository</b></a></li>
155	<li><a href="mirrortogithub.md"><b>How To Mirror A Fossil Repository On GitHub</b></a></li>
156	<li><a href="encryptedrepos.wiki"><b>How To Use Encrypted Repositories</b></a></li>
157	<li><a href="hacker-howto.wiki">How-To — Hacker</a></li>
158	<li><a href="tls-nginx.md">HTTPS with nginx — Proxying Fossil via</a></li>
	@@ -183,19 +187,21 @@
183	<li><a href="newrepo.wiki">New Fossil Repository — How To Create A</a></li>
184	<li><a href="tls-nginx.md">nginx — Proxying Fossil via HTTPS with</a></li>
185	<li><a href="alerts.md">Notifications — Email Alerts And</a></li>
186	<li><a href="foss-cklist.wiki">Open-Source Projects — Checklist For Successful</a></li>
187	<li><a href="pop.wiki">Operation — Principles Of</a></li>

188	<li><a href="env-opts.md">Options — Environment Variables and Global</a></li>
189	<li><a href="tech_overview.wiki">Overview Of The Design And Implementation Of Fossil — A Technical</a></li>
190	<li><a href="index.wiki">Page — Home</a></li>
191	<li><a href="aboutdownload.wiki">Page Works — How The Download</a></li>
192	<li><a href="customskin.md">Pages — Theming: Customizing The Appearance of Web</a></li>
193	<li><a href="password.wiki"><b>Password Management And Authentication</b></a></li>
194	<li><a href="globs.md">Patterns — File Name Glob</a></li>
195	<li><a href="quotes.wiki">People Are Saying About Fossil, Git, and DVCSes in General — Quotes: What</a></li>
196	<li><a href="stats.wiki"><b>Performance Statistics</b></a></li>

197	<li><a href="hashpolicy.wiki">Policy: Choosing Between SHA1 and SHA3-256 — Hash</a></li>
198	<li><a href="grep.md">POSIX grep — Fossil grep vs</a></li>
199	<li><a href="../test/release-checklist.wiki"><b>Pre-Release Testing Checklist</b></a></li>
200	<li><a href="pop.wiki"><b>Principles Of Operation</b></a></li>
201	<li><a href="private.wiki">Private Branches — Creating, Syncing, and Deleting</a></li>
	@@ -220,15 +226,17 @@
220	<li><a href="reviews.wiki"><b>Reviews</b></a></li>
221	<li><a href="../../../md_rules">Rules — Markdown Formatting</a></li>
222	<li><a href="../../../wiki_rules">Rules — Wiki Formatting</a></li>
223	<li><a href="fiveminutes.wiki">Running in 5 Minutes as a Single User — Up and</a></li>
224	<li><a href="quotes.wiki">Saying About Fossil, Git, and DVCSes in General — Quotes: What People Are</a></li>

225	<li><a href="th1.md">Scripting Language — The TH1</a></li>
226	<li><a href="serverext.wiki">Scripts — Adding Extensions To A Fossil Server Using CGI</a></li>

227	<li><a href="selfcheck.wiki">Self Checks — Fossil Repository Integrity</a></li>
228	<li><a href="selfhost.wiki">Self Hosting Repositories — Fossil</a></li>
229	<li><a href="server.wiki">Server — How To Configure A Fossil</a></li>
230	<li><a href="serverext.wiki">Server Extensions — CGI</a></li>
231	<li><a href="serverext.wiki">Server Using CGI Scripts — Adding Extensions To A Fossil</a></li>
232	<li><a href="settings.wiki">Settings — Fossil</a></li>
233	<li><a href="admin-v-setup.md">Setup and Admin User Capabilities — The Differences Between the</a></li>
234	<li><a href="hashpolicy.wiki">SHA1 and SHA3-256 — Hash Policy: Choosing Between</a></li>
	@@ -254,10 +262,11 @@
254	<li><a href="tech_overview.wiki">Technical Overview Of The Design And Implementation Of Fossil — A</a></li>
255	<li><a href="../test/release-checklist.wiki">Testing Checklist — Pre-Release</a></li>
256	<li><a href="th1.md">TH1 Scripting Language — The</a></li>
257	<li><a href="backoffice.md"><b>The "Backoffice" mechanism of Fossil</b></a></li>
258	<li><a href="blame.wiki"><b>The Annotate/Blame Algorithm Of Fossil</b></a></li>

259	<li><a href="admin-v-setup.md"><b>The Differences Between the Setup and Admin User Capabilities</b></a></li>
260	<li><a href="makefile.wiki"><b>The Fossil Build Process</b></a></li>
261	<li><a href="sync.wiki"><b>The Fossil Sync Protocol</b></a></li>
262	<li><a href="tickets.wiki"><b>The Fossil Ticket System</b></a></li>
263	<li><a href="webui.wiki"><b>The Fossil Web Interface</b></a></li>
264

	--- www/permutedindex.html
	+++ www/permutedindex.html
	@@ -44,10 +44,11 @@
44	<li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li>
45	<li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
46	<li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
47	<li><a href="makefile.wiki">Build Process — The Fossil</a></li>
48	<li><a href="admin-v-setup.md">Capabilities — The Differences Between the Setup and Admin User</a></li>
49	<li><a href="cgi.wiki"><b>CGI Script Configuration Options</b></a></li>
50	<li><a href="serverext.wiki">CGI Scripts — Adding Extensions To A Fossil Server Using</a></li>
51	<li><a href="serverext.wiki"><b>CGI Server Extensions</b></a></li>
52	<li><a href="aboutcgi.wiki">CGI Works In Fossil — How</a></li>
53	<li><a href="changes.wiki">Changelog — Fossil</a></li>
54	<li><a href="checkin_names.wiki"><b>Check-in And Version Names</b></a></li>
	@@ -61,12 +62,14 @@
62	<li><a href="contribute.wiki">Code or Documentation To The Fossil Project — Contributing</a></li>
63	<li><a href="style.wiki">Code Style Guidelines — Source</a></li>
64	<li><a href="../../../help">Commands and Webpages — Lists of</a></li>
65	<li><a href="build.wiki"><b>Compiling and Installing Fossil</b></a></li>
66	<li><a href="concepts.wiki">Concepts — Fossil Core</a></li>
67	<li><a href="cgi.wiki">Configuration Options — CGI Script</a></li>
68	<li><a href="server/">Configure A Fossil Server — How To</a></li>
69	<li><a href="shunning.wiki">Content From Fossil — Shunning: Deleting</a></li>
70	<li><a href="defcsp.md">Content Security Policy — The Default</a></li>
71	<li><a href="contribute.wiki"><b>Contributing Code or Documentation To The Fossil Project</b></a></li>
72	<li><a href="copyright-release.html"><b>Contributor License Agreement</b></a></li>
73	<li><a href="whyusefossil.wiki">Control — Benefits Of Version</a></li>
74	<li><a href="concepts.wiki">Core Concepts — Fossil</a></li>
75	<li><a href="newrepo.wiki">Create A New Fossil Repository — How To</a></li>
	@@ -75,10 +78,11 @@
78	<li><a href="customskin.md"><b>Custom Skins</b></a></li>
79	<li><a href="customskin.md">Customizing The Appearance of Web Pages — Theming:</a></li>
80	<li><a href="custom_ticket.wiki"><b>Customizing The Ticket System</b></a></li>
81	<li><a href="customgraph.md">Customizing the Timeline Graph — Theming:</a></li>
82	<li><a href="tech_overview.wiki">Databases Used By Fossil — SQLite</a></li>
83	<li><a href="defcsp.md">Default Content Security Policy — The</a></li>
84	<li><a href="antibot.wiki"><b>Defense against Spiders and Bots</b></a></li>
85	<li><a href="shunning.wiki">Deleting Content From Fossil — Shunning:</a></li>
86	<li><a href="private.wiki">Deleting Private Branches — Creating, Syncing, and</a></li>
87	<li><a href="delta_encoder_algorithm.wiki">Delta Encoding Algorithm — Fossil</a></li>
88	<li><a href="delta_format.wiki">Delta Format — Fossil</a></li>
	@@ -148,11 +152,11 @@
152	<li><a href="hints.wiki">Hints — Fossil Tips And Usage</a></li>
153	<li><a href="index.wiki"><b>Home Page</b></a></li>
154	<li><a href="selfhost.wiki">Hosting Repositories — Fossil Self</a></li>
155	<li><a href="aboutcgi.wiki"><b>How CGI Works In Fossil</b></a></li>
156	<li><a href="aboutdownload.wiki"><b>How The Download Page Works</b></a></li>
157	<li><a href="server/"><b>How To Configure A Fossil Server</b></a></li>
158	<li><a href="newrepo.wiki"><b>How To Create A New Fossil Repository</b></a></li>
159	<li><a href="mirrortogithub.md"><b>How To Mirror A Fossil Repository On GitHub</b></a></li>
160	<li><a href="encryptedrepos.wiki"><b>How To Use Encrypted Repositories</b></a></li>
161	<li><a href="hacker-howto.wiki">How-To — Hacker</a></li>
162	<li><a href="tls-nginx.md">HTTPS with nginx — Proxying Fossil via</a></li>
	@@ -183,19 +187,21 @@
187	<li><a href="newrepo.wiki">New Fossil Repository — How To Create A</a></li>
188	<li><a href="tls-nginx.md">nginx — Proxying Fossil via HTTPS with</a></li>
189	<li><a href="alerts.md">Notifications — Email Alerts And</a></li>
190	<li><a href="foss-cklist.wiki">Open-Source Projects — Checklist For Successful</a></li>
191	<li><a href="pop.wiki">Operation — Principles Of</a></li>
192	<li><a href="cgi.wiki">Options — CGI Script Configuration</a></li>
193	<li><a href="env-opts.md">Options — Environment Variables and Global</a></li>
194	<li><a href="tech_overview.wiki">Overview Of The Design And Implementation Of Fossil — A Technical</a></li>
195	<li><a href="index.wiki">Page — Home</a></li>
196	<li><a href="aboutdownload.wiki">Page Works — How The Download</a></li>
197	<li><a href="customskin.md">Pages — Theming: Customizing The Appearance of Web</a></li>
198	<li><a href="password.wiki"><b>Password Management And Authentication</b></a></li>
199	<li><a href="globs.md">Patterns — File Name Glob</a></li>
200	<li><a href="quotes.wiki">People Are Saying About Fossil, Git, and DVCSes in General — Quotes: What</a></li>
201	<li><a href="stats.wiki"><b>Performance Statistics</b></a></li>
202	<li><a href="defcsp.md">Policy — The Default Content Security</a></li>
203	<li><a href="hashpolicy.wiki">Policy: Choosing Between SHA1 and SHA3-256 — Hash</a></li>
204	<li><a href="grep.md">POSIX grep — Fossil grep vs</a></li>
205	<li><a href="../test/release-checklist.wiki"><b>Pre-Release Testing Checklist</b></a></li>
206	<li><a href="pop.wiki"><b>Principles Of Operation</b></a></li>
207	<li><a href="private.wiki">Private Branches — Creating, Syncing, and Deleting</a></li>
	@@ -220,15 +226,17 @@
226	<li><a href="reviews.wiki"><b>Reviews</b></a></li>
227	<li><a href="../../../md_rules">Rules — Markdown Formatting</a></li>
228	<li><a href="../../../wiki_rules">Rules — Wiki Formatting</a></li>
229	<li><a href="fiveminutes.wiki">Running in 5 Minutes as a Single User — Up and</a></li>
230	<li><a href="quotes.wiki">Saying About Fossil, Git, and DVCSes in General — Quotes: What People Are</a></li>
231	<li><a href="cgi.wiki">Script Configuration Options — CGI</a></li>
232	<li><a href="th1.md">Scripting Language — The TH1</a></li>
233	<li><a href="serverext.wiki">Scripts — Adding Extensions To A Fossil Server Using CGI</a></li>
234	<li><a href="defcsp.md">Security Policy — The Default Content</a></li>
235	<li><a href="selfcheck.wiki">Self Checks — Fossil Repository Integrity</a></li>
236	<li><a href="selfhost.wiki">Self Hosting Repositories — Fossil</a></li>
237	<li><a href="server/">Server — How To Configure A Fossil</a></li>
238	<li><a href="serverext.wiki">Server Extensions — CGI</a></li>
239	<li><a href="serverext.wiki">Server Using CGI Scripts — Adding Extensions To A Fossil</a></li>
240	<li><a href="settings.wiki">Settings — Fossil</a></li>
241	<li><a href="admin-v-setup.md">Setup and Admin User Capabilities — The Differences Between the</a></li>
242	<li><a href="hashpolicy.wiki">SHA1 and SHA3-256 — Hash Policy: Choosing Between</a></li>
	@@ -254,10 +262,11 @@
262	<li><a href="tech_overview.wiki">Technical Overview Of The Design And Implementation Of Fossil — A</a></li>
263	<li><a href="../test/release-checklist.wiki">Testing Checklist — Pre-Release</a></li>
264	<li><a href="th1.md">TH1 Scripting Language — The</a></li>
265	<li><a href="backoffice.md"><b>The "Backoffice" mechanism of Fossil</b></a></li>
266	<li><a href="blame.wiki"><b>The Annotate/Blame Algorithm Of Fossil</b></a></li>
267	<li><a href="defcsp.md"><b>The Default Content Security Policy</b></a></li>
268	<li><a href="admin-v-setup.md"><b>The Differences Between the Setup and Admin User Capabilities</b></a></li>
269	<li><a href="makefile.wiki"><b>The Fossil Build Process</b></a></li>
270	<li><a href="sync.wiki"><b>The Fossil Sync Protocol</b></a></li>
271	<li><a href="tickets.wiki"><b>The Fossil Ticket System</b></a></li>
272	<li><a href="webui.wiki"><b>The Fossil Web Interface</b></a></li>
273

M www/quickstart.wiki

+6 -5

		--- www/quickstart.wiki
		+++ www/quickstart.wiki
		@@ -146,11 +146,11 @@
146	146	<h2>Configuring Your Local Repository</h2>
147	147
148	148	<p>When you create a new repository, either by cloning an existing
149	149	project or create a new project of your own, you usually want to do some
150	150	local configuration. This is easily accomplished using the web-server
151		- that is built into fossil. Start the fossil webserver like this:
	151	+ that is built into fossil. Start the fossil web server like this:
152	152	([/help/ui \| more info])</p>
153	153
154	154	<blockquote>
155	155	<b>fossil ui </b><i> repository-filename</i>
156	156	</blockquote>
		@@ -282,11 +282,11 @@
282	282	</blockquote>
283	283
284	284	<p>The argument to the [/help/merge\|merge] command can be any of the
285	285	version identifier forms that work for [/help/update\|update].
286	286	([./checkin_names.wiki\|more info].)
287		- The merge command has options to cherrypick individual
	287	+ The merge command has options to cherry-pick individual
288	288	changes, or to back out individual changes, if you don't want to
289	289	do a full merge.</p>
290	290
291	291	The merge command puts all changes in your working check-out.
292	292	No changes are made to the repository.
		@@ -338,13 +338,14 @@
338	338	server. For cross-machine collaboration, use the <b>server</b> command,
339	339	which binds on all IP addresses and does not try to start a web browser.</p>
340	340
341	341	<p>Servers are also easily configured as:
342	342	<ul>
343		- <li>[./server.wiki#inetd\|inetd/xinetd]
344		- <li>[./server.wiki#cgi\|CGI]
345		- <li>[./server.wiki#scgi\|SCGI]
	343	+ <li>[./server/any/inetd.md\|inetd]
	344	+ <li>[./server/debian/service.md\|systemd]
	345	+ <li>[./server/any/cgi.md\|CGI]
	346	+ <li>[./server/any/scgi.md\|SCGI]
346	347	</ul>
347	348
348	349	<p>The [./selfhost.wiki \| self-hosting fossil repositories] use
349	350	CGI.
350	351
351	352

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -146,11 +146,11 @@
146	<h2>Configuring Your Local Repository</h2>
147
148	<p>When you create a new repository, either by cloning an existing
149	project or create a new project of your own, you usually want to do some
150	local configuration. This is easily accomplished using the web-server
151	that is built into fossil. Start the fossil webserver like this:
152	([/help/ui \| more info])</p>
153
154	<blockquote>
155	<b>fossil ui </b><i> repository-filename</i>
156	</blockquote>
	@@ -282,11 +282,11 @@
282	</blockquote>
283
284	<p>The argument to the [/help/merge\|merge] command can be any of the
285	version identifier forms that work for [/help/update\|update].
286	([./checkin_names.wiki\|more info].)
287	The merge command has options to cherrypick individual
288	changes, or to back out individual changes, if you don't want to
289	do a full merge.</p>
290
291	The merge command puts all changes in your working check-out.
292	No changes are made to the repository.
	@@ -338,13 +338,14 @@
338	server. For cross-machine collaboration, use the <b>server</b> command,
339	which binds on all IP addresses and does not try to start a web browser.</p>
340
341	<p>Servers are also easily configured as:
342	<ul>
343	<li>[./server.wiki#inetd\|inetd/xinetd]
344	<li>[./server.wiki#cgi\|CGI]
345	<li>[./server.wiki#scgi\|SCGI]

346	</ul>
347
348	<p>The [./selfhost.wiki \| self-hosting fossil repositories] use
349	CGI.
350
351

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -146,11 +146,11 @@
146	<h2>Configuring Your Local Repository</h2>
147
148	<p>When you create a new repository, either by cloning an existing
149	project or create a new project of your own, you usually want to do some
150	local configuration. This is easily accomplished using the web-server
151	that is built into fossil. Start the fossil web server like this:
152	([/help/ui \| more info])</p>
153
154	<blockquote>
155	<b>fossil ui </b><i> repository-filename</i>
156	</blockquote>
	@@ -282,11 +282,11 @@
282	</blockquote>
283
284	<p>The argument to the [/help/merge\|merge] command can be any of the
285	version identifier forms that work for [/help/update\|update].
286	([./checkin_names.wiki\|more info].)
287	The merge command has options to cherry-pick individual
288	changes, or to back out individual changes, if you don't want to
289	do a full merge.</p>
290
291	The merge command puts all changes in your working check-out.
292	No changes are made to the repository.
	@@ -338,13 +338,14 @@
338	server. For cross-machine collaboration, use the <b>server</b> command,
339	which binds on all IP addresses and does not try to start a web browser.</p>
340
341	<p>Servers are also easily configured as:
342	<ul>
343	<li>[./server/any/inetd.md\|inetd]
344	<li>[./server/debian/service.md\|systemd]
345	<li>[./server/any/cgi.md\|CGI]
346	<li>[./server/any/scgi.md\|SCGI]
347	</ul>
348
349	<p>The [./selfhost.wiki \| self-hosting fossil repositories] use
350	CGI.
351
352

M www/selfhost.wiki

+1 -1

		--- www/selfhost.wiki
		+++ www/selfhost.wiki
		@@ -72,6 +72,6 @@
72	72	Server (2) is a
73	73	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
74	74	and set up just like the canonical server (1) with the addition of a
75	75	cron job for synchronization. The same cron job also runs the
76	76	[/help?cmd=git\|fossil git export] command after each sync in order to
77		-[./mirrortogithub.md\|mirror all changes to GitHub].
	77	+[./mirrortogithub.md#ex1\|mirror all changes to GitHub].
78	78
79	79	DELETED www/server.wiki
80	80	ADDED www/server/any/althttpd.md
81	81	ADDED www/server/any/cgi.md
82	82	ADDED www/server/any/inetd.md
83	83	ADDED www/server/any/none.md
84	84	ADDED www/server/any/scgi.md
85	85	ADDED www/server/any/stunnel.md
86	86	ADDED www/server/any/xinetd.md
87	87	ADDED www/server/debian/nginx.md
88	88	ADDED www/server/debian/service.md
89	89	ADDED www/server/index.html
90	90	ADDED www/server/macos/service.md
91	91	ADDED www/server/whyuseaserver.wiki
92	92	ADDED www/server/windows/cgi-bin-perm.png
93	93	ADDED www/server/windows/cgi-exec-perm.png
94	94	ADDED www/server/windows/cgi-install-iis.png
95	95	ADDED www/server/windows/cgi-script-map.png
96	96	ADDED www/server/windows/cgi.md
97	97	ADDED www/server/windows/iis.md
98	98	ADDED www/server/windows/index.md
99	99	ADDED www/server/windows/none.md
100	100	ADDED www/server/windows/service.md
101	101	ADDED www/server/windows/stunnel.md

	--- www/selfhost.wiki
	+++ www/selfhost.wiki
	@@ -72,6 +72,6 @@
72	Server (2) is a
73	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
74	and set up just like the canonical server (1) with the addition of a
75	cron job for synchronization. The same cron job also runs the
76	[/help?cmd=git\|fossil git export] command after each sync in order to
77	[./mirrortogithub.md\|mirror all changes to GitHub].
78
79	ELETED www/server.wiki
80	DDED www/server/any/althttpd.md
81	DDED www/server/any/cgi.md
82	DDED www/server/any/inetd.md
83	DDED www/server/any/none.md
84	DDED www/server/any/scgi.md
85	DDED www/server/any/stunnel.md
86	DDED www/server/any/xinetd.md
87	DDED www/server/debian/nginx.md
88	DDED www/server/debian/service.md
89	DDED www/server/index.html
90	DDED www/server/macos/service.md
91	DDED www/server/whyuseaserver.wiki
92	DDED www/server/windows/cgi-bin-perm.png
93	DDED www/server/windows/cgi-exec-perm.png
94	DDED www/server/windows/cgi-install-iis.png
95	DDED www/server/windows/cgi-script-map.png
96	DDED www/server/windows/cgi.md
97	DDED www/server/windows/iis.md
98	DDED www/server/windows/index.md
99	DDED www/server/windows/none.md
100	DDED www/server/windows/service.md
101	DDED www/server/windows/stunnel.md

	--- www/selfhost.wiki
	+++ www/selfhost.wiki
	@@ -72,6 +72,6 @@
72	Server (2) is a
73	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
74	and set up just like the canonical server (1) with the addition of a
75	cron job for synchronization. The same cron job also runs the
76	[/help?cmd=git\|fossil git export] command after each sync in order to
77	[./mirrortogithub.md#ex1\|mirror all changes to GitHub].
78
79	ELETED www/server.wiki
80	DDED www/server/any/althttpd.md
81	DDED www/server/any/cgi.md
82	DDED www/server/any/inetd.md
83	DDED www/server/any/none.md
84	DDED www/server/any/scgi.md
85	DDED www/server/any/stunnel.md
86	DDED www/server/any/xinetd.md
87	DDED www/server/debian/nginx.md
88	DDED www/server/debian/service.md
89	DDED www/server/index.html
90	DDED www/server/macos/service.md
91	DDED www/server/whyuseaserver.wiki
92	DDED www/server/windows/cgi-bin-perm.png
93	DDED www/server/windows/cgi-exec-perm.png
94	DDED www/server/windows/cgi-install-iis.png
95	DDED www/server/windows/cgi-script-map.png
96	DDED www/server/windows/cgi.md
97	DDED www/server/windows/iis.md
98	DDED www/server/windows/index.md
99	DDED www/server/windows/none.md
100	DDED www/server/windows/service.md
101	DDED www/server/windows/stunnel.md

D www/server.wiki

-149

		--- a/www/server.wiki
		+++ b/www/server.wiki
		@@ -1,149 +0,0 @@
1		-<title>her post-asqltitle>her post-activation steps includher poster post-activation steps is incl:</p>
2		-
3		-<ol>
4		-<li>
5		-Add addieam members have approp.</l].
6		-
7		-by to aData sharing and synchronization can be entirely peer-to-peer.
8		-Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
9		-to ensure that (in the limit) all participating peers see the exact same content.nding in
10		-"<tt>>
11		-sh2>But, A Server Can Be Useful is incl:</p>
12		-
13		-<ol>l>
14		-<li>
15		-Add addnot require a server,
16		-but a server does make collaboration easier.
17		-A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
18		-
19		-<ol>
20		-listener approachactivation: inetd, xinetdA stand-alone server
21		- <li>Using inetd, xinetd, or stunnel
22		- <li>CGI
23		- <li>SCGI (a.k.a. Simp [ \| a separate article].nding in
24		-"<tt>>
25		-
26		-<h2 id="inetd">Serving via inetd is incl:</p>
27		-
28		-<ol>
29		- See [hat all teYou can als \| this article].nding in
30		-"<tt>>
31		-
32		-<h2 id="sl.wiki#stunneleading,
33		-is just a Fossil server displaying the content of the
34		-=> with a also migrate fro
35		- ia-title="Howt This is the easiest wn also migrate fro
36		- ia-title="Howt This is the easieng in
37		-"<tt>>
38		-
39		-<h2 id="inetd">Serving via inetd is incl:</p>
40		-
41		-<ol>
42		- See [hat all teYou can als \| this article].nding in
43		-"<tt>>
44		-
45		-<h2 id="cgi">Serving via CGI is incl:</p>
46		-
47		-<ol>
48		- See [ \| this article].nding in
49		-"<tt>>
50		-
51		-<h2 id="scgi">Serving via SCGI is incl:</p>
52		-
53		-<ol>
54		- See [on standard output w \| this article].nding in
55		-"<tt>>
56		-debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
57		-ving via inetd is incl:</p>
58		-
59		-<ol>
60		-serverT is to use either the
61		-[/help/server\|server] or the [/help/ui\|ui] commands:
62		-
63		-<ul>
64		- <li><b>fossil server</b> <i>REPOSITORY</i>
65		- <li><b>fossil ui</b> <i>REPOSITORY</i>
66		-</ul>
67		-
68		-The <i>REPOSITORY</i> argument is either the name of the repository file, or
69		-a directorerving via inetd is incl:</p>
70		-
71		-named <tt>*.fossil</tt>.
72		-Both of these vation steps includher poster post-activation steps is incl:</p>
73		-
74		-<ol>
75		-<li>
76		-Add addieam members have approp.</l].
77		-
78		-by to aData sharing and synchronization can be entirely peer-to-peer.
79		-Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
80		-to ensure that (in the limit) all participating peers see the exact same content.nding in
81		-"<tt>>
82		-sh2>But, A Server Can Be Useful is incl:</p>
83		-
84		-<ol>l>
85		-<li>
86		-Add addnot require a server,
87		-but a server does make collaboration easier.
88		-A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
89		-
90		-<ol>
91		-listener approachactivation: inetd, xinetdA stand-alone server
92		- <li>Using inetd, xinetd, or stunnel
93		- <li>CGI
94		- <li>SCGI (a.k.a. Simp [ \| a separate article].nding in
95		-"<tt>>
96		-
97		-<h2 id="inetd">Serving via inetd is incl:</p>
98		-
99		-<ol>
100		- See [hat all teYou can als \| this article].nding in
101		-"<tt>>
102		-
103		-<h2 id="sl.wiki#stunneleading,
104		-is just a Fossil server displaying the content of the
105		-=> with a also migrate fro
106		- ia-title="Howt This is the easiest wn also migrate fro
107		- ia-title="Howt This is the easieng in
108		-"<tt>>
109		-
110		-<h2 id="inetd">Serving via inetd is incl:</p>
111		-
112		-<ol>
113		- See [hat all teYou can als \| this article].nding in
114		-"<tt>>
115		-
116		-<h2 id="cgi">Serving via CGI is incl:</p>
117		-
118		-<ol>
119		- See [ \| this article].nding in
120		-"<tt>>
121		-
122		-<h2 id="scgi">Serving via SCGI is incl:</p>
123		-
124		-<ol>
125		- See [on standard output w \| this article].nding in
126		-"<tt>>
127		-debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
128		-ving via inetd is incl:</p>
129		-
130		-<ol>
131		-serverT is to use either the
132		-[/help/server\|server] or the [/help/ui\|ui] commands:
133		-
134		-<ul>
135		- <li><b>fossil server</b> <i>REPOSITORY</i>
136		- <li><b>fossil ui</b> <i>REPOSITORY</i>
137		-</ul>
138		-
139		-The <i>REPOSITORY</i> argument is either the name of the repository file, or
140		-a directorerving via inetd is incl:</p>
141		-
142		-named <tt>*.fossil</tt>.
143		-Both of these commands start a Fossil server, usually on TCP port 8080, though
144		-a higher numbered port might also be used if 8080 is already occupied. You can
145		-access these using URLs of the form <b>http://localhost:8080/</b>, or if
146		-<i>REPOSITORY</i> is a directory, URLs of the form
147		-<b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is thedocumented in the
148		-source code. As of 2019-07-26, the available options are described at
149		-[/artifact/183cf5e5ad2ae111?ln=1912-1959\|main.c lines 1912 through 1959]

	--- a/www/server.wiki
	+++ b/www/server.wiki
	@@ -1,149 +0,0 @@
1	<title>her post-asqltitle>her post-activation steps includher poster post-activation steps is incl:</p>
2
3	<ol>
4	<li>
5	Add addieam members have approp.</l].
6
7	by to aData sharing and synchronization can be entirely peer-to-peer.
8	Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
9	to ensure that (in the limit) all participating peers see the exact same content.nding in
10	"<tt>>
11	sh2>But, A Server Can Be Useful is incl:</p>
12
13	<ol>l>
14	<li>
15	Add addnot require a server,
16	but a server does make collaboration easier.
17	A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
18
19	<ol>
20	listener approachactivation: inetd, xinetdA stand-alone server
21	<li>Using inetd, xinetd, or stunnel
22	<li>CGI
23	<li>SCGI (a.k.a. Simp [ \| a separate article].nding in
24	"<tt>>
25
26	<h2 id="inetd">Serving via inetd is incl:</p>
27
28	<ol>
29	See [hat all teYou can als \| this article].nding in
30	"<tt>>
31
32	<h2 id="sl.wiki#stunneleading,
33	is just a Fossil server displaying the content of the
34	=> with a also migrate fro
35	ia-title="Howt This is the easiest wn also migrate fro
36	ia-title="Howt This is the easieng in
37	"<tt>>
38
39	<h2 id="inetd">Serving via inetd is incl:</p>
40
41	<ol>
42	See [hat all teYou can als \| this article].nding in
43	"<tt>>
44
45	<h2 id="cgi">Serving via CGI is incl:</p>
46
47	<ol>
48	See [ \| this article].nding in
49	"<tt>>
50
51	<h2 id="scgi">Serving via SCGI is incl:</p>
52
53	<ol>
54	See [on standard output w \| this article].nding in
55	"<tt>>
56	debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
57	ving via inetd is incl:</p>
58
59	<ol>
60	serverT is to use either the
61	[/help/server\|server] or the [/help/ui\|ui] commands:
62
63	<ul>
64	<li><b>fossil server</b> <i>REPOSITORY</i>
65	<li><b>fossil ui</b> <i>REPOSITORY</i>
66	</ul>
67
68	The <i>REPOSITORY</i> argument is either the name of the repository file, or
69	a directorerving via inetd is incl:</p>
70
71	named <tt>*.fossil</tt>.
72	Both of these vation steps includher poster post-activation steps is incl:</p>
73
74	<ol>
75	<li>
76	Add addieam members have approp.</l].
77
78	by to aData sharing and synchronization can be entirely peer-to-peer.
79	Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
80	to ensure that (in the limit) all participating peers see the exact same content.nding in
81	"<tt>>
82	sh2>But, A Server Can Be Useful is incl:</p>
83
84	<ol>l>
85	<li>
86	Add addnot require a server,
87	but a server does make collaboration easier.
88	A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
89
90	<ol>
91	listener approachactivation: inetd, xinetdA stand-alone server
92	<li>Using inetd, xinetd, or stunnel
93	<li>CGI
94	<li>SCGI (a.k.a. Simp [ \| a separate article].nding in
95	"<tt>>
96
97	<h2 id="inetd">Serving via inetd is incl:</p>
98
99	<ol>
100	See [hat all teYou can als \| this article].nding in
101	"<tt>>
102
103	<h2 id="sl.wiki#stunneleading,
104	is just a Fossil server displaying the content of the
105	=> with a also migrate fro
106	ia-title="Howt This is the easiest wn also migrate fro
107	ia-title="Howt This is the easieng in
108	"<tt>>
109
110	<h2 id="inetd">Serving via inetd is incl:</p>
111
112	<ol>
113	See [hat all teYou can als \| this article].nding in
114	"<tt>>
115
116	<h2 id="cgi">Serving via CGI is incl:</p>
117
118	<ol>
119	See [ \| this article].nding in
120	"<tt>>
121
122	<h2 id="scgi">Serving via SCGI is incl:</p>
123
124	<ol>
125	See [on standard output w \| this article].nding in
126	"<tt>>
127	debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
128	ving via inetd is incl:</p>
129
130	<ol>
131	serverT is to use either the
132	[/help/server\|server] or the [/help/ui\|ui] commands:
133
134	<ul>
135	<li><b>fossil server</b> <i>REPOSITORY</i>
136	<li><b>fossil ui</b> <i>REPOSITORY</i>
137	</ul>
138
139	The <i>REPOSITORY</i> argument is either the name of the repository file, or
140	a directorerving via inetd is incl:</p>
141
142	named <tt>*.fossil</tt>.
143	Both of these commands start a Fossil server, usually on TCP port 8080, though
144	a higher numbered port might also be used if 8080 is already occupied. You can
145	access these using URLs of the form <b>http://localhost:8080/</b>, or if
146	<i>REPOSITORY</i> is a directory, URLs of the form
147	<b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is thedocumented in the
148	source code. As of 2019-07-26, the available options are described at
149	[/artifact/183cf5e5ad2ae111?ln=1912-1959\|main.c lines 1912 through 1959]

	--- a/www/server.wiki
	+++ b/www/server.wiki
	@@ -1,149 +0,0 @@

M www/server/any/althttpd.md

+37

		--- a/www/server/any/althttpd.md
		+++ b/www/server/any/althttpd.md
		@@ -0,0 +1,37 @@
	1	+# Serving via althttpd
	2	+
	3	+The public SQLite and Fossil web sites are not purely served by Fossil
	4	+for two reasons:
	5	+
	6	+1. We want access to these sites to be secured with TLS, which we do
	7	+ [via `stunnel`](./stunnel.md).
	8	+
	9	+2. Parts of these web sites are static, stored as plain files on disk,
	10	+ not as Fossil artifacts. We serve such files using a separate web
	11	+ server called [`althttpd`][ah], written by the primary author of
	12	+ both SQLite and Fossil, D. Richard Hipp. `althttpd` is a lightweight
	13	+ HTTP-only web server. It handles the static HTTP hits on
	14	+ <tt>sqlite.org</tt> and <tt>fossil-scm.org</tt>, delegating HTTPS
	15	+ hits to `stunnel` and dynamic content hits to Fossil [via
	16	+ CGI][cgi].
	17	+
	18	+The largest single chunk of static content served directly by `althttpd`
	19	+rather than via Fossil is the [SQLite documentation][sd], which is built
	20	+[from source files][ds]. We don’t want those output files stored in
	21	+Fossil; we already keep that process’s input files in Fossil. Thus the
	22	+choice to serve the output statically.
	23	+
	24	+In addition to the [server’s documentation page][ah], there is a large,
	25	+helpful header comment in the server’s [single-file C
	26	+implementation][ac]. Between that and the generic [Serving via CGI][cgi]
	27	+docs, you should be able to figure out how to serve Fossil via
	28	+`althttpd`.
	29	+
	30	+[Return to the top-level Fossil server article.](../)
	31	+
	32	+
	33	+[ac]: https://sqlite.org/docsrc/file/misc/althttpd.c
	34	+[ah]: https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md
	35	+[cgi]: ./cgi.md
	36	+[ds]: https://sqlite.org/docsrc/
	37	+[sd]: https://sqlite.org/docs.html

	--- a/www/server/any/althttpd.md
	+++ b/www/server/any/althttpd.md
	@@ -0,0 +1,37 @@

	--- a/www/server/any/althttpd.md
	+++ b/www/server/any/althttpd.md
	@@ -0,0 +1,37 @@
1	# Serving via althttpd
2
3	The public SQLite and Fossil web sites are not purely served by Fossil
4	for two reasons:
5
6	1. We want access to these sites to be secured with TLS, which we do
7	[via `stunnel`](./stunnel.md).
8
9	2. Parts of these web sites are static, stored as plain files on disk,
10	not as Fossil artifacts. We serve such files using a separate web
11	server called [`althttpd`][ah], written by the primary author of
12	both SQLite and Fossil, D. Richard Hipp. `althttpd` is a lightweight
13	HTTP-only web server. It handles the static HTTP hits on
14	<tt>sqlite.org</tt> and <tt>fossil-scm.org</tt>, delegating HTTPS
15	hits to `stunnel` and dynamic content hits to Fossil [via
16	CGI][cgi].
17
18	The largest single chunk of static content served directly by `althttpd`
19	rather than via Fossil is the [SQLite documentation][sd], which is built
20	[from source files][ds]. We don’t want those output files stored in
21	Fossil; we already keep that process’s input files in Fossil. Thus the
22	choice to serve the output statically.
23
24	In addition to the [server’s documentation page][ah], there is a large,
25	helpful header comment in the server’s [single-file C
26	implementation][ac]. Between that and the generic [Serving via CGI][cgi]
27	docs, you should be able to figure out how to serve Fossil via
28	`althttpd`.
29
30	[Return to the top-level Fossil server article.](../)
31
32
33	[ac]: https://sqlite.org/docsrc/file/misc/althttpd.c
34	[ah]: https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md
35	[cgi]: ./cgi.md
36	[ds]: https://sqlite.org/docsrc/
37	[sd]: https://sqlite.org/docs.html

M www/server/any/cgi.md

+10

		--- a/www/server/any/cgi.md
		+++ b/www/server/any/cgi.md
		@@ -0,0 +1,10 @@
	1	+# Serving via Sometime in# Serving via version 2.4# Serving via In version 2.4.59# Serving Fossil server can be run f
	2	+the Content-Length headeWe use CGI for t in the HTTP reply from CGIs back to client
	3	+```
	4	+<Directory ...>
	5	+<ontent-Length header in the HTTP reply from CGIs back to client
	6	+```
	7	+<Directory ...>
	8	+</Directory>
	9	+```
	10	+# Serving via Sometim

	--- a/www/server/any/cgi.md
	+++ b/www/server/any/cgi.md
	@@ -0,0 +1,10 @@

	--- a/www/server/any/cgi.md
	+++ b/www/server/any/cgi.md
	@@ -0,0 +1,10 @@
1	# Serving via Sometime in# Serving via version 2.4# Serving via In version 2.4.59# Serving Fossil server can be run f
2	the Content-Length headeWe use CGI for t in the HTTP reply from CGIs back to client
3	```
4	<Directory ...>
5	<ontent-Length header in the HTTP reply from CGIs back to client
6	```
7	<Directory ...>
8	</Directory>
9	```
10	# Serving via Sometim

M www/server/any/inetd.md

+16

		--- a/www/server/any/inetd.md
		+++ b/www/server/any/inetd.md
		@@ -0,0 +1,16 @@
	1	+# Serving via inetd
	2	+
	3	+A Fossil server can be launched on-demand by `inetd` by using the
	4	+[`fossil http`](/help/http) command. To do so, add a line like the
	5	+following to its configuration file, typically `/etc/inetd.conf`:
	6	+
	7	+ 80 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /home/fossil/repo.fossil
	8	+
	9	+In this example, you are telling `inetd` that when an incoming
	10	+connection appears on TCP port 80 that it should launch the program
	11	+`/usr/bin/fossil` with the arguments shown. Obviously you will need to
	12	+modify the pathnames for your particular setup. The final argument is
	13	+either the name of the fossil repository to be served or a directory
	14	+containing multiple repositories.
	15	+
	16	+If you use a

	--- a/www/server/any/inetd.md
	+++ b/www/server/any/inetd.md
	@@ -0,0 +1,16 @@

	--- a/www/server/any/inetd.md
	+++ b/www/server/any/inetd.md
	@@ -0,0 +1,16 @@
1	# Serving via inetd
2
3	A Fossil server can be launched on-demand by `inetd` by using the
4	[`fossil http`](/help/http) command. To do so, add a line like the
5	following to its configuration file, typically `/etc/inetd.conf`:
6
7	80 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /home/fossil/repo.fossil
8
9	In this example, you are telling `inetd` that when an incoming
10	connection appears on TCP port 80 that it should launch the program
11	`/usr/bin/fossil` with the arguments shown. Obviously you will need to
12	modify the pathnames for your particular setup. The final argument is
13	either the name of the fossil repository to be served or a directory
14	containing multiple repositories.
15
16	If you use a

M www/server/any/none.md

+41

		--- a/www/server/any/none.md
		+++ b/www/server/any/none.md
		@@ -0,0 +1,41 @@
	1	+# Standalone HTTP Server
	2	+
	3	+The easiest way to set up a Fossil server is to use either the
	4	+[`server`](/help/server) or [`ui`](/help/ui) command:
	5	+
	6	+* fossil server _REPOSITORY_
	7	+* fossil ui _REPOSITORY_
	8	+
	9	+The _REPOSITORY_ argument is either the name of the repository file or a
	10	+directory containing many repositories named “`*.fossil`”. Both of these
	11	+commands start a Fossil server, usually on TCP port 8080, though a
	12	+higher numbered port will be used instead if 8080 is already occupied.
	13	+
	14	+You can access these using URLs of the form http://localhost:8080/,
	15	+or if _REPOSITORY_ is a directory, URLs of the form
	16	+http://localhost:8080/_repo_/ where _repo_ is the base name of
	17	+the repository file without the “`.fossil`” suffix.
	18	+
	19	+There are several key differences between “`ui`” and “`server`”:
	20	+
	21	+* “`ui`” always binds the server to the loopback IP address (127.0.0.1)
	22	+ so that it cannot serve to other machines.
	23	+
	24	+* Anyone who visits this URL is treated as the all-powerful Setup
	25	+ user, which is why th first difference exists.
	26	+
	27	+* “`ui`” launches a local web browser pointed at this URL.
	28	+
	29	+You can omit the _REPOSITORY_ argument if you run one of the above
	30	+commands from within a Fossil checkout directory to s $ foss# Standalone HTTP Server
	31	+
	32	+The easiest way to set up a Fossil server is to use either the
	33	+[`server`](/help/server) or [`ui`](/help/ui) command:
	34	+
	35	+* fossil server _REPOSITORY_
	36	+* fossil ui _REPOSITORY_
	37	+
	38	+The _REPOSITORY_ argument is either the name of the repository file or a
	39	+directory containing many repositories named “`*.fossil`”. Both of these
	40	+commands start a Fossil server, usually on TCP port 8080, though a
	41	+higher numbered port will be use

	--- a/www/server/any/none.md
	+++ b/www/server/any/none.md
	@@ -0,0 +1,41 @@

	--- a/www/server/any/none.md
	+++ b/www/server/any/none.md
	@@ -0,0 +1,41 @@
1	# Standalone HTTP Server
2
3	The easiest way to set up a Fossil server is to use either the
4	[`server`](/help/server) or [`ui`](/help/ui) command:
5
6	* fossil server _REPOSITORY_
7	* fossil ui _REPOSITORY_
8
9	The _REPOSITORY_ argument is either the name of the repository file or a
10	directory containing many repositories named “`*.fossil`”. Both of these
11	commands start a Fossil server, usually on TCP port 8080, though a
12	higher numbered port will be used instead if 8080 is already occupied.
13
14	You can access these using URLs of the form http://localhost:8080/,
15	or if _REPOSITORY_ is a directory, URLs of the form
16	http://localhost:8080/_repo_/ where _repo_ is the base name of
17	the repository file without the “`.fossil`” suffix.
18
19	There are several key differences between “`ui`” and “`server`”:
20
21	* “`ui`” always binds the server to the loopback IP address (127.0.0.1)
22	so that it cannot serve to other machines.
23
24	* Anyone who visits this URL is treated as the all-powerful Setup
25	user, which is why th first difference exists.
26
27	* “`ui`” launches a local web browser pointed at this URL.
28
29	You can omit the _REPOSITORY_ argument if you run one of the above
30	commands from within a Fossil checkout directory to s $ foss# Standalone HTTP Server
31
32	The easiest way to set up a Fossil server is to use either the
33	[`server`](/help/server) or [`ui`](/help/ui) command:
34
35	* fossil server _REPOSITORY_
36	* fossil ui _REPOSITORY_
37
38	The _REPOSITORY_ argument is either the name of the repository file or a
39	directory containing many repositories named “`*.fossil`”. Both of these
40	commands start a Fossil server, usually on TCP port 8080, though a
41	higher numbered port will be use

M www/server/any/scgi.md

+18

		--- a/www/server/any/scgi.md
		+++ b/www/server/any/scgi.md
		@@ -0,0 +1,18 @@
	1	+# Serving via SCGI
	2	+
	3	+There examplexamplexamplexamplram HTTPS "on";
	4	+ }
	5	+
	6	+Start Fossil so that it will respond to nginx’s SCG
	7	+
	8	+ 12@NB,Bh@OF,8V:Fossil requires the `SCRIPT_NAME` environment variable in order to
	9	+function properly, but nginx does not provide this variable by default,
	10	+so it is necessary to provide it in the configuration. Failure to do
	11	+this will cause Fossil to return an error.
	12	+
	13	+The [example `fslsrv` script](/file/tools/fslsrv) shows off these same
	14	+concepts in a more complicated setting. You might want to mine that
	15	+script for ideas.
	16	+
	17	+You might want to next read one of the platform-specific versions of this
	18	+document, which goes

	--- a/www/server/any/scgi.md
	+++ b/www/server/any/scgi.md
	@@ -0,0 +1,18 @@

	--- a/www/server/any/scgi.md
	+++ b/www/server/any/scgi.md
	@@ -0,0 +1,18 @@
1	# Serving via SCGI
2
3	There examplexamplexamplexamplram HTTPS "on";
4	}
5
6	Start Fossil so that it will respond to nginx’s SCG
7
8	12@NB,Bh@OF,8V:Fossil requires the `SCRIPT_NAME` environment variable in order to
9	function properly, but nginx does not provide this variable by default,
10	so it is necessary to provide it in the configuration. Failure to do
11	this will cause Fossil to return an error.
12
13	The [example `fslsrv` script](/file/tools/fslsrv) shows off these same
14	concepts in a more complicated setting. You might want to mine that
15	script for ideas.
16
17	You might want to next read one of the platform-specific versions of this
18	document, which goes

M www/server/any/stunnel.md

+34

		--- a/www/server/any/stunnel.md
		+++ b/www/server/any/stunnel.md
		@@ -0,0 +1,34 @@
	1	+# Serving via stunnel
	2	+
	3	+[`stunnel`](https://www.stunnel.org/) is a TLS/SSL proxy for programs
	4	+that themselves serve only via HTTP, such as Fossil. (Fossil can speak
	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
	24	+ TIMEOUTclose = 0
	25	+ exec = /usr/bin/fossil
	26	+ execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
	27	+ cert = /etc/letsencrypt/live/ubercool-project.org/fullchain.pem
	28	+ key = /etc/letsencrypt/live/ubercool-project.org/privkey.pem
	29	+ ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA
	30	+ options = CIPHER_SERVER_PREFERENCE
	31	+```
	32	+
	33	+This configuration shows the TLS certificate generated by the [Let’s
	34	+Encrypt](https://letsencrypt.org) [Certbot](https://certbot.eff.or

	--- a/www/server/any/stunnel.md
	+++ b/www/server/any/stunnel.md
	@@ -0,0 +1,34 @@

	--- a/www/server/any/stunnel.md
	+++ b/www/server/any/stunnel.md
	@@ -0,0 +1,34 @@
1	# Serving via stunnel
2
3	[`stunnel`](https://www.stunnel.org/) is a TLS/SSL proxy for programs
4	that themselves serve only via HTTP, such as Fossil. (Fossil can speak
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
24	TIMEOUTclose = 0
25	exec = /usr/bin/fossil
26	execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
27	cert = /etc/letsencrypt/live/ubercool-project.org/fullchain.pem
28	key = /etc/letsencrypt/live/ubercool-project.org/privkey.pem
29	ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA
30	options = CIPHER_SERVER_PREFERENCE
31	```
32
33	This configuration shows the TLS certificate generated by the [Let’s
34	Encrypt](https://letsencrypt.org) [Certbot](https://certbot.eff.or

M www/server/any/xinetd.md

+26

		--- a/www/server/any/xinetd.md
		+++ b/www/server/any/xinetd.md
		@@ -0,0 +1,26 @@
	1	+# Serving via xinetd
	2	+
	3	+Some operating systems have replaced the old Unix `inetd` daemon with
	4	+`xinetd`, which has a similar mission but with a very different
	5	+configuration file format.
	6	+
	7	+The typical configuration file is either `/etc/xinetd.conf` or a subfile
	8	+in the `/etc/xinetd.d` directory. You need a configuration something
	9	+like this for Fossil:
	10	+
	11	+ service http
	12	+ {
	13	+ port = 80
	14	+ socket_type = stream
	15	+ wait = no
	16	+ e = stream
	17	+ wait = server = /usr/bin/fossil
	18	+ server_args = ht }
	19	+
	20	+This example configures Fossil to serve multiple repositories under the
	21	+`/home/fossil/repos/` directory.
	22	+
	23	+Beyond this, see the general commentary in our article on [the `inetd`
	24	+method](./inetd.md) as they also apply to service via `xinetd`.
	25	+
	26	+*[Return to the top-level Fos

	--- a/www/server/any/xinetd.md
	+++ b/www/server/any/xinetd.md
	@@ -0,0 +1,26 @@

	--- a/www/server/any/xinetd.md
	+++ b/www/server/any/xinetd.md
	@@ -0,0 +1,26 @@
1	# Serving via xinetd
2
3	Some operating systems have replaced the old Unix `inetd` daemon with
4	`xinetd`, which has a similar mission but with a very different
5	configuration file format.
6
7	The typical configuration file is either `/etc/xinetd.conf` or a subfile
8	in the `/etc/xinetd.d` directory. You need a configuration something
9	like this for Fossil:
10
11	service http
12	{
13	port = 80
14	socket_type = stream
15	wait = no
16	e = stream
17	wait = server = /usr/bin/fossil
18	server_args = ht }
19
20	This example configures Fossil to serve multiple repositories under the
21	`/home/fossil/repos/` directory.
22
23	Beyond this, see the general commentary in our article on [the `inetd`
24	method](./inetd.md) as they also apply to service via `xinetd`.
25
26	*[Return to the top-level Fos

M www/server/debian/nginx.md

+105

		--- a/www/server/debian/nginx.md
		+++ b/www/server/debian/nginx.md
		@@ -0,0 +1,105 @@
	1	+# S generic;
	2	+
	3	+ S# S# S }
	4	+ # Redirect everything els }
	5	+ }T is
	6	+We focus
	7	+Ubuntu 20.04 here, which a
	8	+private servers][vpadding TLS access
	9	+ supports
	10	+TLS. One such option is nginx on Debian, so we show the details of that
	11	+here.
	12	+
	13	+You can extend this guide to other operating systems by following the
	14	+instructions fou18 via [the front Certbot web page][c;
	15	+
	16	+ S# S# S }
	17	+ # Redirect everything els ls }
	18	+ }T is
	19	+# S generic;
	20	+
	21	+ S# S# S }
	22	+ # Redirect everything If you want to add TLS to this configuration, that is covered [in a
	23	+separate document][tls] which was written with the assumption that
	24	+you’ve read this firstnfused Certbot, so we had totls]: ../../tls-nginxs manually](#lehw),
	25	+else the Let’s Encrypt [ACME] exchange failed in thenameecessary domain
	26	+validation steps.
	27	+
	28	+At this point, if# S generic;
	29	+
	30	+ S# S# S }
	31	+ # Redirect everything els }
	32	+ }T is
	33	+
	34	+
	35	+ $ sudo snap install --classic certbot
	36	+ $ sudo systemctl disable certbot.timer
	37	+
	38	+Next, edit `H@3AF,50:renewal/example.com.conf` to disable the
	39	+nginx plugins. You’re looking for two lines setting the “install” and
	40	+“auth” plugins to “nginx”. You can comment them out or remove them
	41	+entirely.
	42	+
	43	+
	44	+#### Step 2: Configuring nginx
	45	+
	46	+This is a straightforward extension to the HTTP/help/serveration
	47	+[above](#config)e@1X4,9:foo.net;
	48	+P@1Y9,_:tls-common;
	49	+
	50	+ charset utf-8c@this
	51	+ option is overkill for our purposes. nginx is itself a fully
	52	+ featured HTTP server, so we will choose in this guide not to make
	53	+ S generic;
	54	+
	55	+ S# S# S }
	56	+ ic;
	57	+
	58	+ S# S# S }
	59	+ #.I run my Fossil SCGI server instances with a variant of [the `fslsrv`
	60	+shell currently hosted in the Fossil source
	61	+code repository. You’ll want to download that and make a copy of it, so
	62	+you can customize it to your particular needSCGI servers, one per
	63	+repository, each bound to a different high-numbered `localhost` port, so
	64	+that only nginx can see and proxy them out to the public. The
	65	+“`example`” repo is on TCP port localhost:12345, and the “`foo`” repo is
	66	+on localhost:12346.
	67	+
	68	+As written, the `fslsrv` script expects repositories to be stored in the
	69	+calling user’s home directory under `~/museum`, because where else do
	70	+you keep Fossils?
	71	+
	72	+That home directory also needs to have a directory to hold log files,
	73	+`~/log/fossil/*.log`. Fossil doesn’t put out much logging, but when it
	74	+does, it’s better to have it captured than to need to re-create the
	75	+problem after the fact.
	76	+
	77	+The use of `--baseurl` in this script lets us have each Fossil
	78	+repository mounted in a different location in the URL scheme. Here, for
	79	+example, we’re saying that the “`example`” repository is hosted under
	80	+the `/code` URI on its domains, but that the “`foo`” repo is hosted at
	81	+the top level of its domain. You’ll want to do something like the
	82	+former for a Fossil repo that’s just one piece of a larger site, but the
	83	+latter for a repo that is basically the whole point of the site.
	84	+
	85	+You might also want another script to automate the update, build, and
	86	+deployment steps for new Fossil versions:
	87	+
	88	+ #!/bin/sh
	89	+ fossil up
	90	+ make -j11
	91	+ killall fossil
	92	+ sudo make install
	93	+ fslsrv
	94	+
	95	+The `killall fossil` step is needed only on OSes that refuse to let you
	96	+replace a running binary on disk.
	97	+
	98	+As written, the `fslsrv` script assumes a Linux environment. It expects
	99	+`/bin/bash` to exist, and it depends on non-POSIX tools like `pgrep`.
	100	+It should not be difficult to port to systems like macOS or the BSDs` contains thfoo.netT is
	101	+We focus
	102	+Ubuntu 20.04 # Sfoo.net;
	103	+foo.netfoo.netDoxygen docsfoo.net scgi_param HTTPS "on"";
	104	+ simpleedirect everything he public. The
	105	+“`example`”

	--- a/www/server/debian/nginx.md
	+++ b/www/server/debian/nginx.md
	@@ -0,0 +1,105 @@

	--- a/www/server/debian/nginx.md
	+++ b/www/server/debian/nginx.md
	@@ -0,0 +1,105 @@
1	# S generic;
2
3	S# S# S }
4	# Redirect everything els }
5	}T is
6	We focus
7	Ubuntu 20.04 here, which a
8	private servers][vpadding TLS access
9	supports
10	TLS. One such option is nginx on Debian, so we show the details of that
11	here.
12
13	You can extend this guide to other operating systems by following the
14	instructions fou18 via [the front Certbot web page][c;
15
16	S# S# S }
17	# Redirect everything els ls }
18	}T is
19	# S generic;
20
21	S# S# S }
22	# Redirect everything If you want to add TLS to this configuration, that is covered [in a
23	separate document][tls] which was written with the assumption that
24	you’ve read this firstnfused Certbot, so we had totls]: ../../tls-nginxs manually](#lehw),
25	else the Let’s Encrypt [ACME] exchange failed in thenameecessary domain
26	validation steps.
27
28	At this point, if# S generic;
29
30	S# S# S }
31	# Redirect everything els }
32	}T is
33
34
35	$ sudo snap install --classic certbot
36	$ sudo systemctl disable certbot.timer
37
38	Next, edit `H@3AF,50:renewal/example.com.conf` to disable the
39	nginx plugins. You’re looking for two lines setting the “install” and
40	“auth” plugins to “nginx”. You can comment them out or remove them
41	entirely.
42
43
44	#### Step 2: Configuring nginx
45
46	This is a straightforward extension to the HTTP/help/serveration
47	[above](#config)e@1X4,9:foo.net;
48	P@1Y9,_:tls-common;
49
50	charset utf-8c@this
51	option is overkill for our purposes. nginx is itself a fully
52	featured HTTP server, so we will choose in this guide not to make
53	S generic;
54
55	S# S# S }
56	ic;
57
58	S# S# S }
59	#.I run my Fossil SCGI server instances with a variant of [the `fslsrv`
60	shell currently hosted in the Fossil source
61	code repository. You’ll want to download that and make a copy of it, so
62	you can customize it to your particular needSCGI servers, one per
63	repository, each bound to a different high-numbered `localhost` port, so
64	that only nginx can see and proxy them out to the public. The
65	“`example`” repo is on TCP port localhost:12345, and the “`foo`” repo is
66	on localhost:12346.
67
68	As written, the `fslsrv` script expects repositories to be stored in the
69	calling user’s home directory under `~/museum`, because where else do
70	you keep Fossils?
71
72	That home directory also needs to have a directory to hold log files,
73	`~/log/fossil/*.log`. Fossil doesn’t put out much logging, but when it
74	does, it’s better to have it captured than to need to re-create the
75	problem after the fact.
76
77	The use of `--baseurl` in this script lets us have each Fossil
78	repository mounted in a different location in the URL scheme. Here, for
79	example, we’re saying that the “`example`” repository is hosted under
80	the `/code` URI on its domains, but that the “`foo`” repo is hosted at
81	the top level of its domain. You’ll want to do something like the
82	former for a Fossil repo that’s just one piece of a larger site, but the
83	latter for a repo that is basically the whole point of the site.
84
85	You might also want another script to automate the update, build, and
86	deployment steps for new Fossil versions:
87
88	#!/bin/sh
89	fossil up
90	make -j11
91	killall fossil
92	sudo make install
93	fslsrv
94
95	The `killall fossil` step is needed only on OSes that refuse to let you
96	replace a running binary on disk.
97
98	As written, the `fslsrv` script assumes a Linux environment. It expects
99	`/bin/bash` to exist, and it depends on non-POSIX tools like `pgrep`.
100	It should not be difficult to port to systems like macOS or the BSDs` contains thfoo.netT is
101	We focus
102	Ubuntu 20.04 # Sfoo.net;
103	foo.netfoo.netDoxygen docsfoo.net scgi_param HTTPS "on"";
104	simpleedirect everything he public. The
105	“`example`”

M www/server/debian/service.md

+14

		--- a/www/server/debian/service.md
		+++ b/www/server/debian/service.md
		@@ -0,0 +1,14 @@
	1	+#A simple and useful modification to the above scheme is to add the
	2	+`--scgi` and `--localhost` flags to the `ExecStart` line to replace the
	3	+use of `fslsrv` in(../any/scgi.md)sockets.target-lAnother workaround for the problem with user services above is to
	4	+install the service as a systeminstead. This , such as
	5	+[nginx](./nginx.md)sockets.targetrably one as a
	6	+user service #A simple and useful modification to the above scheme is to add the
	7	+`--scgi` and `--localhost` flags to the `ExecStart` line to replace the
	8	+use of `fslsrv` in(../any/scgi.md)sockets.target-lAnother workaround for the problem with user services above is to
	9	+install the service as a systeminstead. This , such as
	10	+[nginx](./nginx.md)sockets.targetrably one useful modification to the above scheme is to add the
	11	+`--scgi` and `--localhost` flags to the `ExecStart` line to replace the
	12	+use of `fslsrv` in(../any/scgi.md)sockets.target-lAnother workaround for the problem with user services above is to
	13	+install the service as a systeminstead. This , such as
	14	+[nginx](./nginx.md)sockets.targetrably one

	--- a/www/server/debian/service.md
	+++ b/www/server/debian/service.md
	@@ -0,0 +1,14 @@

	--- a/www/server/debian/service.md
	+++ b/www/server/debian/service.md
	@@ -0,0 +1,14 @@
1	#A simple and useful modification to the above scheme is to add the
2	`--scgi` and `--localhost` flags to the `ExecStart` line to replace the
3	use of `fslsrv` in(../any/scgi.md)sockets.target-lAnother workaround for the problem with user services above is to
4	install the service as a systeminstead. This , such as
5	[nginx](./nginx.md)sockets.targetrably one as a
6	user service #A simple and useful modification to the above scheme is to add the
7	`--scgi` and `--localhost` flags to the `ExecStart` line to replace the
8	use of `fslsrv` in(../any/scgi.md)sockets.target-lAnother workaround for the problem with user services above is to
9	install the service as a systeminstead. This , such as
10	[nginx](./nginx.md)sockets.targetrably one useful modification to the above scheme is to add the
11	`--scgi` and `--localhost` flags to the `ExecStart` line to replace the
12	use of `fslsrv` in(../any/scgi.md)sockets.target-lAnother workaround for the problem with user services above is to
13	install the service as a systeminstead. This , such as
14	[nginx](./nginx.md)sockets.targetrably one

M www/server/index.html

+112 -135

		--- a/www/server/index.html
		+++ b/www/server/index.html
		@@ -1,149 +1,126 @@
1		-<title>her post-asqltitle>her post-activation steps includher poster post-activation steps is incl:</p>
	1	+ia-title="How To Configure A Fossil Server">
	2	+
	3	+<style type="text/css">
	4	+ p {
	5	+ margin-left: 4em;
	6	+ margin-right: 3em;
	7	+ }
	8	+
	9	+ li p {
	10	+ margin-left: 0;h2n evenPI to give it an evenPI
	11	+Prior to launching a server on, it is best to
	12	+prepareto be served. The easiest wacommand
	13	+on a workstation and then visit the "Setup" menu.
	14	+Minimum preparation actions include:</p>
2	15
3	16	<ol>
4	17	<li>
5		-Add addieam members have approp.</l].
	18	+Ensure that you have an administrator user account and password
	19	+configured. Visit the Setup/Users page to accomplish this.</p></li>
	20	+<li>
	21	+Visit the Setup/Security-Audit pageYou might want to configureto be completely private
	22	+for the initial upload and server activatation, then open access up to
	23	+post-activation configuration refinement</a>
	24	+stage.
	25	+</p></li>
	26	+</ol>
6	27
7		-by to aData sharing and synchronization can be entirely peer-to-peer.
8		-Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
9		-to ensure that (in the limit) all participating peers see the exact same content.nding in
10		-"<tt>>
11		-sh2>But, A Server Can Be Useful is incl:</p>
	28	+<p>
	29	+Additional configuration can be accomplished after the server is up
	30	+and running. Once the prvery useful</a>.</p>trator
	31	+and visiting the Setup menu. Pay particular attention to the
	32	+"Setup/Sec
	33	+configured the
	34	+want to keep private. Other post-activation steps include the follodditionalmethods">.
	35	+</p></li>
	36	+</ol>
12	37
13		-<ol>l>
14		-<li>
15		-Add addnot require a server,
16		-but a server does make collaboration easier.
17		-A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
18		-
19		-<ol>
20		-listener approachactivation: inetd, xinetdA stand-alone server
21		- <li>Using inetd, xinetd, or stunnel
22		- <li>CGI
23		- <li>SCGI (a.k.a. Simp [ \| a separate article].nding in
24		-"<tt>>
25		-
26		-<h2 id="inetd">Serving via inetd is incl:</p>
27		-
28		-<ol>
29		- See [hat all teYou can als \| this article].nding in
30		-"<tt>>
31		-
32		-<h2 id="sl.wiki#stunneleading,
33		-is just a Fossil server displaying the content of the
34		-=> with a also migrate fro
35		- ia-title="Howt This is the easiest wn also migrate fro
36		- ia-title="Howt This is the easieng in
37		-"<tt>>
38		-
39		-<h2 id="inetd">Serving via inetd is incl:</p>
40		-
41		-<ol>
42		- See [hat all teYou can als \| this article].nding in
43		-"<tt>>
44		-
45		-<h2 id="cgi">Serving via CGI is incl:</p>
46		-
47		-<ol>
48		- See [ \| this article].nding in
49		-"<tt>>
50		-
51		-<h2 id="scgi">Serving via SCGI is incl:</p>
52		-
53		-<ol>
54		- See [on standard output w \| this article].nding in
55		-"<tt>>
56		-debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
57		-ving via inetd is incl:</p>
58		-
59		-<ol>
60		-serverT is to use either the
61		-[/help/server\|server] or the [/help/ui\|ui] commands:
62		-
63		-<ul>
64		- <li><b>fossil server</b> <i>REPOSITORY</i>
65		- <li><b>fossil ui</b> <i>REPOSITORY</i>
66		-</ul>
67		-
68		-The <i>REPOSITORY</i> argument is either the name of the repository file, or
69		-a directorerving via inetd is incl:</p>
70		-
71		-named <tt>*.fossil</tt>.
72		-Both of these vation steps includher poster post-activation steps is incl:</p>
	38	+<p>
	39	+set upe accomplished after the server is up
	40	+and running. Once the preliminary configuration is completed
	41	+uploaddatabaand proceed to
	42	+activate the server using one or more of the techniques dSnext two sectiiques described
	43	+in the next two sections.
	44	+</p>additional configuration
	45	+fine-tuning can be accomplished by logging in as an administrator
	46	+containing repositorieusing a single methodconfigured the
	47	+want to keep private. Other post-activation steps include the following:</p>
73	48
74	49	<ol>
75	50	<li>
76		-Add addieam members have approp.</l].
	51	+Add additional users accounts so that all team members have approp.</li>
	52	+<li>
	53	+Modify the look-and-feel of site by to accommodatedocumentation</a> then perhaps activate the s feature so that
	54	+visitors can doin-left: 0;
	55	+ ia-title="Howto an email server so that it can send email
	56	+notifications of new check-ins or other activate.
	57	+<li>
77	58
78		-by to aData sharing and synchronization can be entirely peer-to-peer.
79		-Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
80		-to ensure that (in the limit) all participating peers see the exact same content.nding in
81		-"<tt>>
82		-sh2>But, A Server Can Be Useful is incl:</p>
	59	+<li>
	60	+If you locked downas completely private prior to
	61	+upload, you might want to open up access to the public once you get
	62	+everything working. Or, keepprivate, according to
	63	+your needs.
	64	+</ol>
83	65
84		-<ol>l>
85		-<li>
86		-Add addnot require a server,
87		-but a server does make collaboration easier.
88		-A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
	66	+<p>
	67	+Afte,t</a>
	68	+stage.
	69	+</p></li>
	70	+</ol>
	71	+
	72	+<p>
	73	+Additional configuration can be accthe script runs Fossil to
	74	+appropriate URL, thatafter the server is up
	75	+and running. w To Configure A Fossil Server">
	76	+
	77	+<style type="text/css">
	78	+ p {
	79	+ margin-left: 4em;
	80	+ margin-right: 3em;
	81	+ }
	82	+
	83	+ li p {
	84	+ margin-left: 0;h2n evenPI to give it an evenPI
	85	+Prior to launching a server on, it is best to
	86	+prepareto be served. The easiest wacommand
	87	+on a workstation and then visit the "Setup" menu.
	88	+Minimum preparation actia-title="How To Configure A Fossil Server">
	89	+
	90	+<style type="text/css">
	91	+ p {
	92	+ margin-left: 4em;
	93	+ margin-right: 3em;
	94	+ }
	95	+
	96	+ li p {
	97	+ margin-left: 0;h2n evenPI to give it an evenPI
	98	+Prior to launching a server on, it is best to
	99	+prepareto be served. The easiest wacommand
	100	+on a workstation and then visit the "Setup" menu.
	101	+Minimum preparation actions include:</p>
89	102
90	103	<ol>
91		-listener approachactivation: inetd, xinetdA stand-alone server
92		- <li>Using inetd, xinetd, or stunnel
93		- <li>CGI
94		- <li>SCGI (a.k.a. Simp [ \| a separate article].nding in
95		-"<tt>>
	104	+<li>
	105	+Ensure that you have an administrator user account and password
	106	+configured. Visit the Setup/Users page to accomplish this.</p></li>
	107	+<li>
	108	+Vi <a
	109	+documentation</a> then perhaps activate the s feature so that
	110	+visitors can doin-left: 0;
	111	+ ia-title="Howto an email server so that it can send email
	112	+notifications of new check-ins or other activate.
	113	+<li>
96	114
97		-<h2 id="inetd">Serving via inetd is incl:</p>
	115	+<li>
	116	+If you locked downas completely private prior to
	117	+upload, you might want to open up access to the public once you get
	118	+everything working. Or, keepprivate, according to
	119	+your needs.
	120	+</ol>
98	121
99		-<ol>
100		- See [hat all teYou can als \| this article].nding in
101		-"<tt>>
102		-
103		-<h2 id="sl.wiki#stunneleading,
104		-is just a Fossil server displaying the content of the
105		-=> with a also migrate fro
106		- ia-title="Howt This is the easiest wn also migrate fro
107		- ia-title="Howt This is the easieng in
108		-"<tt>>
109		-
110		-<h2 id="inetd">Serving via inetd is incl:</p>
111		-
112		-<ol>
113		- See [hat all teYou can als \| this article].nding in
114		-"<tt>>
115		-
116		-<h2 id="cgi">Serving via CGI is incl:</p>
117		-
118		-<ol>
119		- See [ \| this article].nding in
120		-"<tt>>
121		-
122		-<h2 id="scgi">Serving via SCGI is incl:</p>
123		-
124		-<ol>
125		- See [on standard output w \| this article].nding in
126		-"<tt>>
127		-debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
128		-ving via inetd is incl:</p>
129		-
130		-<ol>
131		-serverT is to use either the
132		-[/help/server\|server] or the [/help/ui\|ui] commands:
133		-
134		-<ul>
135		- <li><b>fossil server</b> <i>REPOSITORY</i>
136		- <li><b>fossil ui</b> <i>REPOSITORY</i>
137		-</ul>
138		-
139		-The <i>REPOSITORY</i> argument is either the name of the repository file, or
140		-a directorerving via inetd is incl:</p>
141		-
142		-named <tt>*.fossil</tt>.
143		-Both of these commands start a Fossil server, usually on TCP port 8080, though
144		-a higher numbered port might also be used if 8080 is already occupied. You can
145		-access these using URLs of the form <b>http://localhost:8080/</b>, or if
146		-<i>REPOSITORY</i> is a directory, URLs of the form
147		-<b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is thedocumented in the
148		-source code. As of 2019-07-26, the available options are described at
149		-[/artifact/183cf5e5ad2ae111?ln=1912-1959\|main.c lines 1912 through 1959]
	122	+<p>
	123	+After any signification configuration change, it is a good idea to
	124	+revisit the Setup/Security-Audit page just to dourun in
	125	+SCGI mode</a> — --scgi</tt></a>
	126	+— instead of HTTP mode</a>, which allows it

	--- a/www/server/index.html
	+++ b/www/server/index.html
	@@ -1,149 +1,126 @@
1	<title>her post-asqltitle>her post-activation steps includher poster post-activation steps is incl:</p>













2
3	<ol>
4	<li>
5	Add addieam members have approp.</l].








6
7	by to aData sharing and synchronization can be entirely peer-to-peer.
8	Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
9	to ensure that (in the limit) all participating peers see the exact same content.nding in
10	"<tt>>
11	sh2>But, A Server Can Be Useful is incl:</p>




12
13	<ol>l>
14	<li>
15	Add addnot require a server,
16	but a server does make collaboration easier.
17	A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>
18
19	<ol>
20	listener approachactivation: inetd, xinetdA stand-alone server
21	<li>Using inetd, xinetd, or stunnel
22	<li>CGI
23	<li>SCGI (a.k.a. Simp [ \| a separate article].nding in
24	"<tt>>
25
26	<h2 id="inetd">Serving via inetd is incl:</p>
27
28	<ol>
29	See [hat all teYou can als \| this article].nding in
30	"<tt>>
31
32	<h2 id="sl.wiki#stunneleading,
33	is just a Fossil server displaying the content of the
34	=> with a also migrate fro
35	ia-title="Howt This is the easiest wn also migrate fro
36	ia-title="Howt This is the easieng in
37	"<tt>>
38
39	<h2 id="inetd">Serving via inetd is incl:</p>
40
41	<ol>
42	See [hat all teYou can als \| this article].nding in
43	"<tt>>
44
45	<h2 id="cgi">Serving via CGI is incl:</p>
46
47	<ol>
48	See [ \| this article].nding in
49	"<tt>>
50
51	<h2 id="scgi">Serving via SCGI is incl:</p>
52
53	<ol>
54	See [on standard output w \| this article].nding in
55	"<tt>>
56	debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
57	ving via inetd is incl:</p>
58
59	<ol>
60	serverT is to use either the
61	[/help/server\|server] or the [/help/ui\|ui] commands:
62
63	<ul>
64	<li><b>fossil server</b> <i>REPOSITORY</i>
65	<li><b>fossil ui</b> <i>REPOSITORY</i>
66	</ul>
67
68	The <i>REPOSITORY</i> argument is either the name of the repository file, or
69	a directorerving via inetd is incl:</p>
70
71	named <tt>*.fossil</tt>.
72	Both of these vation steps includher poster post-activation steps is incl:</p>
73
74	<ol>
75	<li>
76	Add addieam members have approp.</l].






77
78	by to aData sharing and synchronization can be entirely peer-to-peer.
79	Fossil uses [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|conflict-free replicated data types]
80	to ensure that (in the limit) all participating peers see the exact same content.nding in
81	"<tt>>
82	sh2>But, A Server Can Be Useful is incl:</p>

83
84	<ol>l>
85	<li>
86	Add addnot require a server,
87	but a server does make collaboration easier.
88	A Fossil server also works well as a complete website for acompletOverviewMethods is incl:</p>































89
90	<ol>
91	listener approachactivation: inetd, xinetdA stand-alone server
92	<li>Using inetd, xinetd, or stunnel
93	<li>CGI
94	<li>SCGI (a.k.a. Simp [ \| a separate article].nding in
95	"<tt>>





96
97	<h2 id="inetd">Serving via inetd is incl:</p>





98
99	<ol>
100	See [hat all teYou can als \| this article].nding in
101	"<tt>>
102
103	<h2 id="sl.wiki#stunneleading,
104	is just a Fossil server displaying the content of the
105	=> with a also migrate fro
106	ia-title="Howt This is the easiest wn also migrate fro
107	ia-title="Howt This is the easieng in
108	"<tt>>
109
110	<h2 id="inetd">Serving via inetd is incl:</p>
111
112	<ol>
113	See [hat all teYou can als \| this article].nding in
114	"<tt>>
115
116	<h2 id="cgi">Serving via CGI is incl:</p>
117
118	<ol>
119	See [ \| this article].nding in
120	"<tt>>
121
122	<h2 id="scgi">Serving via SCGI is incl:</p>
123
124	<ol>
125	See [on standard output w \| this article].nding in
126	"<tt>>
127	debian/nginxtext-align:style="text-align: Windows.org/] website, in, or a directory hierarchy
128	ving via inetd is incl:</p>
129
130	<ol>
131	serverT is to use either the
132	[/help/server\|server] or the [/help/ui\|ui] commands:
133
134	<ul>
135	<li><b>fossil server</b> <i>REPOSITORY</i>
136	<li><b>fossil ui</b> <i>REPOSITORY</i>
137	</ul>
138
139	The <i>REPOSITORY</i> argument is either the name of the repository file, or
140	a directorerving via inetd is incl:</p>
141
142	named <tt>*.fossil</tt>.
143	Both of these commands start a Fossil server, usually on TCP port 8080, though
144	a higher numbered port might also be used if 8080 is already occupied. You can
145	access these using URLs of the form <b>http://localhost:8080/</b>, or if
146	<i>REPOSITORY</i> is a directory, URLs of the form
147	<b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is thedocumented in the
148	source code. As of 2019-07-26, the available options are described at
149	[/artifact/183cf5e5ad2ae111?ln=1912-1959\|main.c lines 1912 through 1959]

	--- a/www/server/index.html
	+++ b/www/server/index.html
	@@ -1,149 +1,126 @@
1	ia-title="How To Configure A Fossil Server">
2
3	<style type="text/css">
4	p {
5	margin-left: 4em;
6	margin-right: 3em;
7	}
8
9	li p {
10	margin-left: 0;h2n evenPI to give it an evenPI
11	Prior to launching a server on, it is best to
12	prepareto be served. The easiest wacommand
13	on a workstation and then visit the "Setup" menu.
14	Minimum preparation actions include:</p>
15
16	<ol>
17	<li>
18	Ensure that you have an administrator user account and password
19	configured. Visit the Setup/Users page to accomplish this.</p></li>
20	<li>
21	Visit the Setup/Security-Audit pageYou might want to configureto be completely private
22	for the initial upload and server activatation, then open access up to
23	post-activation configuration refinement</a>
24	stage.
25	</p></li>
26	</ol>
27
28	<p>
29	Additional configuration can be accomplished after the server is up
30	and running. Once the prvery useful</a>.</p>trator
31	and visiting the Setup menu. Pay particular attention to the
32	"Setup/Sec
33	configured the
34	want to keep private. Other post-activation steps include the follodditionalmethods">.
35	</p></li>
36	</ol>
37
38	<p>
39	set upe accomplished after the server is up
40	and running. Once the preliminary configuration is completed
41	uploaddatabaand proceed to
42	activate the server using one or more of the techniques dSnext two sectiiques described
43	in the next two sections.
44	</p>additional configuration
45	fine-tuning can be accomplished by logging in as an administrator
46	containing repositorieusing a single methodconfigured the
47	want to keep private. Other post-activation steps include the following:</p>


















































48
49	<ol>
50	<li>
51	Add additional users accounts so that all team members have approp.</li>
52	<li>
53	Modify the look-and-feel of site by to accommodatedocumentation</a> then perhaps activate the s feature so that
54	visitors can doin-left: 0;
55	ia-title="Howto an email server so that it can send email
56	notifications of new check-ins or other activate.
57	<li>
58
59	<li>
60	If you locked downas completely private prior to
61	upload, you might want to open up access to the public once you get
62	everything working. Or, keepprivate, according to
63	your needs.
64	</ol>
65
66	<p>
67	Afte,t</a>
68	stage.
69	</p></li>
70	</ol>
71
72	<p>
73	Additional configuration can be accthe script runs Fossil to
74	appropriate URL, thatafter the server is up
75	and running. w To Configure A Fossil Server">
76
77	<style type="text/css">
78	p {
79	margin-left: 4em;
80	margin-right: 3em;
81	}
82
83	li p {
84	margin-left: 0;h2n evenPI to give it an evenPI
85	Prior to launching a server on, it is best to
86	prepareto be served. The easiest wacommand
87	on a workstation and then visit the "Setup" menu.
88	Minimum preparation actia-title="How To Configure A Fossil Server">
89
90	<style type="text/css">
91	p {
92	margin-left: 4em;
93	margin-right: 3em;
94	}
95
96	li p {
97	margin-left: 0;h2n evenPI to give it an evenPI
98	Prior to launching a server on, it is best to
99	prepareto be served. The easiest wacommand
100	on a workstation and then visit the "Setup" menu.
101	Minimum preparation actions include:</p>
102
103	<ol>
104	<li>
105	Ensure that you have an administrator user account and password
106	configured. Visit the Setup/Users page to accomplish this.</p></li>
107	<li>
108	Vi <a
109	documentation</a> then perhaps activate the s feature so that
110	visitors can doin-left: 0;
111	ia-title="Howto an email server so that it can send email
112	notifications of new check-ins or other activate.
113	<li>
114
115	<li>
116	If you locked downas completely private prior to
117	upload, you might want to open up access to the public once you get
118	everything working. Or, keepprivate, according to
119	your needs.
120	</ol>
121
122	<p>
123	After any signification configuration change, it is a good idea to
124	revisit the Setup/Security-Audit page just to dourun in
125	SCGI mode</a> — --scgi</tt></a>
126	— instead of HTTP mode</a>, which allows it

A www/server/index.html

+126

		--- a/www/server/index.html
		+++ b/www/server/index.html
		@@ -0,0 +1,126 @@
	1	+ia-title="How To Configure A Fossil Server">
	2	+
	3	+<style type="text/css">
	4	+ p {
	5	+ margin-left: 4em;
	6	+ margin-right: 3em;
	7	+ }
	8	+
	9	+ li p {
	10	+ margin-left: 0;h2n evenPI to give it an evenPI
	11	+Prior to launching a server on, it is best to
	12	+prepareto be served. The easiest wacommand
	13	+on a workstation and then visit the "Setup" menu.
	14	+Minimum preparation actions include:</p>
	15	+
	16	+<ol>
	17	+<li>
	18	+Ensure that you have an administrator user account and password
	19	+configured. Visit the Setup/Users page to accomplish this.</p></li>
	20	+<li>
	21	+Visit the Setup/Security-Audit pageYou might want to configureto be completely private
	22	+for the initial upload and server activatation, then open access up to
	23	+post-activation configuration refinement</a>
	24	+stage.
	25	+</p></li>
	26	+</ol>
	27	+
	28	+<p>
	29	+Additional configuration can be accomplished after the server is up
	30	+and running. Once the prvery useful</a>.</p>trator
	31	+and visiting the Setup menu. Pay particular attention to the
	32	+"Setup/Sec
	33	+configured the
	34	+want to keep private. Other post-activation steps include the follodditionalmethods">.
	35	+</p></li>
	36	+</ol>
	37	+
	38	+<p>
	39	+set upe accomplished after the server is up
	40	+and running. Once the preliminary configuration is completed
	41	+uploaddatabaand proceed to
	42	+activate the server using one or more of the techniques dSnext two sectiiques described
	43	+in the next two sections.
	44	+</p>additional configuration
	45	+fine-tuning can be accomplished by logging in as an administrator
	46	+containing repositorieusing a single methodconfigured the
	47	+want to keep private. Other post-activation steps include the following:</p>
	48	+
	49	+<ol>
	50	+<li>
	51	+Add additional users accounts so that all team members have approp.</li>
	52	+<li>
	53	+Modify the look-and-feel of site by to accommodatedocumentation</a> then perhaps activate the s feature so that
	54	+visitors can doin-left: 0;
	55	+ ia-title="Howto an email server so that it can send email
	56	+notifications of new check-ins or other activate.
	57	+<li>
	58	+
	59	+<li>
	60	+If you locked downas completely private prior to
	61	+upload, you might want to open up access to the public once you get
	62	+everything working. Or, keepprivate, according to
	63	+your needs.
	64	+</ol>
	65	+
	66	+<p>
	67	+Afte,t</a>
	68	+stage.
	69	+</p></li>
	70	+</ol>
	71	+
	72	+<p>
	73	+Additional configuration can be accthe script runs Fossil to
	74	+appropriate URL, thatafter the server is up
	75	+and running. w To Configure A Fossil Server">
	76	+
	77	+<style type="text/css">
	78	+ p {
	79	+ margin-left: 4em;
	80	+ margin-right: 3em;
	81	+ }
	82	+
	83	+ li p {
	84	+ margin-left: 0;h2n evenPI to give it an evenPI
	85	+Prior to launching a server on, it is best to
	86	+prepareto be served. The easiest wacommand
	87	+on a workstation and then visit the "Setup" menu.
	88	+Minimum preparation actia-title="How To Configure A Fossil Server">
	89	+
	90	+<style type="text/css">
	91	+ p {
	92	+ margin-left: 4em;
	93	+ margin-right: 3em;
	94	+ }
	95	+
	96	+ li p {
	97	+ margin-left: 0;h2n evenPI to give it an evenPI
	98	+Prior to launching a server on, it is best to
	99	+prepareto be served. The easiest wacommand
	100	+on a workstation and then visit the "Setup" menu.
	101	+Minimum preparation actions include:</p>
	102	+
	103	+<ol>
	104	+<li>
	105	+Ensure that you have an administrator user account and password
	106	+configured. Visit the Setup/Users page to accomplish this.</p></li>
	107	+<li>
	108	+Vi <a
	109	+documentation</a> then perhaps activate the s feature so that
	110	+visitors can doin-left: 0;
	111	+ ia-title="Howto an email server so that it can send email
	112	+notifications of new check-ins or other activate.
	113	+<li>
	114	+
	115	+<li>
	116	+If you locked downas completely private prior to
	117	+upload, you might want to open up access to the public once you get
	118	+everything working. Or, keepprivate, according to
	119	+your needs.
	120	+</ol>
	121	+
	122	+<p>
	123	+After any signification configuration change, it is a good idea to
	124	+revisit the Setup/Security-Audit page just to dourun in
	125	+SCGI mode</a> — --scgi</tt></a>
	126	+— instead of HTTP mode</a>, which allows it

	--- a/www/server/index.html
	+++ b/www/server/index.html
	@@ -0,0 +1,126 @@

	--- a/www/server/index.html
	+++ b/www/server/index.html
	@@ -0,0 +1,126 @@
1	ia-title="How To Configure A Fossil Server">
2
3	<style type="text/css">
4	p {
5	margin-left: 4em;
6	margin-right: 3em;
7	}
8
9	li p {
10	margin-left: 0;h2n evenPI to give it an evenPI
11	Prior to launching a server on, it is best to
12	prepareto be served. The easiest wacommand
13	on a workstation and then visit the "Setup" menu.
14	Minimum preparation actions include:</p>
15
16	<ol>
17	<li>
18	Ensure that you have an administrator user account and password
19	configured. Visit the Setup/Users page to accomplish this.</p></li>
20	<li>
21	Visit the Setup/Security-Audit pageYou might want to configureto be completely private
22	for the initial upload and server activatation, then open access up to
23	post-activation configuration refinement</a>
24	stage.
25	</p></li>
26	</ol>
27
28	<p>
29	Additional configuration can be accomplished after the server is up
30	and running. Once the prvery useful</a>.</p>trator
31	and visiting the Setup menu. Pay particular attention to the
32	"Setup/Sec
33	configured the
34	want to keep private. Other post-activation steps include the follodditionalmethods">.
35	</p></li>
36	</ol>
37
38	<p>
39	set upe accomplished after the server is up
40	and running. Once the preliminary configuration is completed
41	uploaddatabaand proceed to
42	activate the server using one or more of the techniques dSnext two sectiiques described
43	in the next two sections.
44	</p>additional configuration
45	fine-tuning can be accomplished by logging in as an administrator
46	containing repositorieusing a single methodconfigured the
47	want to keep private. Other post-activation steps include the following:</p>
48
49	<ol>
50	<li>
51	Add additional users accounts so that all team members have approp.</li>
52	<li>
53	Modify the look-and-feel of site by to accommodatedocumentation</a> then perhaps activate the s feature so that
54	visitors can doin-left: 0;
55	ia-title="Howto an email server so that it can send email
56	notifications of new check-ins or other activate.
57	<li>
58
59	<li>
60	If you locked downas completely private prior to
61	upload, you might want to open up access to the public once you get
62	everything working. Or, keepprivate, according to
63	your needs.
64	</ol>
65
66	<p>
67	Afte,t</a>
68	stage.
69	</p></li>
70	</ol>
71
72	<p>
73	Additional configuration can be accthe script runs Fossil to
74	appropriate URL, thatafter the server is up
75	and running. w To Configure A Fossil Server">
76
77	<style type="text/css">
78	p {
79	margin-left: 4em;
80	margin-right: 3em;
81	}
82
83	li p {
84	margin-left: 0;h2n evenPI to give it an evenPI
85	Prior to launching a server on, it is best to
86	prepareto be served. The easiest wacommand
87	on a workstation and then visit the "Setup" menu.
88	Minimum preparation actia-title="How To Configure A Fossil Server">
89
90	<style type="text/css">
91	p {
92	margin-left: 4em;
93	margin-right: 3em;
94	}
95
96	li p {
97	margin-left: 0;h2n evenPI to give it an evenPI
98	Prior to launching a server on, it is best to
99	prepareto be served. The easiest wacommand
100	on a workstation and then visit the "Setup" menu.
101	Minimum preparation actions include:</p>
102
103	<ol>
104	<li>
105	Ensure that you have an administrator user account and password
106	configured. Visit the Setup/Users page to accomplish this.</p></li>
107	<li>
108	Vi <a
109	documentation</a> then perhaps activate the s feature so that
110	visitors can doin-left: 0;
111	ia-title="Howto an email server so that it can send email
112	notifications of new check-ins or other activate.
113	<li>
114
115	<li>
116	If you locked downas completely private prior to
117	upload, you might want to open up access to the public once you get
118	everything working. Or, keepprivate, according to
119	your needs.
120	</ol>
121
122	<p>
123	After any signification configuration change, it is a good idea to
124	revisit the Setup/Security-Audit page just to dourun in
125	SCGI mode</a> — --scgi</tt></a>
126	— instead of HTTP mode</a>, which allows it

M www/server/macos/service.md

+122

		--- a/www/server/macos/service.md
		+++ b/www/server/macos/service.md
		@@ -0,0 +1,122 @@
	1	+# Serving via launchd on macOS
	2	+
	3	+[`launchd`][ldhome] is the default service management framework on macOS
	4	+[since the release of Tiger in 2005][wpa]. If you want a Fossil server
	5	+to launch in the background on a Mac, it’s the way Apple wants you to do
	6	+it. `launchd` is to macOS as `systemd` is to most modern Linux desktop
	7	+systems. (Indeed, `systemd` arguably reinvented the perfectly good,
	8	+pre-existing `launchd` wheel.)
	9	+
	10	+Unlike in [our `systemd` article](../debian/service.md), we’re not going
	11	+to show the per-user method here, because those so-called
	12	+[LaunchAgents][la] only start when a user is logged into the GUI, and
	13	+they stop when that user logs out. This does not strike us as proper
	14	+“server” behavior, so we’ll stick to system-level LaunchDaemons instead.
	15	+
	16	+However, we will still give two different configurations, just as in the
	17	+`systemd` article: one for a standalone HTTP server, and one using
	18	+socket activation.
	19	+
	20	+For more information on `launchd`, the single best ](launchd.inf.info). The next best is:
	21	+
	22	+ $ man launchd.plist
	23	+
	24	+[la]: http://www.grivet-tools.com/blog/2014/launchdaemons-vs-launchagents/
	25	+[ldhome]: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
	26	+[wpa]: https://en.wikipedia.org/wiki/Launchd
	27	+
	28	+
	29	+
	30	+## Standalone HTTP Server
	31	+
	32	+To configure `launchd` to start Fossil as a standalone HTTP server,
	33	+write the following as `com.example.dev. >WorkingDire
	34	+[`launchd`][ldhome] is t# Serving via launchd on /key>
	35	+ <true/>
	36	+ <dict>
	37	+ <key>Labe <key>log</string>
	38	+ <key>StandardHTTP</string>
	39	+ ev.FossilHTTP</string>
	40	+ <key>ring>/tmp/fossil-inf-info.log</string>
	41	+ <# Serving via launchd on macOS
	42	+
	43	+[` <strin </array>
	44	+ key>WorkingDirec <key>KeepAlive</key>
	45	+ >
	46	+ <key>KeepAeepAlive</key>
	47	+ <true/>
	48	+ >
	49	+ <key>KeepA <key>S <string>/tmp/fossil-error.log</string>
	50	+ /fossil-error.log</string>
	51	+ <key <string>/tmp/fop/fossil-info.log</string>
	52	+ # Serving via launchd on macOlaunchd on macOS
	53	+
	54	+[`launchd`]a launchd on macOS
	55	+
	56	+[`launchd`]es not strike us as proper
	57	+“>
	58	+ <key>KeepAl/dict>
	59	+ or, so we’ll stick to system-level LaunchDaemons instead.
	60	+
	61	+However, we will still give two different configurations, just as in the
	62	+`systemd` article: one for a standalone HTTP server, and one using
	63	+socket activation.
	64	+
	65	+For more information on `launchd`, the single best resource we’ve found
	66	+is [launchd.info](https://launchd.info). The next best is:
	67	+
	68	+ $ man launchd.plist
	69	+
	70	+[la]: http://www.grivet-tools.com/blog/2014/launchdaemons-vs-launchagents/
	71	+[ldhome]: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
	72	+[wpa]: https://en.wikipedia.org/wiki/Launchd
	73	+
	74	+
	75	+
	76	+## Standalone HTTP Server
	77	+
	78	+To configure `launchd` to start Fossil as a standalone HTTP server,
	79	+write the following as `com.example.dev.FossilHTTP.plist`:n macOS
	80	+
	81	+[`launchd`][ldhome] is the default service management framework on macOS
	82	+[s# S"http://www.apple.com/DT
	83	+ "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
	84	+<plist version="1.0">
	85	+<dict>
	86	+ <key>Label</key>
	87	+ <string>com.example.dev.FossilHTTP</string>
	88	+ <key "http://www.apple.co<string>/usr/local/bin/fossil</string>
	89	+ <string>server</string>
	90	+ <string>--port</string>
	91	+ <string>9000</string>
	92	+ <string>repo.fossil</string>
	93	+ </array>
	94	+ <key>WorkingDirectory</key>
	95	+ <string>/Users/you/museum</string>
	96	+ <key>KeepAlive</key>
	97	+ "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
	98	+<plist version="1.0">
	99	+<dict>
	100	+ <key>Label</key>
	101	+ <string>com.example.dev.Fossil</string>
	102	+ <key>StandardOutPath</key>
	103	+ <string>/tmp/fossil-info.log</string>
	104	+ <key>UserName</key>
	105	+ <string>you</string>
	106	+ <key>GroupName</key>
	107	+ <string>staff</string>
	108	+ <key>InitGroups</key>
	109	+ <true/>
	110	+</dict>
	111	+</plist>
	112	+```
	113	+
	114	+In this example, we’re assuming your development organization uses the
	115	+domain name “`dev.example.org`”, that your short macOS login name is
	116	+“`you`”, and that you store your Fossils in “`~/museum`”. Adjust these
	117	+elements of the plist file to suit your local situation.
	118	+
	119	+You might be wondering about the use of `UserName`: isn’t Fossil
	120	+supposed to drop privileges and enter [a `chroot(2)`
	121	+jail](../../chroot.md) when it’s started as root like this? Why do we
	122	+need

	--- a/www/server/macos/service.md
	+++ b/www/server/macos/service.md
	@@ -0,0 +1,122 @@

	--- a/www/server/macos/service.md
	+++ b/www/server/macos/service.md
	@@ -0,0 +1,122 @@
1	# Serving via launchd on macOS
2
3	[`launchd`][ldhome] is the default service management framework on macOS
4	[since the release of Tiger in 2005][wpa]. If you want a Fossil server
5	to launch in the background on a Mac, it’s the way Apple wants you to do
6	it. `launchd` is to macOS as `systemd` is to most modern Linux desktop
7	systems. (Indeed, `systemd` arguably reinvented the perfectly good,
8	pre-existing `launchd` wheel.)
9
10	Unlike in [our `systemd` article](../debian/service.md), we’re not going
11	to show the per-user method here, because those so-called
12	[LaunchAgents][la] only start when a user is logged into the GUI, and
13	they stop when that user logs out. This does not strike us as proper
14	“server” behavior, so we’ll stick to system-level LaunchDaemons instead.
15
16	However, we will still give two different configurations, just as in the
17	`systemd` article: one for a standalone HTTP server, and one using
18	socket activation.
19
20	For more information on `launchd`, the single best ](launchd.inf.info). The next best is:
21
22	$ man launchd.plist
23
24	[la]: http://www.grivet-tools.com/blog/2014/launchdaemons-vs-launchagents/
25	[ldhome]: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
26	[wpa]: https://en.wikipedia.org/wiki/Launchd
27
28
29
30	## Standalone HTTP Server
31
32	To configure `launchd` to start Fossil as a standalone HTTP server,
33	write the following as `com.example.dev. >WorkingDire
34	[`launchd`][ldhome] is t# Serving via launchd on /key>
35	<true/>
36	<dict>
37	<key>Labe <key>log</string>
38	<key>StandardHTTP</string>
39	ev.FossilHTTP</string>
40	<key>ring>/tmp/fossil-inf-info.log</string>
41	<# Serving via launchd on macOS
42
43	[` <strin </array>
44	key>WorkingDirec <key>KeepAlive</key>
45	>
46	<key>KeepAeepAlive</key>
47	<true/>
48	>
49	<key>KeepA <key>S <string>/tmp/fossil-error.log</string>
50	/fossil-error.log</string>
51	<key <string>/tmp/fop/fossil-info.log</string>
52	# Serving via launchd on macOlaunchd on macOS
53
54	[`launchd`]a launchd on macOS
55
56	[`launchd`]es not strike us as proper
57	“>
58	<key>KeepAl/dict>
59	or, so we’ll stick to system-level LaunchDaemons instead.
60
61	However, we will still give two different configurations, just as in the
62	`systemd` article: one for a standalone HTTP server, and one using
63	socket activation.
64
65	For more information on `launchd`, the single best resource we’ve found
66	is [launchd.info](https://launchd.info). The next best is:
67
68	$ man launchd.plist
69
70	[la]: http://www.grivet-tools.com/blog/2014/launchdaemons-vs-launchagents/
71	[ldhome]: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
72	[wpa]: https://en.wikipedia.org/wiki/Launchd
73
74
75
76	## Standalone HTTP Server
77
78	To configure `launchd` to start Fossil as a standalone HTTP server,
79	write the following as `com.example.dev.FossilHTTP.plist`:n macOS
80
81	[`launchd`][ldhome] is the default service management framework on macOS
82	[s# S"http://www.apple.com/DT
83	"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
84	<plist version="1.0">
85	<dict>
86	<key>Label</key>
87	<string>com.example.dev.FossilHTTP</string>
88	<key "http://www.apple.co<string>/usr/local/bin/fossil</string>
89	<string>server</string>
90	<string>--port</string>
91	<string>9000</string>
92	<string>repo.fossil</string>
93	</array>
94	<key>WorkingDirectory</key>
95	<string>/Users/you/museum</string>
96	<key>KeepAlive</key>
97	"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
98	<plist version="1.0">
99	<dict>
100	<key>Label</key>
101	<string>com.example.dev.Fossil</string>
102	<key>StandardOutPath</key>
103	<string>/tmp/fossil-info.log</string>
104	<key>UserName</key>
105	<string>you</string>
106	<key>GroupName</key>
107	<string>staff</string>
108	<key>InitGroups</key>
109	<true/>
110	</dict>
111	</plist>
112	```
113
114	In this example, we’re assuming your development organization uses the
115	domain name “`dev.example.org`”, that your short macOS login name is
116	“`you`”, and that you store your Fossils in “`~/museum`”. Adjust these
117	elements of the plist file to suit your local situation.
118
119	You might be wondering about the use of `UserName`: isn’t Fossil
120	supposed to drop privileges and enter [a `chroot(2)`
121	jail](../../chroot.md) when it’s started as root like this? Why do we
122	need

M www/server/whyuseaserver.wiki

+20

		--- a/www/server/whyuseaserver.wiki
		+++ b/www/server/whyuseaserver.wiki
		@@ -0,0 +1,20 @@
	1	+<title>Benefits Of A Fossil Server</title>
	2	+
	3	+<h2>No Server Required</h2>
	4	+
	5	+Fossil does <em>not</em> require a central server.
	6	+Data sharing and synchronization can be entirel peer-to-peer.
	7	+Fossil uses
	8	+[https://en.wikipedia.org/wiki/Conflic\|conflict-free replicated data types]
	9	+to ensure that (in the limit) all participating peers see tAe>Benefits of a Fossil Server</title>
	10	+
	11	+<h2>No Server Required</h2>
	12	+
	13	+Fossil does not require a central server.
	14	+Data sharing and synchronization can be entirely peer-to-peer.
	15	+Fossil uses
	16	+[https://en.wikipedia.org/wiki/Conflict-free_replous2. <b>A server works as a projectplicated data types]
	17	+to ensure that (in the limit) all participating peer
	18	+trouble-tickets, and wiki, and a forum. It shows the status
	19	+ of the project. And the embedded documentation feature provides
	20	+ only instructionse.

	--- a/www/server/whyuseaserver.wiki
	+++ b/www/server/whyuseaserver.wiki
	@@ -0,0 +1,20 @@

	--- a/www/server/whyuseaserver.wiki
	+++ b/www/server/whyuseaserver.wiki
	@@ -0,0 +1,20 @@
1	<title>Benefits Of A Fossil Server</title>
2
3	<h2>No Server Required</h2>
4
5	Fossil does <em>not</em> require a central server.
6	Data sharing and synchronization can be entirel peer-to-peer.
7	Fossil uses
8	[https://en.wikipedia.org/wiki/Conflic\|conflict-free replicated data types]
9	to ensure that (in the limit) all participating peers see tAe>Benefits of a Fossil Server</title>
10
11	<h2>No Server Required</h2>
12
13	Fossil does not require a central server.
14	Data sharing and synchronization can be entirely peer-to-peer.
15	Fossil uses
16	[https://en.wikipedia.org/wiki/Conflict-free_replous2. <b>A server works as a projectplicated data types]
17	to ensure that (in the limit) all participating peer
18	trouble-tickets, and wiki, and a forum. It shows the status
19	of the project. And the embedded documentation feature provides
20	only instructionse.

M www/server/windows/cgi-bin-perm.png

Binary file

M www/server/windows/cgi-exec-perm.png

Binary file

M www/server/windows/cgi-install-iis.png

Binary file

M www/server/windows/cgi-script-map.png

Binary file

M www/server/windows/cgi.md

+115

		--- a/www/server/windows/cgi.md
		+++ b/www/server/windows/cgi.md
		@@ -0,0 +1,115 @@
	1	+# Serving via IIS + CGI
	2	+
	3	+## This Is Not the Method You Are Looking For
	4	+
	5	+Setting up CGI service under IIS is surprisingly complicated compared to
	6	+running Fossil as a CGI under most other operating systems. We recommend
	7	+that you use the simpler [reverse proxying method](./iis.md) instead
	8	+unless there is some compelling reason why that method cannot work for
	9	+you, such as its dependence on non-stock IIS extensions. (Keep in mind
	10	+that both extensions it requires are by Microsoft, not third parties!)
	11	+
	12	+Once you’ve got this scheme working, it gives the same benefits as those
	13	+listed at the top of the linked-to document.
	14	+
	15	+There is a small benefit you get from using CGI over reverse proxying on
	16	+other OSes, which is that the Fossil program only runs briefly in order
	17	+to serve each HTTP hit. Once the request is done, that Fossil instance
	18	+shuts back down, releasing all of its resources. You don’t need to keep
	19	+a background Fossil HTTP server running full-time to provide CGI-based
	20	+Fossil service.
	21	+
	22	+You lose a lot of that benefit on Windows:
	23	+
	24	+1. It only matters to start with on servers that are highly RAM
	25	+ constrained. (Roughly ≤ 128 MiB.) Our configuration steps below
	26	+ assume you’re using the Windows and IIS GUIs, which have RAM
	27	+ requirements well in excess of this, making Fossil’s resource
	28	+ requirements a drop in the bucket next to them. On the [Azure
	29	+ B1s][b1s] virtual machine I used to prepare these instructions, the
	30	+ Windows Server Manager GUI kept filling the VM’s 1 GiB of RAM
	31	+ during feature installation and crashing. I had to upgrade the VM’s
	32	+ RAM to 2 GiB just to get useful work done!
	33	+
	34	+2. Process creation on Windows is [much more expensive][cp] than on the
	35	+ other OSes Fossil runs on, so the benefits of firing up a Fossil
	36	+ executable to process each HTTP request are partially swamped by the
	37	+ overhead of doing so.
	38	+
	39	+Therefore, unless you’re willing to replace all of the GUI configuration
	40	+steps below with command line equivalents, or shut the GUI down entirely
	41	+after configuring IIS, CGI is a much less compelling option on Windows.
	42	+
	43	+WARNING: The following tutorial appears to fail with the current
	44	+(2019-08-17) version of Fossil, [apparently][fbug] due to an inability
	45	+of Fossil to detect that it’s being run in CGI mode.
	46	+
	47	+[b1s]: https://azure.microsoft.com/en-us/blog/introducing-b-series-our-new-burstable-vm-size/
	48	+[cp]: https://stackoverflow.com/a/48244/142454
	49	+[fbug]: https://fossil-scm.org/forum/forumpost/de18dc32c0
	50	+
	51	+
	52	+## Install IIS with CGI Support
	53	+
	54	+The steps for this are identical to those for the [reverse proxying IIS
	55	+setup](./iis.md#install) except that you need to enable CGI in the last
	56	+step, since it isn’t installed by default. For Windows Server, the path
	57	+is:
	58	+
	59	+![Install CGI in IIS](./cgi-install-iis.png)
	60	+
	61	+The path is similar on the consumer-focused versions of Windows, once
	62	+you get to that last step.
	63	+
	64	+
	65	+## Setup
	66	+
	67	+1. Install the Fossil executable to `c:\inetpub\wwwroot\bin` on the web
	68	+ server. We can’t use an executable you might already have because IIS
	69	+ runs under a separate user account, so we need to give that
	70	+ executable special permissions, and that’s easiest to do under the
	71	+ IIS tree:
	72	+
	73	+ ![IIS fossil.exe execute permission](./cgi-bin-perm.png)
	74	+
	75	+2. In IIS Manager (a.k.a. `INETMGR`) drill down into the Sites folder
	76	+ in the left-side pane and right-click your web site’s
	77	+ configuration. (e.g. “Default Web Site”)
	78	+
	79	+3. On that menu say “Add Virtual Directory.” Give it the alias “`cgi`”
	80	+ and point it at a suitable directory, such as
	81	+ “`c:\inetpub\wwwroot\cgi`”.
	82	+
	83	+4. Double-click the “Handler Mappings” icon, then in the right-side
	84	+ pane, click “Add Script Map...” Apply the following settings:
	85	+
	86	+ ![IIS script map dialog](./cgi-script-map.png)
	87	+
	88	+ The Executable path must point to the path we set up in step 1, not
	89	+ to some other `fossil.exe` you may have elsewhere on your system.
	90	+ You will need to change the default “`*.dll`” filter in the Open
	91	+ dialog to “`*.exe`” in order to see it when browsing via the “`...`”
	92	+ button.
	93	+
	94	+5. Create a file called `repo.fslcgi` within the CGI directory you
	95	+ chose in step 3, with a single line like this:
	96	+
	97	+ repository: c:\Users\SOMEONE\museum\repo.fossil
	98	+
	99	+ Give the actual path to the repository, of course.
	100	+
	101	+6. Up at the top level of IIS Manager, double-click the “ISAPI and CGI
	102	+ Restrictions” icon, then click “Add...” in the right-side pane.
	103	+ Give the script you just created permission to execute:
	104	+
	105	+ ![IIS CGI execute permission](./cgi-exec-perm.png)
	106	+
	107	+7. In the right-side pane, click “Restart” to apply this configuration,
	108	+ then test it by visiting the newly-available URL in a browser:
	109	+
	110	+ http://localhost/cgi/repo.fslcgi
	111	+
	112	+For more complicated setups such as “directory” mode, see [the generic
	113	+CGI instructions](../any/cgi.md).
	114	+
	115	+[Return to the top-level Fossil server article.](../)

	--- a/www/server/windows/cgi.md
	+++ b/www/server/windows/cgi.md
	@@ -0,0 +1,115 @@

	--- a/www/server/windows/cgi.md
	+++ b/www/server/windows/cgi.md
	@@ -0,0 +1,115 @@
1	# Serving via IIS + CGI
2
3	## This Is Not the Method You Are Looking For
4
5	Setting up CGI service under IIS is surprisingly complicated compared to
6	running Fossil as a CGI under most other operating systems. We recommend
7	that you use the simpler [reverse proxying method](./iis.md) instead
8	unless there is some compelling reason why that method cannot work for
9	you, such as its dependence on non-stock IIS extensions. (Keep in mind
10	that both extensions it requires are by Microsoft, not third parties!)
11
12	Once you’ve got this scheme working, it gives the same benefits as those
13	listed at the top of the linked-to document.
14
15	There is a small benefit you get from using CGI over reverse proxying on
16	other OSes, which is that the Fossil program only runs briefly in order
17	to serve each HTTP hit. Once the request is done, that Fossil instance
18	shuts back down, releasing all of its resources. You don’t need to keep
19	a background Fossil HTTP server running full-time to provide CGI-based
20	Fossil service.
21
22	You lose a lot of that benefit on Windows:
23
24	1. It only matters to start with on servers that are highly RAM
25	constrained. (Roughly ≤ 128 MiB.) Our configuration steps below
26	assume you’re using the Windows and IIS GUIs, which have RAM
27	requirements well in excess of this, making Fossil’s resource
28	requirements a drop in the bucket next to them. On the [Azure
29	B1s][b1s] virtual machine I used to prepare these instructions, the
30	Windows Server Manager GUI kept filling the VM’s 1 GiB of RAM
31	during feature installation and crashing. I had to upgrade the VM’s
32	RAM to 2 GiB just to get useful work done!
33
34	2. Process creation on Windows is [much more expensive][cp] than on the
35	other OSes Fossil runs on, so the benefits of firing up a Fossil
36	executable to process each HTTP request are partially swamped by the
37	overhead of doing so.
38
39	Therefore, unless you’re willing to replace all of the GUI configuration
40	steps below with command line equivalents, or shut the GUI down entirely
41	after configuring IIS, CGI is a much less compelling option on Windows.
42
43	WARNING: The following tutorial appears to fail with the current
44	(2019-08-17) version of Fossil, [apparently][fbug] due to an inability
45	of Fossil to detect that it’s being run in CGI mode.
46
47	[b1s]: https://azure.microsoft.com/en-us/blog/introducing-b-series-our-new-burstable-vm-size/
48	[cp]: https://stackoverflow.com/a/48244/142454
49	[fbug]: https://fossil-scm.org/forum/forumpost/de18dc32c0
50
51
52	## Install IIS with CGI Support
53
54	The steps for this are identical to those for the [reverse proxying IIS
55	setup](./iis.md#install) except that you need to enable CGI in the last
56	step, since it isn’t installed by default. For Windows Server, the path
57	is:
58
59	![Install CGI in IIS](./cgi-install-iis.png)
60
61	The path is similar on the consumer-focused versions of Windows, once
62	you get to that last step.
63
64
65	## Setup
66
67	1. Install the Fossil executable to `c:\inetpub\wwwroot\bin` on the web
68	server. We can’t use an executable you might already have because IIS
69	runs under a separate user account, so we need to give that
70	executable special permissions, and that’s easiest to do under the
71	IIS tree:
72
73	![IIS fossil.exe execute permission](./cgi-bin-perm.png)
74
75	2. In IIS Manager (a.k.a. `INETMGR`) drill down into the Sites folder
76	in the left-side pane and right-click your web site’s
77	configuration. (e.g. “Default Web Site”)
78
79	3. On that menu say “Add Virtual Directory.” Give it the alias “`cgi`”
80	and point it at a suitable directory, such as
81	“`c:\inetpub\wwwroot\cgi`”.
82
83	4. Double-click the “Handler Mappings” icon, then in the right-side
84	pane, click “Add Script Map...” Apply the following settings:
85
86	![IIS script map dialog](./cgi-script-map.png)
87
88	The Executable path must point to the path we set up in step 1, not
89	to some other `fossil.exe` you may have elsewhere on your system.
90	You will need to change the default “`*.dll`” filter in the Open
91	dialog to “`*.exe`” in order to see it when browsing via the “`...`”
92	button.
93
94	5. Create a file called `repo.fslcgi` within the CGI directory you
95	chose in step 3, with a single line like this:
96
97	repository: c:\Users\SOMEONE\museum\repo.fossil
98
99	Give the actual path to the repository, of course.
100
101	6. Up at the top level of IIS Manager, double-click the “ISAPI and CGI
102	Restrictions” icon, then click “Add...” in the right-side pane.
103	Give the script you just created permission to execute:
104
105	![IIS CGI execute permission](./cgi-exec-perm.png)
106
107	7. In the right-side pane, click “Restart” to apply this configuration,
108	then test it by visiting the newly-available URL in a browser:
109
110	http://localhost/cgi/repo.fslcgi
111
112	For more complicated setups such as “directory” mode, see [the generic
113	CGI instructions](../any/cgi.md).
114
115	[Return to the top-level Fossil server article.](../)

M www/server/windows/iis.md

+52

		--- a/www/server/windows/iis.md
		+++ b/www/server/windows/iis.md
		@@ -0,0 +1,52 @@
	1	+# Serving via IIS
	2	+
	3	+## Why Bother?
	4	+
	5	+The first part of the scheme below sets Fossil up as an HTTP server, so
	6	+you might be wondering why you wouldn’t just modify that to make it
	7	+listen on all network interfaces on TCP port 80, so you can avoid the
	8	+need for IIS entirely. For simple use cases, you can indeed do without
	9	+IIS, but there are several use cases where adding it is helpful:
	10	+
	11	+1. Proxying Fossil with IIS lets you [add TLS encryption][tls], which
	12	+ [Fossil does not currently speak](../../ssl.wiki) in its server role.
	13	+
	14	+2. The URL rewriting we do below allows Fossil to be part of a larger
	15	+ site already being served with IIS.
	16	+
	17	+3. You ca n have a mixed-mode site, with Fossil acting as a powerful
	18	+ dynamic content management service and IIS as a fast static content
	19	+ server. The pure-Fossil alternative requires that you check all of
	20	+ your static content into Fossil as versioned or unversioned
	21	+ artifacts.
	22	+
	23	+This article shows how you can get any combination of those benefits by
	24	+using IIS as a reverse proxy for `fossil server`.
	25	+
	26	+There are other ways to use IIS to serve Fossil, such as [via
	27	+CGI](./cgi.md).
	28	+
	29	+
	30	+## Background Fossil Service Setup
	31	+
	32	+You will need to have the Fossil HTTP server running in the background,
	33	+serving some local repository, bound to localhost on a fixed
	34	+high-numbered TCP port. For the purposes of testing, simply start it by
	35	+hand in your command shell of choice:
	36	+
	37	+ fossil serve --port 9000 --localhost repo.fossil
	38	+
	39	+That command assumes you’ve got `fossil.exe` in your `%PATH%` and you’re
	40	+in a directory holding `repo.fossil`. See [the platform-independent
	41	+instructions](../any/none.md) for further details.
	42	+
	43	+For a more robust setup, we recommend that you [install Fossil as a
	44	+Windows service](./service.md), which will allow Fossil to start at
	45	+system boot, before anyone has logged in interactively.
	46	+
	47	+
	48	+## <a name="install"></a>Install IIS
	49	+
	50	+IIS might not be installed in your system yet, so follow the path
	51	+appropriate to your host OS. We’ve tested only the latest Microsoft
	52	+OSes as of the time of this wri

	--- a/www/server/windows/iis.md
	+++ b/www/server/windows/iis.md
	@@ -0,0 +1,52 @@

	--- a/www/server/windows/iis.md
	+++ b/www/server/windows/iis.md
	@@ -0,0 +1,52 @@
1	# Serving via IIS
2
3	## Why Bother?
4
5	The first part of the scheme below sets Fossil up as an HTTP server, so
6	you might be wondering why you wouldn’t just modify that to make it
7	listen on all network interfaces on TCP port 80, so you can avoid the
8	need for IIS entirely. For simple use cases, you can indeed do without
9	IIS, but there are several use cases where adding it is helpful:
10
11	1. Proxying Fossil with IIS lets you [add TLS encryption][tls], which
12	[Fossil does not currently speak](../../ssl.wiki) in its server role.
13
14	2. The URL rewriting we do below allows Fossil to be part of a larger
15	site already being served with IIS.
16
17	3. You ca n have a mixed-mode site, with Fossil acting as a powerful
18	dynamic content management service and IIS as a fast static content
19	server. The pure-Fossil alternative requires that you check all of
20	your static content into Fossil as versioned or unversioned
21	artifacts.
22
23	This article shows how you can get any combination of those benefits by
24	using IIS as a reverse proxy for `fossil server`.
25
26	There are other ways to use IIS to serve Fossil, such as [via
27	CGI](./cgi.md).
28
29
30	## Background Fossil Service Setup
31
32	You will need to have the Fossil HTTP server running in the background,
33	serving some local repository, bound to localhost on a fixed
34	high-numbered TCP port. For the purposes of testing, simply start it by
35	hand in your command shell of choice:
36
37	fossil serve --port 9000 --localhost repo.fossil
38
39	That command assumes you’ve got `fossil.exe` in your `%PATH%` and you’re
40	in a directory holding `repo.fossil`. See [the platform-independent
41	instructions](../any/none.md) for further details.
42
43	For a more robust setup, we recommend that you [install Fossil as a
44	Windows service](./service.md), which will allow Fossil to start at
45	system boot, before anyone has logged in interactively.
46
47
48	## <a name="install"></a>Install IIS
49
50	IIS might not be installed in your system yet, so follow the path
51	appropriate to your host OS. We’ve tested only the latest Microsoft
52	OSes as of the time of this wri

M www/server/windows/index.md

+4

		--- a/www/server/windows/index.md
		+++ b/www/server/windows/index.md
		@@ -0,0 +1,4 @@
	1	+# Using Windows as as a Service](service.md)
	2	+- [Using stunn with Fossil on Windows](./stunnel.md)
	3	+
	4	+*[Return to the top-level Fos

	--- a/www/server/windows/index.md
	+++ b/www/server/windows/index.md
	@@ -0,0 +1,4 @@

	--- a/www/server/windows/index.md
	+++ b/www/server/windows/index.md
	@@ -0,0 +1,4 @@
1	# Using Windows as as a Service](service.md)
2	- [Using stunn with Fossil on Windows](./stunnel.md)
3
4	*[Return to the top-level Fos

M www/server/windows/none.md

+69

		--- a/www/server/windows/none.md
		+++ b/www/server/windows/none.md
		@@ -0,0 +1,69 @@
	1	+# Serving as a Standalone Server on Windows
	2	+
	3	+On Windows, this method works more or less identically to how it’s
	4	+documented in [the generic instructions](../any/none.md).
	5	+
	6	+...but only while `fossil.exe` is actually running, which is the source
	7	+of much trouble on Windows. This problem has two halves:
	8	+
	9	+
	10	+## No App Startup Without Desktop
	11	+
	12	+The easy methods for starting a program in Windows at system start all
	13	+require an interactive desktop. There is no easy way to start an arbitrary
	14	+program on Windows at boot before anyone has logged in. In Unix
	15	+terms, Windows has no simple equivalent to [the `/etc/rc.local` file][rcl].
	16	+
	17	+You can partially get around the first problem by setting your `fossil
	18	+server` call up as one of the user’s interactive startup items. Windows
	19	+10 has its own [idiosyncratic way of doing this][si10], and in older
	20	+systems you have [several alternatives to this][si7]. Regardless of the
	21	+actual mechanism, these will cause the Fossil standalone HTTP server to
	22	+start on an interactive desktop login only. While you’re sitting at
	23	+the Windows login screen, the Fossil server is down.
	24	+
	25	+[rcl]: http://nixdoc.net/man-pages/FreeBSD/man8/rc.local.8.html
	26	+[si10]: https://www.tenforums.com/tutorials/2944-add-delete-enable-disable-startup-items-windows-10-a.html
	27	+[si7]: https://www.wikihow.com/Change-Startup-Programs-in-Windows-7
	28	+
	29	+
	30	+
	31	+## No Simple Background Mode
	32	+
	33	+Windows also lacks a direct equivalent of the Bourne shell’s “`&`” control operator to
	34	+run a program in the background, which you can give in Unix’s `rc.local`
	35	+file, which is just a normal Bourne shell script.
	36	+
	37	+By “background,” I mean
	38	+“not attached to any interactive user’s login session.” When the
	39	+`rc.local` script exits in Unix, any program it backgrounded *stays
	40	+running*. There is no simple and direct equivalent to this mechanism in
	41	+Windows.
	42	+
	43	+If you set `fossil server` to run on interactive login, as above, it
	44	+will shut right back down again when that user logs back out.
	45	+
	46	+With Windows 10, it’s especially problematic because you can no longer
	47	+make the OS put off updates arbitrarily: your Fossil server will go down
	48	+every time Windows Update decides it needs to reboot your computer, and
	49	+then Fossil service will stay down until someone logs back into that
	50	+machine interactively.
	51	+
	52	+
	53	+## Better Solutions
	54	+
	55	+Because of these problems, we only recommend setting `fossil server` up
	56	+on Windows this way when
	57	+you’re a solo developer or you work in a small office where everyone
	58	+arrives more or less at the same time each day, and everyone goes home
	59	+about the same time each day, so that one user can keep the Fossil
	60	+server up through the working day.
	61	+
	62	+If your needs go at all beyond this, you should expect proper “server”
	63	+behavior, which you can get on Windows by [registering Fossil as a
	64	+Windows service](./service.md), which solves the interactive startup and
	65	+shutdown problems above, at a bit of complexity over the Startup Items
	66	+method. You may also want to consider putting that service behind [an
	67	+IIS front-end proxy](./iis.md) to add additional web serving features.
	68	+
	69	+[Return to the top-level Fossil server article.](../)

	--- a/www/server/windows/none.md
	+++ b/www/server/windows/none.md
	@@ -0,0 +1,69 @@

	--- a/www/server/windows/none.md
	+++ b/www/server/windows/none.md
	@@ -0,0 +1,69 @@
1	# Serving as a Standalone Server on Windows
2
3	On Windows, this method works more or less identically to how it’s
4	documented in [the generic instructions](../any/none.md).
5
6	...but only while `fossil.exe` is actually running, which is the source
7	of much trouble on Windows. This problem has two halves:
8
9
10	## No App Startup Without Desktop
11
12	The easy methods for starting a program in Windows at system start all
13	require an interactive desktop. There is no easy way to start an arbitrary
14	program on Windows at boot before anyone has logged in. In Unix
15	terms, Windows has no simple equivalent to [the `/etc/rc.local` file][rcl].
16
17	You can partially get around the first problem by setting your `fossil
18	server` call up as one of the user’s interactive startup items. Windows
19	10 has its own [idiosyncratic way of doing this][si10], and in older
20	systems you have [several alternatives to this][si7]. Regardless of the
21	actual mechanism, these will cause the Fossil standalone HTTP server to
22	start on an interactive desktop login only. While you’re sitting at
23	the Windows login screen, the Fossil server is down.
24
25	[rcl]: http://nixdoc.net/man-pages/FreeBSD/man8/rc.local.8.html
26	[si10]: https://www.tenforums.com/tutorials/2944-add-delete-enable-disable-startup-items-windows-10-a.html
27	[si7]: https://www.wikihow.com/Change-Startup-Programs-in-Windows-7
28
29
30
31	## No Simple Background Mode
32
33	Windows also lacks a direct equivalent of the Bourne shell’s “`&`” control operator to
34	run a program in the background, which you can give in Unix’s `rc.local`
35	file, which is just a normal Bourne shell script.
36
37	By “background,” I mean
38	“not attached to any interactive user’s login session.” When the
39	`rc.local` script exits in Unix, any program it backgrounded *stays
40	running*. There is no simple and direct equivalent to this mechanism in
41	Windows.
42
43	If you set `fossil server` to run on interactive login, as above, it
44	will shut right back down again when that user logs back out.
45
46	With Windows 10, it’s especially problematic because you can no longer
47	make the OS put off updates arbitrarily: your Fossil server will go down
48	every time Windows Update decides it needs to reboot your computer, and
49	then Fossil service will stay down until someone logs back into that
50	machine interactively.
51
52
53	## Better Solutions
54
55	Because of these problems, we only recommend setting `fossil server` up
56	on Windows this way when
57	you’re a solo developer or you work in a small office where everyone
58	arrives more or less at the same time each day, and everyone goes home
59	about the same time each day, so that one user can keep the Fossil
60	server up through the working day.
61
62	If your needs go at all beyond this, you should expect proper “server”
63	behavior, which you can get on Windows by [registering Fossil as a
64	Windows service](./service.md), which solves the interactive startup and
65	shutdown problems above, at a bit of complexity over the Startup Items
66	method. You may also want to consider putting that service behind [an
67	IIS front-end proxy](./iis.md) to add additional web serving features.
68
69	[Return to the top-level Fossil server article.](../)

M www/server/windows/service.md

+15

		--- a/www/server/windows/service.md
		+++ b/www/server/windows/service.md
		@@ -0,0 +1,15 @@
	1	+# Fossil as a WiDir(...) API. -DSCM' running under the local
	2	+s
	3	+ running u 80 by default. `fossil winsrv`
	4	+ default. `fossil winsrv` car<a name='PowerShell'></a>
	5	+### (x86)\Fossil This
	6	+way Fossil is inYou do NOT
	7	+ Make Fossil a WindowsAs of Fossil 2.9 the built in API. -DSCM' runni# Fossil as a WiDir(...) API. -DSCM' running under the local
	8	+s
	9	+ running u (x86)\FossilSCM\fossil.exe"
	10	+paths passed to Fossil. Windows
	11	+has
	12	+...) API. -DSCM' running under the local
	13	+s
	14	+ running u 80 by default.# Fossil repository,
	15	+ to the

	--- a/www/server/windows/service.md
	+++ b/www/server/windows/service.md
	@@ -0,0 +1,15 @@

	--- a/www/server/windows/service.md
	+++ b/www/server/windows/service.md
	@@ -0,0 +1,15 @@
1	# Fossil as a WiDir(...) API. -DSCM' running under the local
2	s
3	running u 80 by default. `fossil winsrv`
4	default. `fossil winsrv` car<a name='PowerShell'></a>
5	### (x86)\Fossil This
6	way Fossil is inYou do NOT
7	Make Fossil a WindowsAs of Fossil 2.9 the built in API. -DSCM' runni# Fossil as a WiDir(...) API. -DSCM' running under the local
8	s
9	running u (x86)\FossilSCM\fossil.exe"
10	paths passed to Fossil. Windows
11	has
12	...) API. -DSCM' running under the local
13	s
14	running u 80 by default.# Fossil repository,
15	to the

M www/server/windows/stunnel.md

+129

		--- a/www/server/windows/stunnel.md
		+++ b/www/server/windows/stunnel.md
		@@ -0,0 +1,129 @@
	1	+Following most of [Fossil as a Windows Service](./service.md), you will need
	2	+to change the command to install the Fossil Service to configure it properly for
	3	+ configure
	4	+it properly for instead:
	5	+
	6	+```PowerShell
	7	+ following:
	8	+
	9	+```PowerShell
	10	+New-Service -Name fossil-secure -DisplayName fossil-secure -Binary (x86)\FossilSCM\fossil.exe"
	11	+iles\FossilSCM\fossil.exe" server --localhost --port 9000 --https --repolist "D:/Path/to/Repo
	12	+```
	13	+
	14	+The use of `--localhost` means Fossil will only listen for traffic on the local
	15	+host on the designated port - 9000 in this case - and will not respond to
	16	+network traffic. Using `--https` will tell Fossil to generate HTTPS URLs rather
	17	+than HTTP ones.
	18	+
	19	+`New-Service` does not automatically start a service on install, so you will
	20	+need to enter the following to avoid rebooting the server:
	21	+
	22	+```PowerShell
	23	+Start-Service -Name fossil-secure
	24	+```
	25	+
	26	+wershell is 6.0 or above.
	27	+
	28	+## Install stunnel 5.55
	29	+
	30	+Download stunnel from the [downloads](https://www.stunnel.org/downloads.html)
	31	+page. Select the latest stunnel windows package (at the time of writing this is
	32	+`stunnel-5.55-win64-installer.exe`). Execute the installer and make sure you
	33	+install openSSL tools when you install stunnel. You will need this to convert
	34	+your certificate from PFX to PEM format.
	35	+
	36	+Even though the installer says it is for win64, it installs stunnel by default
	37	+to `\Program Files (x86)\stunnel`.
	38	+
	39	+## Get your certificate ready for Stunnel
	40	+
	41	+Whether you use a Public Certificate Authority or Internal Certificate
	42	+Authority, the next step is exporting the certificate from Windows into a format
	43	+useable by Stunnel.
	44	+
	45	+### Export Certificate from Windows
	46	+
	47	+If your certificate is installed via Windows Certificate Management, you will
	48	+need to export the certificate into a usable format. You can do this either
	49	+using the Windows Certificate Management Console, or PowerShell.
	50	+
	51	+#### Certificate Management Console
	52	+
	53	+Start `mmc.exe` as an Administrator. Select 'File>Add/Remove Snapin', select
	54	+'Certificates' from the list, and click 'Add'. Select 'Computer Account',
	55	+'Next', 'Local Computer', and then 'Finish'. In the Console Root, expand
	56	+'Certificates', then 'Personal', and select 'Certificates'. In the middle pane
	57	+find and select your certificate. Right click the certificate and select
	58	+'All Tasks>Export'. You want to export as PFX the Private Key, include all
	59	+certificates in the certification path, and use a password only to secure the
	60	+file. Enter a path and file name to a working directory and complete the
	61	+export.
	62	+
	63	+Continue with [Convert Certificate from PFX to PEM](#convert).
	64	+
	65	+#### PowerShell
	66	+
	67	+If you know the Friendly
	68	+Name of the Certificate this is relatively easy. Since you need to export
	69	+the private key as well, you must run the following from an Administrative
	70	+PowerShell console.
	71	+
	72	+```PowerShell
	73	+$passwd = ConvertTo-SecureString -string "yourpassword" -Force -AsPlainText
	74	+
	75	+Get-ChildItem Cert:\LocalMachine\My \| Where{$_.FriendlyName -eq "FriendlyName"} \|
	76	+Export-PfxCertificate -FilePath fossil-scm.pfx -Password $passwd
	77	+```
	78	+
	79	+You will now have your certificatename="convert"></a>
	80	+### Convert Certificate from PFX to PEM
	81	+
	82	+For this step you will need the openssl tools that were installed with stunnel.
	83	+
	84	+```PowerShell
	85	+# Add stunnel\bin directory to path for this session.
	86	+$env:PATH += ";${env:ProgramFiles(x86)}\stunnel\bin"
	87	+# Export Private Key
	88	+openssl.exe pkcs12 -in fossil-scm.pfx -out fossil-scm.key -nocerts -nodes
	89	+# Export the Certificate
	90	+openssl.exe pkcs12 -in fossil-scm.pfx -out fossil-scm.pem -nokeys
	91	+```
	92	+
	93	+Now move `fossil-scm.key` and `fossil-scm.pem` to your stunnel config directory
	94	+(by default this should be located at `\Program Files (x86)\stunne\config`).
	95	+
	96	+## stunnel Configuration
	97	+
	98	+Use the reverse proxy configuration given in the generic [Serving via
	99	+stunnel document](../any/stunnel.md#proxy). On Windows, the
	100	+`stunnel.conf` file is located at `\Program Files (x86)\stunnel\config`.
	101	+
	102	+You will need to modify it to point at the PEM and key files generated
	103	+above.
	104	+
	105	+After completing the above configuration restart the stunnel service in Windows
	106	+with the following:
	107	+
	108	+```PowerShell
	109	+Restart-Service -Name stunnel
	110	+```
	111	+
	112	+## Open up port 443 in the Windows Firewall
	113	+
	114	+The following instructions are for the [Windows Advanced
	115	+Firewall](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security).
	116	+If you are using a different Firewall, please consult your Firewall
	117	+documentation for how to open port 443 for inbound traffic.
	118	+
	119	+The following command should be entered all on one line.
	120	+
	121	+```PowerShell
	122	+New-NetFirewallRule -DisplayName "Allow Fossil Inbound" -Description "Allow Fossil inbound on port 443 using Stunnel as TLS Proxy."
	123	+ -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow -Program "C:\Program Files (x86)\Stunnel\bin\stunnel.exe"
	124	+```
	125	+
	126	+You should now be able to access your new Fossil Server via HTTPS.
	127	+
	128	+
	129	+*[

	--- a/www/server/windows/stunnel.md
	+++ b/www/server/windows/stunnel.md
	@@ -0,0 +1,129 @@

	--- a/www/server/windows/stunnel.md
	+++ b/www/server/windows/stunnel.md
	@@ -0,0 +1,129 @@
1	Following most of [Fossil as a Windows Service](./service.md), you will need
2	to change the command to install the Fossil Service to configure it properly for
3	configure
4	it properly for instead:
5
6	```PowerShell
7	following:
8
9	```PowerShell
10	New-Service -Name fossil-secure -DisplayName fossil-secure -Binary (x86)\FossilSCM\fossil.exe"
11	iles\FossilSCM\fossil.exe" server --localhost --port 9000 --https --repolist "D:/Path/to/Repo
12	```
13
14	The use of `--localhost` means Fossil will only listen for traffic on the local
15	host on the designated port - 9000 in this case - and will not respond to
16	network traffic. Using `--https` will tell Fossil to generate HTTPS URLs rather
17	than HTTP ones.
18
19	`New-Service` does not automatically start a service on install, so you will
20	need to enter the following to avoid rebooting the server:
21
22	```PowerShell
23	Start-Service -Name fossil-secure
24	```
25
26	wershell is 6.0 or above.
27
28	## Install stunnel 5.55
29
30	Download stunnel from the [downloads](https://www.stunnel.org/downloads.html)
31	page. Select the latest stunnel windows package (at the time of writing this is
32	`stunnel-5.55-win64-installer.exe`). Execute the installer and make sure you
33	install openSSL tools when you install stunnel. You will need this to convert
34	your certificate from PFX to PEM format.
35
36	Even though the installer says it is for win64, it installs stunnel by default
37	to `\Program Files (x86)\stunnel`.
38
39	## Get your certificate ready for Stunnel
40
41	Whether you use a Public Certificate Authority or Internal Certificate
42	Authority, the next step is exporting the certificate from Windows into a format
43	useable by Stunnel.
44
45	### Export Certificate from Windows
46
47	If your certificate is installed via Windows Certificate Management, you will
48	need to export the certificate into a usable format. You can do this either
49	using the Windows Certificate Management Console, or PowerShell.
50
51	#### Certificate Management Console
52
53	Start `mmc.exe` as an Administrator. Select 'File>Add/Remove Snapin', select
54	'Certificates' from the list, and click 'Add'. Select 'Computer Account',
55	'Next', 'Local Computer', and then 'Finish'. In the Console Root, expand
56	'Certificates', then 'Personal', and select 'Certificates'. In the middle pane
57	find and select your certificate. Right click the certificate and select
58	'All Tasks>Export'. You want to export as PFX the Private Key, include all
59	certificates in the certification path, and use a password only to secure the
60	file. Enter a path and file name to a working directory and complete the
61	export.
62
63	Continue with [Convert Certificate from PFX to PEM](#convert).
64
65	#### PowerShell
66
67	If you know the Friendly
68	Name of the Certificate this is relatively easy. Since you need to export
69	the private key as well, you must run the following from an Administrative
70	PowerShell console.
71
72	```PowerShell
73	$passwd = ConvertTo-SecureString -string "yourpassword" -Force -AsPlainText
74
75	Get-ChildItem Cert:\LocalMachine\My \| Where{$_.FriendlyName -eq "FriendlyName"} \|
76	Export-PfxCertificate -FilePath fossil-scm.pfx -Password $passwd
77	```
78
79	You will now have your certificatename="convert"></a>
80	### Convert Certificate from PFX to PEM
81
82	For this step you will need the openssl tools that were installed with stunnel.
83
84	```PowerShell
85	# Add stunnel\bin directory to path for this session.
86	$env:PATH += ";${env:ProgramFiles(x86)}\stunnel\bin"
87	# Export Private Key
88	openssl.exe pkcs12 -in fossil-scm.pfx -out fossil-scm.key -nocerts -nodes
89	# Export the Certificate
90	openssl.exe pkcs12 -in fossil-scm.pfx -out fossil-scm.pem -nokeys
91	```
92
93	Now move `fossil-scm.key` and `fossil-scm.pem` to your stunnel config directory
94	(by default this should be located at `\Program Files (x86)\stunne\config`).
95
96	## stunnel Configuration
97
98	Use the reverse proxy configuration given in the generic [Serving via
99	stunnel document](../any/stunnel.md#proxy). On Windows, the
100	`stunnel.conf` file is located at `\Program Files (x86)\stunnel\config`.
101
102	You will need to modify it to point at the PEM and key files generated
103	above.
104
105	After completing the above configuration restart the stunnel service in Windows
106	with the following:
107
108	```PowerShell
109	Restart-Service -Name stunnel
110	```
111
112	## Open up port 443 in the Windows Firewall
113
114	The following instructions are for the [Windows Advanced
115	Firewall](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/windows-firewall-with-advanced-security).
116	If you are using a different Firewall, please consult your Firewall
117	documentation for how to open port 443 for inbound traffic.
118
119	The following command should be entered all on one line.
120
121	```PowerShell
122	New-NetFirewallRule -DisplayName "Allow Fossil Inbound" -Description "Allow Fossil inbound on port 443 using Stunnel as TLS Proxy."
123	-Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow -Program "C:\Program Files (x86)\Stunnel\bin\stunnel.exe"
124	```
125
126	You should now be able to access your new Fossil Server via HTTPS.
127
128
129	*[

M www/serverext.wiki

+30 -11

		--- www/serverext.wiki
		+++ www/serverext.wiki
		@@ -1,10 +1,10 @@
1	1	<title>CGI Server Extensions</title>
2	2
3	3	<h2>1.0 Introduction</h2>
4	4
5		-If you have a [./server.wiki\|Fossil server] for your project,
	5	+If you have a [./server/\|Fossil server] for your project,
6	6	you can add [https://en.wikipedia.org/wiki/Common_Gateway_Interface\|CGI]
7	7	extensions to that server. These extensions work like
8	8	any other CGI program, except that they also have access to the Fossil
9	9	login information and can (optionally) leverage the "skins" of Fossil
10	10	so that they appear to be more tightly integrated into the project.
		@@ -26,19 +26,22 @@
26	26	<h2>2.0 How It Works</h2>
27	27
28	28	CGI Extensions are disabled by default.
29	29	An administrator activates the CGI extension mechanism by specifying
30	30	an "Extension Root Directory" or "extroot" as part of the server setup.
31		-If the Fossil server is itself run as CGI, then add a line to the CGI
32		-script file that says:
	31	+If the Fossil server is itself run as
	32	+[./server/any/cgi.md\|CGI], then add a line to the
	33	+[./cgi.wiki#extroot\|CGI script file] that says:
33	34
34	35	<blockquote><pre>
35	36	extroot: <i>DIRECTORY</i>
36	37	</pre></blockquote>
37	38
38		-Or, if the Fossil server is begin run as using the "fossil server" or
39		-"fossil ui" or "fossil http" commands, then add an extra
	39	+Or, if the Fossil server is begin run as using the
	40	+"[./server/any/none.md\|fossil server]" or
	41	+"[./server/any/none.md\|fossil ui]" or
	42	+"[./server/any/inetd.md\|fossil http]" commands, then add an extra
40	43	"--extroot <i>DIRECTORY</i>" option to that command.
41	44
42	45	The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
43	46	Files in the DOCUMENT_ROOT are accessed via URLs like this:
44	47
		@@ -85,16 +88,16 @@
85	88	[https://www.sqlite.org/src/ext/checklist/self] and
86	89	recent historical versions are available at
87	90	[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with
88	91	older legacy at [https://sqlite.org/checklistapp/timeline?n=all]
89	92
90		-There is a cascade of CGIs happening here. The webserver that receives
	93	+There is a cascade of CGIs happening here. The web server that receives
91	94	the initial HTTP request runs Fossil as a CGI based on the
92	95	"https://sqlite.org/src" portion of the URL. The Fossil instance then
93	96	runs the checklist sub-CGI based on the "/ext/checklists" suffix. The
94	97	output of the sub-CGI is read by Fossil and then relayed on to the
95		-main webserver which in turn relays the result back to the original client.
	98	+main web server which in turn relays the result back to the original client.
96	99
97	100	<h3>2.2 Example #2</h3>
98	101
99	102	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
100	103	a CGI that looks like this:
		@@ -106,11 +109,11 @@
106	109	extroot: /fossil-extroot
107	110	</verbatim></blockquote>
108	111
109	112	The extroot for this Fossil server is /fossil-extroot and in that directory
110	113	is an executable file named "fileup1" - another [https://wapp.tcl.tk\|Wapp]
111		-script. (The extension mechanism does not have to use Wapp. You can use
	114	+script. (The extension mechanism is not required to use Wapp. You can use
112	115	any kind of program you like. But the creator of SQLite and Fossil is fond
113	116	of [https://www.tcl.tk\|Tcl/Tk] and so he tends to gravitate toward Tcl-based
114	117	technologies like Wapp.) The fileup1 script is a demo program that lets
115	118	the user upload a file using a form, and then displays that file in the reply.
116	119	There is a link on the page that causes the fileup1 script to return a copy
		@@ -155,16 +158,17 @@
155	158	they are used.
156	159	Live listings of the values of some or all of these environment variables
157	160	can be found at links like these:
158	161
159	162	* [https://fossil-scm.org/home/test_env]
160		- * [https://sqlite.org/src/ext/checklist/env]
	163	+ * [https://sqlite.org/src/ext/checklist/top/env]
161	164
162	165	In addition to the standard CGI environment variables listed above,
163	166	Fossil adds the following:
164	167
165	168	* FOSSIL_CAPABILITIES
	169	+ * FOSSIL_NONCE
166	170	* FOSSIL_REPOSITORY
167	171	* FOSSIL_URI
168	172	* FOSSIL_USER
169	173
170	174	The FOSSIL_USER string is the name of the logged-in user. This variable
		@@ -182,21 +186,36 @@
182	186	the FOSSIL_CAPABILITIES variable to determine if the user is allowed to
183	187	mark off changes to the checklist. Only users with check-in permission
184	188	to the Fossil repository are allowed to mark off checklist items. That
185	189	means that the FOSSIL_CAPABILITIES string must contain the letter "i".
186	190	Search for "FOSSIL_CAPABILITIES" in the
187		-[https://sqlite.org/src/ext/checklist/self\|source listing] to see how
	191	+[https://sqlite.org/src/ext/checklist/top/self\|source listing] to see how
188	192	this happens.
	193	+
	194	+If the CGI output is one of the forms for which Fossil inserts its own
	195	+header and footer, then the inserted header will include a
	196	+Content Security Policy (CSP) restriction on the use of javascript within
	197	+the webpage. Any <script>...</script> elements within the
	198	+CGI output must include a nonce or else they will be suppressed by the
	199	+web browser. The FOSSIL_NONCE variable contains the value of that nonce.
	200	+So, in other words, to get javascript to work, it must be enclosed in:
	201	+
	202	+<blockquote><verbatim>
	203	+<script nonce='$FOSSIL_NONCE'>...</script>
	204	+</verbatim></blockquote>
	205	+
	206	+Except, of course, the $FOSSIL_NONCE is replace by the value of the
	207	+FOSSIL_NONCE environment variable.
189	208
190	209	If the HTTP request includes content (for example if this is a POST request)
191	210	then the CONTENT_LENGTH value will be positive and the data for the content
192	211	will be readable on standard input.
193	212
194	213	<h2>4.0 CGI Outputs</h2>
195	214
196	215	CGI programs construct a reply by writing to standard output. The first
197		-few lines of output are parameters intended for the webserver that invoked
	216	+few lines of output are parameters intended for the web server that invoked
198	217	the CGI. These are followed by a blank line and then the content.
199	218
200	219	Typical parameter output looks like this:
201	220
202	221	<blockquote><verbatim>
203	222

	--- www/serverext.wiki
	+++ www/serverext.wiki
	@@ -1,10 +1,10 @@
1	<title>CGI Server Extensions</title>
2
3	<h2>1.0 Introduction</h2>
4
5	If you have a [./server.wiki\|Fossil server] for your project,
6	you can add [https://en.wikipedia.org/wiki/Common_Gateway_Interface\|CGI]
7	extensions to that server. These extensions work like
8	any other CGI program, except that they also have access to the Fossil
9	login information and can (optionally) leverage the "skins" of Fossil
10	so that they appear to be more tightly integrated into the project.
	@@ -26,19 +26,22 @@
26	<h2>2.0 How It Works</h2>
27
28	CGI Extensions are disabled by default.
29	An administrator activates the CGI extension mechanism by specifying
30	an "Extension Root Directory" or "extroot" as part of the server setup.
31	If the Fossil server is itself run as CGI, then add a line to the CGI
32	script file that says:

33
34	<blockquote><pre>
35	extroot: <i>DIRECTORY</i>
36	</pre></blockquote>
37
38	Or, if the Fossil server is begin run as using the "fossil server" or
39	"fossil ui" or "fossil http" commands, then add an extra


40	"--extroot <i>DIRECTORY</i>" option to that command.
41
42	The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
43	Files in the DOCUMENT_ROOT are accessed via URLs like this:
44
	@@ -85,16 +88,16 @@
85	[https://www.sqlite.org/src/ext/checklist/self] and
86	recent historical versions are available at
87	[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with
88	older legacy at [https://sqlite.org/checklistapp/timeline?n=all]
89
90	There is a cascade of CGIs happening here. The webserver that receives
91	the initial HTTP request runs Fossil as a CGI based on the
92	"https://sqlite.org/src" portion of the URL. The Fossil instance then
93	runs the checklist sub-CGI based on the "/ext/checklists" suffix. The
94	output of the sub-CGI is read by Fossil and then relayed on to the
95	main webserver which in turn relays the result back to the original client.
96
97	<h3>2.2 Example #2</h3>
98
99	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
100	a CGI that looks like this:
	@@ -106,11 +109,11 @@
106	extroot: /fossil-extroot
107	</verbatim></blockquote>
108
109	The extroot for this Fossil server is /fossil-extroot and in that directory
110	is an executable file named "fileup1" - another [https://wapp.tcl.tk\|Wapp]
111	script. (The extension mechanism does not have to use Wapp. You can use
112	any kind of program you like. But the creator of SQLite and Fossil is fond
113	of [https://www.tcl.tk\|Tcl/Tk] and so he tends to gravitate toward Tcl-based
114	technologies like Wapp.) The fileup1 script is a demo program that lets
115	the user upload a file using a form, and then displays that file in the reply.
116	There is a link on the page that causes the fileup1 script to return a copy
	@@ -155,16 +158,17 @@
155	they are used.
156	Live listings of the values of some or all of these environment variables
157	can be found at links like these:
158
159	* [https://fossil-scm.org/home/test_env]
160	* [https://sqlite.org/src/ext/checklist/env]
161
162	In addition to the standard CGI environment variables listed above,
163	Fossil adds the following:
164
165	* FOSSIL_CAPABILITIES

166	* FOSSIL_REPOSITORY
167	* FOSSIL_URI
168	* FOSSIL_USER
169
170	The FOSSIL_USER string is the name of the logged-in user. This variable
	@@ -182,21 +186,36 @@
182	the FOSSIL_CAPABILITIES variable to determine if the user is allowed to
183	mark off changes to the checklist. Only users with check-in permission
184	to the Fossil repository are allowed to mark off checklist items. That
185	means that the FOSSIL_CAPABILITIES string must contain the letter "i".
186	Search for "FOSSIL_CAPABILITIES" in the
187	[https://sqlite.org/src/ext/checklist/self\|source listing] to see how
188	this happens.















189
190	If the HTTP request includes content (for example if this is a POST request)
191	then the CONTENT_LENGTH value will be positive and the data for the content
192	will be readable on standard input.
193
194	<h2>4.0 CGI Outputs</h2>
195
196	CGI programs construct a reply by writing to standard output. The first
197	few lines of output are parameters intended for the webserver that invoked
198	the CGI. These are followed by a blank line and then the content.
199
200	Typical parameter output looks like this:
201
202	<blockquote><verbatim>
203

	--- www/serverext.wiki
	+++ www/serverext.wiki
	@@ -1,10 +1,10 @@
1	<title>CGI Server Extensions</title>
2
3	<h2>1.0 Introduction</h2>
4
5	If you have a [./server/\|Fossil server] for your project,
6	you can add [https://en.wikipedia.org/wiki/Common_Gateway_Interface\|CGI]
7	extensions to that server. These extensions work like
8	any other CGI program, except that they also have access to the Fossil
9	login information and can (optionally) leverage the "skins" of Fossil
10	so that they appear to be more tightly integrated into the project.
	@@ -26,19 +26,22 @@
26	<h2>2.0 How It Works</h2>
27
28	CGI Extensions are disabled by default.
29	An administrator activates the CGI extension mechanism by specifying
30	an "Extension Root Directory" or "extroot" as part of the server setup.
31	If the Fossil server is itself run as
32	[./server/any/cgi.md\|CGI], then add a line to the
33	[./cgi.wiki#extroot\|CGI script file] that says:
34
35	<blockquote><pre>
36	extroot: <i>DIRECTORY</i>
37	</pre></blockquote>
38
39	Or, if the Fossil server is begin run as using the
40	"[./server/any/none.md\|fossil server]" or
41	"[./server/any/none.md\|fossil ui]" or
42	"[./server/any/inetd.md\|fossil http]" commands, then add an extra
43	"--extroot <i>DIRECTORY</i>" option to that command.
44
45	The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
46	Files in the DOCUMENT_ROOT are accessed via URLs like this:
47
	@@ -85,16 +88,16 @@
88	[https://www.sqlite.org/src/ext/checklist/self] and
89	recent historical versions are available at
90	[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with
91	older legacy at [https://sqlite.org/checklistapp/timeline?n=all]
92
93	There is a cascade of CGIs happening here. The web server that receives
94	the initial HTTP request runs Fossil as a CGI based on the
95	"https://sqlite.org/src" portion of the URL. The Fossil instance then
96	runs the checklist sub-CGI based on the "/ext/checklists" suffix. The
97	output of the sub-CGI is read by Fossil and then relayed on to the
98	main web server which in turn relays the result back to the original client.
99
100	<h3>2.2 Example #2</h3>
101
102	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
103	a CGI that looks like this:
	@@ -106,11 +109,11 @@
109	extroot: /fossil-extroot
110	</verbatim></blockquote>
111
112	The extroot for this Fossil server is /fossil-extroot and in that directory
113	is an executable file named "fileup1" - another [https://wapp.tcl.tk\|Wapp]
114	script. (The extension mechanism is not required to use Wapp. You can use
115	any kind of program you like. But the creator of SQLite and Fossil is fond
116	of [https://www.tcl.tk\|Tcl/Tk] and so he tends to gravitate toward Tcl-based
117	technologies like Wapp.) The fileup1 script is a demo program that lets
118	the user upload a file using a form, and then displays that file in the reply.
119	There is a link on the page that causes the fileup1 script to return a copy
	@@ -155,16 +158,17 @@
158	they are used.
159	Live listings of the values of some or all of these environment variables
160	can be found at links like these:
161
162	* [https://fossil-scm.org/home/test_env]
163	* [https://sqlite.org/src/ext/checklist/top/env]
164
165	In addition to the standard CGI environment variables listed above,
166	Fossil adds the following:
167
168	* FOSSIL_CAPABILITIES
169	* FOSSIL_NONCE
170	* FOSSIL_REPOSITORY
171	* FOSSIL_URI
172	* FOSSIL_USER
173
174	The FOSSIL_USER string is the name of the logged-in user. This variable
	@@ -182,21 +186,36 @@
186	the FOSSIL_CAPABILITIES variable to determine if the user is allowed to
187	mark off changes to the checklist. Only users with check-in permission
188	to the Fossil repository are allowed to mark off checklist items. That
189	means that the FOSSIL_CAPABILITIES string must contain the letter "i".
190	Search for "FOSSIL_CAPABILITIES" in the
191	[https://sqlite.org/src/ext/checklist/top/self\|source listing] to see how
192	this happens.
193
194	If the CGI output is one of the forms for which Fossil inserts its own
195	header and footer, then the inserted header will include a
196	Content Security Policy (CSP) restriction on the use of javascript within
197	the webpage. Any <script>...</script> elements within the
198	CGI output must include a nonce or else they will be suppressed by the
199	web browser. The FOSSIL_NONCE variable contains the value of that nonce.
200	So, in other words, to get javascript to work, it must be enclosed in:
201
202	<blockquote><verbatim>
203	<script nonce='$FOSSIL_NONCE'>...</script>
204	</verbatim></blockquote>
205
206	Except, of course, the $FOSSIL_NONCE is replace by the value of the
207	FOSSIL_NONCE environment variable.
208
209	If the HTTP request includes content (for example if this is a POST request)
210	then the CONTENT_LENGTH value will be positive and the data for the content
211	will be readable on standard input.
212
213	<h2>4.0 CGI Outputs</h2>
214
215	CGI programs construct a reply by writing to standard output. The first
216	few lines of output are parameters intended for the web server that invoked
217	the CGI. These are followed by a blank line and then the content.
218
219	Typical parameter output looks like this:
220
221	<blockquote><verbatim>
222

M www/ssl.wiki

+8 -63

		--- www/ssl.wiki
		+++ www/ssl.wiki
		@@ -1,6 +1,6 @@
1		-<title>TLS and Fossil</title>
	1	+<title>Securing a Repository with TLS</title>
2	2
3	3	<h2>Using TLS-Encrypted Communications with Fossil</h2>
4	4
5	5	If you are storing sensitive information in a repository accessible over
6	6	a network whose integrity you do not fully trust, you should use TLS to
		@@ -206,72 +206,17 @@
206	206	<h2 id="server">Fossil TLS Configuration: Server Side</h2>
207	207
208	208	Fossil's built-in HTTP server feature does not currently have a built-in
209	209	way to serve via HTTP over TLS, a.k.a. HTTPS, even when you've linked
210	210	Fossil to OpenSSL. To serve a Fossil repository via HTTPS, you must put
211		-it behind some kind of HTTPS proxy.
212		-
213		-
214		-<h3 id="stunnel">stunnel Alone</h3>
215		-
216		-[https://www.stunnel.org/ \| <tt>stunnel</tt>] is an
217		-[https://en.wikipedia.org/wiki/Inetd \| <tt>inetd</tt>]-like process that
218		-accepts and decodes TLS-encrypted connections. It can directly proxy
219		-Fossil communications, allowing secure TLS-encrypted communications to a
220		-Fossil repository server. You simply need to install <tt>stunnel</tt>
221		-and then place something like this in its main configuration file,
222		-<tt>stunnel.conf</tt>:
223		-
224		-<nowiki><pre>
225		- [https]
226		- accept = www.ubercool-project.org:443
227		- TIMEOUTclose = 0
228		- exec = /usr/bin/fossil
229		- execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
230		-</pre></nowiki>
231		-
232		-The directory where that file goes varies between OSes, so check the man
233		-pages on your system to find out where it should be locally.
234		-
235		-See the <tt>stunnel</tt> documentation for further details about this
236		-configuration file.
237		-
238		-It is important that the [/help/http \| <tt>fossil http</tt>] command in
239		-that configuration include the <tt>--https</tt> option to let Fossil
240		-know to use "<tt>https</tt>" instead of "<tt>http</tt>" as the URL
241		-scheme on generated hyperlinks.
242		-
243		-
244		-<h3 id="althttpd">stunnel + althttpd</h3>
245		-
246		-The public SQLite and Fossil web sites can't just use stunnel + Fossil
247		-because parts of the web site are static, served by
248		-[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|a separate web
249		-server called <tt>althttpd</tt>], written by the primary author of both
250		-SQLite and Fossil. <tt>althttpd</tt> is a lightweight HTTP-only web
251		-server. It handles the static HTTP hits on <tt>sqlite.org</tt> and
252		-<tt>fossil-scm.org</tt>, delegating HTTPS hits to stunnel and dynamic
253		-content hits to Fossil.
254		-
255		-(The largest single chunk of static content served directly by
256		-<tt>althttpd</tt> rather than via Fossil is the
257		-[https://sqlite.org/docs.html \| SQLite documentation], which is built
258		-[https://sqlite.org/docsrc/ \| from source files] and then served
259		-statically.)
260		-
261		-In addition to the documentation linked above, there is a large header
262		-comment in the [https://sqlite.org/docsrc/file/misc/althttpd.c\|single C
263		-file] of <tt>althttpd</tt> which is most helpful.
264		-
265		-
266		-<h3 id="nginx">nginx</h3>
267		-
268		-If your needs are more complex than althttpd can handle or you'd prefer
269		-to use only software available in your server operating system's package
270		-repository, we recommend that you step up to [http://nginx.org/\|nginx].
271		-Setting this up is complex enough that we cover it [./tls-nginx.md\|in a
272		-separate document].
	211	+it behind some kind of HTTPS proxy. We have a number of documents
	212	+elsewhere in this repository that cover your options for [./server/
	213	+\| serving Fossil repositories]. A few of the most useful of these are:
	214	+
	215	+ * <a id="stunnel" href="./server/any/stunnel.md">Serving via stunnel</a>
	216	+ * <a id="althttpd" href="./server/any/althttpd.md">Serving via stunnel + althttpd</a>
	217	+ * <a id="nginx" href="./server/any/scgi.md">Serving via SCGI (nginx)</a>
273	218
274	219
275	220	<h2 id="enforcing">Enforcing TLS Access</h2>
276	221
277	222	To use TLS encryption in cloning and syncing to a remote Fossil
278	223

	--- www/ssl.wiki
	+++ www/ssl.wiki
	@@ -1,6 +1,6 @@
1	<title>TLS and Fossil</title>
2
3	<h2>Using TLS-Encrypted Communications with Fossil</h2>
4
5	If you are storing sensitive information in a repository accessible over
6	a network whose integrity you do not fully trust, you should use TLS to
	@@ -206,72 +206,17 @@
206	<h2 id="server">Fossil TLS Configuration: Server Side</h2>
207
208	Fossil's built-in HTTP server feature does not currently have a built-in
209	way to serve via HTTP over TLS, a.k.a. HTTPS, even when you've linked
210	Fossil to OpenSSL. To serve a Fossil repository via HTTPS, you must put
211	it behind some kind of HTTPS proxy.
212
213
214	<h3 id="stunnel">stunnel Alone</h3>
215
216	[https://www.stunnel.org/ \| <tt>stunnel</tt>] is an
217	[https://en.wikipedia.org/wiki/Inetd \| <tt>inetd</tt>]-like process that
218	accepts and decodes TLS-encrypted connections. It can directly proxy
219	Fossil communications, allowing secure TLS-encrypted communications to a
220	Fossil repository server. You simply need to install <tt>stunnel</tt>
221	and then place something like this in its main configuration file,
222	<tt>stunnel.conf</tt>:
223
224	<nowiki><pre>
225	[https]
226	accept = www.ubercool-project.org:443
227	TIMEOUTclose = 0
228	exec = /usr/bin/fossil
229	execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
230	</pre></nowiki>
231
232	The directory where that file goes varies between OSes, so check the man
233	pages on your system to find out where it should be locally.
234
235	See the <tt>stunnel</tt> documentation for further details about this
236	configuration file.
237
238	It is important that the [/help/http \| <tt>fossil http</tt>] command in
239	that configuration include the <tt>--https</tt> option to let Fossil
240	know to use "<tt>https</tt>" instead of "<tt>http</tt>" as the URL
241	scheme on generated hyperlinks.
242
243
244	<h3 id="althttpd">stunnel + althttpd</h3>
245
246	The public SQLite and Fossil web sites can't just use stunnel + Fossil
247	because parts of the web site are static, served by
248	[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|a separate web
249	server called <tt>althttpd</tt>], written by the primary author of both
250	SQLite and Fossil. <tt>althttpd</tt> is a lightweight HTTP-only web
251	server. It handles the static HTTP hits on <tt>sqlite.org</tt> and
252	<tt>fossil-scm.org</tt>, delegating HTTPS hits to stunnel and dynamic
253	content hits to Fossil.
254
255	(The largest single chunk of static content served directly by
256	<tt>althttpd</tt> rather than via Fossil is the
257	[https://sqlite.org/docs.html \| SQLite documentation], which is built
258	[https://sqlite.org/docsrc/ \| from source files] and then served
259	statically.)
260
261	In addition to the documentation linked above, there is a large header
262	comment in the [https://sqlite.org/docsrc/file/misc/althttpd.c\|single C
263	file] of <tt>althttpd</tt> which is most helpful.
264
265
266	<h3 id="nginx">nginx</h3>
267
268	If your needs are more complex than althttpd can handle or you'd prefer
269	to use only software available in your server operating system's package
270	repository, we recommend that you step up to [http://nginx.org/\|nginx].
271	Setting this up is complex enough that we cover it [./tls-nginx.md\|in a
272	separate document].
273
274
275	<h2 id="enforcing">Enforcing TLS Access</h2>
276
277	To use TLS encryption in cloning and syncing to a remote Fossil
278

	--- www/ssl.wiki
	+++ www/ssl.wiki
	@@ -1,6 +1,6 @@
1	<title>Securing a Repository with TLS</title>
2
3	<h2>Using TLS-Encrypted Communications with Fossil</h2>
4
5	If you are storing sensitive information in a repository accessible over
6	a network whose integrity you do not fully trust, you should use TLS to
	@@ -206,72 +206,17 @@
206	<h2 id="server">Fossil TLS Configuration: Server Side</h2>
207
208	Fossil's built-in HTTP server feature does not currently have a built-in
209	way to serve via HTTP over TLS, a.k.a. HTTPS, even when you've linked
210	Fossil to OpenSSL. To serve a Fossil repository via HTTPS, you must put
211	it behind some kind of HTTPS proxy. We have a number of documents
212	elsewhere in this repository that cover your options for [./server/
213	\| serving Fossil repositories]. A few of the most useful of these are:
214
215	* <a id="stunnel" href="./server/any/stunnel.md">Serving via stunnel</a>
216	* <a id="althttpd" href="./server/any/althttpd.md">Serving via stunnel + althttpd</a>
217	* <a id="nginx" href="./server/any/scgi.md">Serving via SCGI (nginx)</a>























































218
219
220	<h2 id="enforcing">Enforcing TLS Access</h2>
221
222	To use TLS encryption in cloning and syncing to a remote Fossil
223

M www/stats.wiki

+1 -1

		--- www/stats.wiki
		+++ www/stats.wiki
		@@ -125,11 +125,11 @@
125	125	(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB"
126	126	means megabytes and kilobytes, not mebibytes and kibibytes.
127	127
128	128	<h2>Analysis And Supplemental Data</h2>
129	129
130		-Perhaps the two most interesting datapoints in the above table are SQLite
	130	+Perhaps the two most interesting data points in the above table are SQLite
131	131	and SLT. SQLite is a long-running project with long revision chains.
132	132	Some of the files in SQLite have been edited over a thousand times.
133	133	Each of these edits is stored as a delta, and hence the SQLite project
134	134	gets excellent 80:1 compression. SLT, on the other hand, consists of
135	135	many large (megabyte-sized) SQL scripts that have one or maybe two
136	136

	--- www/stats.wiki
	+++ www/stats.wiki
	@@ -125,11 +125,11 @@
125	(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB"
126	means megabytes and kilobytes, not mebibytes and kibibytes.
127
128	<h2>Analysis And Supplemental Data</h2>
129
130	Perhaps the two most interesting datapoints in the above table are SQLite
131	and SLT. SQLite is a long-running project with long revision chains.
132	Some of the files in SQLite have been edited over a thousand times.
133	Each of these edits is stored as a delta, and hence the SQLite project
134	gets excellent 80:1 compression. SLT, on the other hand, consists of
135	many large (megabyte-sized) SQL scripts that have one or maybe two
136

	--- www/stats.wiki
	+++ www/stats.wiki
	@@ -125,11 +125,11 @@
125	(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB"
126	means megabytes and kilobytes, not mebibytes and kibibytes.
127
128	<h2>Analysis And Supplemental Data</h2>
129
130	Perhaps the two most interesting data points in the above table are SQLite
131	and SLT. SQLite is a long-running project with long revision chains.
132	Some of the files in SQLite have been edited over a thousand times.
133	Each of these edits is stored as a delta, and hence the SQLite project
134	gets excellent 80:1 compression. SLT, on the other hand, consists of
135	many large (megabyte-sized) SQL scripts that have one or maybe two
136

M www/sync.wiki

+1 -1

		--- www/sync.wiki
		+++ www/sync.wiki
		@@ -59,11 +59,11 @@
59	59
60	60	<p>The server might be running as an independent server
61	61	using the <b>server</b> command, or it might be launched from
62	62	inetd or xinetd using the <b>http</b> command. Or the server might
63	63	be launched from CGI.
64		-(See "[./server.wiki\|How To Configure A Fossil Server]" for details.)
	64	+(See "[./server/\|How To Configure A Fossil Server]" for details.)
65	65	The specifics of how the server listens
66	66	for incoming HTTP requests is immaterial to this protocol.
67	67	The important point is that the server is listening for requests and
68	68	the client is the issuer of the requests.</p>
69	69
70	70

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -59,11 +59,11 @@
59
60	<p>The server might be running as an independent server
61	using the <b>server</b> command, or it might be launched from
62	inetd or xinetd using the <b>http</b> command. Or the server might
63	be launched from CGI.
64	(See "[./server.wiki\|How To Configure A Fossil Server]" for details.)
65	The specifics of how the server listens
66	for incoming HTTP requests is immaterial to this protocol.
67	The important point is that the server is listening for requests and
68	the client is the issuer of the requests.</p>
69
70

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -59,11 +59,11 @@
59
60	<p>The server might be running as an independent server
61	using the <b>server</b> command, or it might be launched from
62	inetd or xinetd using the <b>http</b> command. Or the server might
63	be launched from CGI.
64	(See "[./server/\|How To Configure A Fossil Server]" for details.)
65	The specifics of how the server listens
66	for incoming HTTP requests is immaterial to this protocol.
67	The important point is that the server is listening for requests and
68	the client is the issuer of the requests.</p>
69
70

M www/tech_overview.wiki

+2 -2

		--- www/tech_overview.wiki
		+++ www/tech_overview.wiki
		@@ -166,11 +166,11 @@
166	166	The enduring file format for Fossil is the unordered
167	167	set of artifacts. The compression techniques are just a detail of
168	168	how the current implementation of Fossil happens to store these artifacts
169	169	efficiently on disk.
170	170
171		-All of the original uncompressed and undeltaed artifacts can be extracted
	171	+All of the original uncompressed and un-delta'd artifacts can be extracted
172	172	from a Fossil repository database using
173	173	the [/help/deconstruct \| fossil deconstruct]
174	174	command. Individual artifacts can be extracted using the
175	175	[/help/artifact \| fossil artifact] command.
176	176	When accessing the repository database using raw SQL and the
		@@ -314,11 +314,11 @@
314	314	For Fossil commands that run from within a working checkout, the
315	315	first thing that happens is that Fossil locates the checkout database.
316	316	Fossil first looks in the current directory. If not found there, it
317	317	looks in the parent directory. If not found there, the parent of the
318	318	parent. And so forth until either the checkout database is found
319		-or the search reaches the root of the filesystem. (In the latter case,
	319	+or the search reaches the root of the file system. (In the latter case,
320	320	Fossil returns an error, of course.) Once the checkout database is
321	321	located, it is used to locate the repository database.
322	322
323	323	Notice that the checkout database contains a pointer to the repository
324	324	database but that the repository database has no record of the checkout
325	325

	--- www/tech_overview.wiki
	+++ www/tech_overview.wiki
	@@ -166,11 +166,11 @@
166	The enduring file format for Fossil is the unordered
167	set of artifacts. The compression techniques are just a detail of
168	how the current implementation of Fossil happens to store these artifacts
169	efficiently on disk.
170
171	All of the original uncompressed and undeltaed artifacts can be extracted
172	from a Fossil repository database using
173	the [/help/deconstruct \| fossil deconstruct]
174	command. Individual artifacts can be extracted using the
175	[/help/artifact \| fossil artifact] command.
176	When accessing the repository database using raw SQL and the
	@@ -314,11 +314,11 @@
314	For Fossil commands that run from within a working checkout, the
315	first thing that happens is that Fossil locates the checkout database.
316	Fossil first looks in the current directory. If not found there, it
317	looks in the parent directory. If not found there, the parent of the
318	parent. And so forth until either the checkout database is found
319	or the search reaches the root of the filesystem. (In the latter case,
320	Fossil returns an error, of course.) Once the checkout database is
321	located, it is used to locate the repository database.
322
323	Notice that the checkout database contains a pointer to the repository
324	database but that the repository database has no record of the checkout
325

	--- www/tech_overview.wiki
	+++ www/tech_overview.wiki
	@@ -166,11 +166,11 @@
166	The enduring file format for Fossil is the unordered
167	set of artifacts. The compression techniques are just a detail of
168	how the current implementation of Fossil happens to store these artifacts
169	efficiently on disk.
170
171	All of the original uncompressed and un-delta'd artifacts can be extracted
172	from a Fossil repository database using
173	the [/help/deconstruct \| fossil deconstruct]
174	command. Individual artifacts can be extracted using the
175	[/help/artifact \| fossil artifact] command.
176	When accessing the repository database using raw SQL and the
	@@ -314,11 +314,11 @@
314	For Fossil commands that run from within a working checkout, the
315	first thing that happens is that Fossil locates the checkout database.
316	Fossil first looks in the current directory. If not found there, it
317	looks in the parent directory. If not found there, the parent of the
318	parent. And so forth until either the checkout database is found
319	or the search reaches the root of the file system. (In the latter case,
320	Fossil returns an error, of course.) Once the checkout database is
321	located, it is used to locate the repository database.
322
323	Notice that the checkout database contains a pointer to the repository
324	database but that the repository database has no record of the checkout
325

M www/tickets.wiki

+7 -7

		--- www/tickets.wiki
		+++ www/tickets.wiki
		@@ -10,28 +10,28 @@
10	10
11	11	Each ticket change artifact contains the following information:
12	12
13	13	<ul>
14	14	<li>The ID of the ticket that was changed
15		-<li>The timestamp for when the change occurred
	15	+<li>The time stamp for when the change occurred
16	16	<li>The user who made the change
17	17	<li>A list of key/value pairs that show what changed in the ticket
18	18	</ul>
19	19
20	20	To determine the current state of a particular ticket, Fossil orders
21	21	the change artifacts for that ticket from oldest to most recent,
22		-then applies each change in timestamp order.
	22	+then applies each change in time stamp order.
23	23
24	24	On each change artifact, there are one or more key/value pairs that
25	25	implement the change. The key corresponds to a field of the ticket
26	26	that is modified. The value may either replace the earlier value for
27	27	that key, or the value may be appended to the prior value.
28	28
29	29	<h2>2.0 Ticket Tables</h2>
30	30
31	31	The low-level artifact format for ticket content is tedious and
32		-cumbersome to access in realtime. To facility reporting and display
	32	+cumbersome to access in real time. To facility reporting and display
33	33	of tickets, the low-level artifact information is collected and
34	34	summarized in a pair of SQL tables in each local repository. Display
35	35	and reporting of tickets is accomplished by querying these two tables.
36	36
37	37	Note that only the low-level ticket change artifacts are synced. The
		@@ -132,12 +132,12 @@
132	132
133	133	Each row in the TICKETCHNG table corresponds to a single ticket change
134	134	artifact. The tkt_id field is the integer primary key of the TICKET
135	135	table entry for the corresponding ticket. The tkt_rid field is the
136	136	integer primary key for the BLOB table entry that contains the low-level
137		-artifact text. The tkt_mtime field is the timestamp on the ticket
138		-change artifact, expressed as a julian day number. If the ticket
	137	+artifact text. The tkt_mtime field is the time stamp on the ticket
	138	+change artifact, expressed as a Julian day number. If the ticket
139	139	change artifact contains a key/value pair where the key is "login",
140	140	then the corresponding value is stored in the login field of the
141	141	TICKETCHNG table. The same it true for "username", "mimetype", and
142	142	"icomment" fields. Any time there is a key/value pair in the ticket
143	143	change artifact and the key corresponds to the name of a field in the
		@@ -154,11 +154,11 @@
154	154	hexadecimal constant. The tkt_mtime and tkt_ctime fields hold the
155	155	times of the most recent and the oldest ticket change artifacts for
156	156	this ticket, respectively.
157	157
158	158	To reconstruct the TICKET table, the ticket change
159		-artifacts are visited in timestamp order. As each ticket change artifact is
	159	+artifacts are visited in time stamp order. As each ticket change artifact is
160	160	visited, its key/value pairs are examined. For any key/value pair in
161	161	which the key is the same as a field in the TICKET table, the value
162	162	of that pair either replaces or is appended to the previous value
163	163	of the corresponding field in the TICKET table. Whether a value is
164	164	replaced or appended is determined by markings in the ticket change
		@@ -194,6 +194,6 @@
194	194	The TICKETCHNG table was added to support new-style tickets. In the new
195	195	style, comment text is stored with the "icomment" (for "Incremental Comment")
196	196	key and appears separately, and with its on mimetype, in multiple rows
197	197	of the TICKETCHNG table. It then falls to the TH1 script code on the
198	198	View Ticket Page to query the TICKETCHNG table and extract and format
199		-the various comments in timestamp order.
	199	+the various comments in time stamp order.
200	200

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -10,28 +10,28 @@
10
11	Each ticket change artifact contains the following information:
12
13	<ul>
14	<li>The ID of the ticket that was changed
15	<li>The timestamp for when the change occurred
16	<li>The user who made the change
17	<li>A list of key/value pairs that show what changed in the ticket
18	</ul>
19
20	To determine the current state of a particular ticket, Fossil orders
21	the change artifacts for that ticket from oldest to most recent,
22	then applies each change in timestamp order.
23
24	On each change artifact, there are one or more key/value pairs that
25	implement the change. The key corresponds to a field of the ticket
26	that is modified. The value may either replace the earlier value for
27	that key, or the value may be appended to the prior value.
28
29	<h2>2.0 Ticket Tables</h2>
30
31	The low-level artifact format for ticket content is tedious and
32	cumbersome to access in realtime. To facility reporting and display
33	of tickets, the low-level artifact information is collected and
34	summarized in a pair of SQL tables in each local repository. Display
35	and reporting of tickets is accomplished by querying these two tables.
36
37	Note that only the low-level ticket change artifacts are synced. The
	@@ -132,12 +132,12 @@
132
133	Each row in the TICKETCHNG table corresponds to a single ticket change
134	artifact. The tkt_id field is the integer primary key of the TICKET
135	table entry for the corresponding ticket. The tkt_rid field is the
136	integer primary key for the BLOB table entry that contains the low-level
137	artifact text. The tkt_mtime field is the timestamp on the ticket
138	change artifact, expressed as a julian day number. If the ticket
139	change artifact contains a key/value pair where the key is "login",
140	then the corresponding value is stored in the login field of the
141	TICKETCHNG table. The same it true for "username", "mimetype", and
142	"icomment" fields. Any time there is a key/value pair in the ticket
143	change artifact and the key corresponds to the name of a field in the
	@@ -154,11 +154,11 @@
154	hexadecimal constant. The tkt_mtime and tkt_ctime fields hold the
155	times of the most recent and the oldest ticket change artifacts for
156	this ticket, respectively.
157
158	To reconstruct the TICKET table, the ticket change
159	artifacts are visited in timestamp order. As each ticket change artifact is
160	visited, its key/value pairs are examined. For any key/value pair in
161	which the key is the same as a field in the TICKET table, the value
162	of that pair either replaces or is appended to the previous value
163	of the corresponding field in the TICKET table. Whether a value is
164	replaced or appended is determined by markings in the ticket change
	@@ -194,6 +194,6 @@
194	The TICKETCHNG table was added to support new-style tickets. In the new
195	style, comment text is stored with the "icomment" (for "Incremental Comment")
196	key and appears separately, and with its on mimetype, in multiple rows
197	of the TICKETCHNG table. It then falls to the TH1 script code on the
198	View Ticket Page to query the TICKETCHNG table and extract and format
199	the various comments in timestamp order.
200

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -10,28 +10,28 @@
10
11	Each ticket change artifact contains the following information:
12
13	<ul>
14	<li>The ID of the ticket that was changed
15	<li>The time stamp for when the change occurred
16	<li>The user who made the change
17	<li>A list of key/value pairs that show what changed in the ticket
18	</ul>
19
20	To determine the current state of a particular ticket, Fossil orders
21	the change artifacts for that ticket from oldest to most recent,
22	then applies each change in time stamp order.
23
24	On each change artifact, there are one or more key/value pairs that
25	implement the change. The key corresponds to a field of the ticket
26	that is modified. The value may either replace the earlier value for
27	that key, or the value may be appended to the prior value.
28
29	<h2>2.0 Ticket Tables</h2>
30
31	The low-level artifact format for ticket content is tedious and
32	cumbersome to access in real time. To facility reporting and display
33	of tickets, the low-level artifact information is collected and
34	summarized in a pair of SQL tables in each local repository. Display
35	and reporting of tickets is accomplished by querying these two tables.
36
37	Note that only the low-level ticket change artifacts are synced. The
	@@ -132,12 +132,12 @@
132
133	Each row in the TICKETCHNG table corresponds to a single ticket change
134	artifact. The tkt_id field is the integer primary key of the TICKET
135	table entry for the corresponding ticket. The tkt_rid field is the
136	integer primary key for the BLOB table entry that contains the low-level
137	artifact text. The tkt_mtime field is the time stamp on the ticket
138	change artifact, expressed as a Julian day number. If the ticket
139	change artifact contains a key/value pair where the key is "login",
140	then the corresponding value is stored in the login field of the
141	TICKETCHNG table. The same it true for "username", "mimetype", and
142	"icomment" fields. Any time there is a key/value pair in the ticket
143	change artifact and the key corresponds to the name of a field in the
	@@ -154,11 +154,11 @@
154	hexadecimal constant. The tkt_mtime and tkt_ctime fields hold the
155	times of the most recent and the oldest ticket change artifacts for
156	this ticket, respectively.
157
158	To reconstruct the TICKET table, the ticket change
159	artifacts are visited in time stamp order. As each ticket change artifact is
160	visited, its key/value pairs are examined. For any key/value pair in
161	which the key is the same as a field in the TICKET table, the value
162	of that pair either replaces or is appended to the previous value
163	of the corresponding field in the TICKET table. Whether a value is
164	replaced or appended is determined by markings in the ticket change
	@@ -194,6 +194,6 @@
194	The TICKETCHNG table was added to support new-style tickets. In the new
195	style, comment text is stored with the "icomment" (for "Incremental Comment")
196	key and appears separately, and with its on mimetype, in multiple rows
197	of the TICKETCHNG table. It then falls to the TH1 script code on the
198	View Ticket Page to query the TICKETCHNG table and extract and format
199	the various comments in time stamp order.
200

M www/tls-nginx.md

+50 -242

		--- www/tls-nginx.md
		+++ www/tls-nginx.md
		@@ -3,183 +3,45 @@
3	3	One of the [many ways](./ssl.wiki) to provide TLS-encrypted HTTP access
4	4	(a.k.a. HTTPS) to Fossil is to run it behind a web proxy that supports
5	5	TLS. This document explains how to use the powerful [nginx web
6	6	server](http://nginx.org/) to do that.
7	7
8		-
9		-## Benefits
10		-
11		-This scheme is complicated, even with the benefit of this guide and
12		-pre-built binary packages. Why should you put up with this complexity?
13		-Because it gives many benefits that are difficult or impossible to get
14		-with the less complicated options:
15		-
16		-* Power — nginx is one of the most powerful web servers in the
17		- world. The chance that you will run into a web serving wall that you
18		- can’t scale with nginx is very low.
19		-
20		- To give you some idea of the sort of thing you can readily
21		- accomplish with nginx, your author runs a single public web server
22		- that provides transparent name-based virtual hosting for four
23		- separate domains:
24		-
25		- * One is entirely static, not involving any dynamic content or
26		- Fossil integration at all.
27		-
28		- * Another is served almost entirely by Fossil, with a few select
29		- static content exceptions punched past Fossil, which are handled
30		- entirely via nginx.
31		-
32		- * The other two domains are aliases for one another — e.g.
33		- `example.com` and `example.net` — with most of the content being
34		- static. This pair of domains has three different Fossil repo
35		- proxies attached to various sections of the URI hierarchy.
36		-
37		- All of this is done with minimal configuration repetition between
38		- the site configurations.
39		-
40		-* Integration — Because nginx is so popular, it integrates with
41		-many different technologies, and many other systems integrate with it in
42		-turn. This makes it great middleware, sitting between the outer web
43		-world and interior site services like Fossil. It allows Fossil to
44		-participate seamlessly as part of a larger web stack.
45		-
46		-* Availability — nginx is already in most operating system binary
47		-package repositories, so you don’t need to go out of your way to get it.
48		-
49		-
50		-## Fossil Remote Access Methods
51		-
52		-Fossil provides four major ways to access a repository it’s serving
53		-remotely, three of which are straightforward to use with nginx:
54		-
55		-* HTTP — Fossil has a built-in HTTP server: `fossil server`.
56		- While this method is efficient and it’s possible to use nginx to
57		- proxy access to another HTTP server, this option is overkill for our
58		- purposes. nginx is itself a fully featured HTTP server, so we will
59		- choose in this guide not to make nginx reinterpret Fossil’s
60		- implementation of HTTP.
61		-
62		-* CGI — This method is simple but inefficient, because it launches
63		- a separate Fossil instance on every HTTP hit.
64		-
65		- Since Fossil is a relatively small self-contained program, and it’s
66		- designed to start up quickly, this method can work well in a
67		- surprisingly large number of cases.
68		-
69		- Nevertheless, we will avoid this option in this document because
70		- we’re already buying into a certain amount of complexity here in
71		- order to gain power. There’s no sense in throwing away any of that
72		- hard-won performance on CGI overhead.
73		-
74		-* SCGI — The [SCGI protocol][scgi] provides the simplicity of CGI
75		- without its performance problems.
76		-
77		-* SSH — This method exists primarily to avoid the need for HTTPS
78		- in the first place. There is probably a way to get nginx to proxy
79		- Fossil to HTTPS via SSH, but it would be pointlessly complicated.
80		-
81		-SCGI it is, then.
82		-
83		-
84		-# Installing
85		-
86		-The first step is to install the pieces we’ll be working with. This
87		-varies on different operating systems, so to avoid overcomplicating this
88		-guide, we’re going to assume you’re using Ubuntu Server 18.04 LTS, a
89		-common Tier 1 offering for [virtual private servers][vps].
90		-
91		-SSH into your server, then say:
92		-
93		- $ sudo apt install certbot fossil nginx
94		-
95		-For other operating systems, simply visit [the front Certbot web
96		-page][cb] and tell it what OS and web stack you’re using. Chances are
97		-good that they’ve got a good guide for you already.
98		-
99		-
100		-# Running Fossil in SCGI Mode
101		-
102		-You presumably already have a working Fossil configuration on the public
103		-server you’re trying to set up and are just following this guide to
104		-replace HTTP service with HTTPS.
105		-
106		-(You can adjust the advice in this guide to get both HTTP and HTTPS
107		-service on the same site, but I strongly recommend that you do not do
108		-that: the good excuses remaining for continuing to allow HTTP on public
109		-web servers are running thin these days.)
110		-
111		-I run my Fossil SCGI server instances with a variant of [the `fslsrv`
112		-shell script](/file/tools/fslsrv) currently hosted in the Fossil source
113		-code repository. You’ll want to download that and make a copy of it, so
114		-you can customize it to your particular needs.
115		-
116		-This script allows running multiple Fossil SCGI servers, one per
117		-repository, each bound to a different high-numbered `localhost` port, so
118		-that only nginx can see and proxy them out to the public. The
119		-“`example`” repo is on TCP port localhost:12345, and the “`foo`” repo is
120		-on localhost:12346.
121		-
122		-As written, the `fslsrv` script expects repositories to be stored in the
123		-calling user’s home directory under `~/museum`, because where else do
124		-you keep Fossils?
125		-
126		-That home directory also needs to have a directory to hold log files,
127		-`~/log/fossil/*.log`. Fossil doesn’t put out much logging, but when it
128		-does, it’s better to have it captured than to need to re-create the
129		-problem after the fact.
130		-
131		-The use of `--baseurl` in this script lets us have each Fossil
132		-repository mounted in a different location in the URL scheme. Here, for
133		-example, we’re saying that the “`example`” repository is hosted under
134		-the `/code` URI on its domains, but that the “`foo`” repo is hosted at
135		-the top level of its domain. You’ll want to do something like the
136		-former for a Fossil repo that’s just one piece of a larger site, but the
137		-latter for a repo that is basically the whole point of the site.
138		-
139		-You might also want another script to automate the update, build, and
140		-deployment steps for new Fossil versions:
141		-
142		- #!/bin/sh
143		- cd $HOME/src/fossil/trunk
144		- fossil up
145		- make -j11
146		- killall fossil
147		- sudo make install
148		- fslsrv
149		-
150		-The `killall fossil` step is needed only on OSes that refuse to let you
151		-replace a running binary on disk.
152		-
153		-As written, the `fslsrv` script assumes a Linux environment. It expects
154		-`/bin/bash` to exist, and it depends on non-POSIX tools like `pgrep`.
155		-It should not be difficult to port to systems like macOS or the BSDs.
	8	+This document is an extension of the [Serving via nginx on Debian][nod]
	9	+document. Please read that first, then come back here to extend its
	10	+configuration with TLS.
	11	+
	12	+[nod]: ./server/debian/nginx.md
	13	+
	14	+
	15	+## Install Certbot
	16	+
	17	+The [nginx-on-Debian document][nod] had you install a few non-default
	18	+packages to the system, but there’s one more you need for this guide:
	19	+
	20	+ $ sudo apt install certbot
	21	+
	22	+You can extend this guide to other operating systems by following the
	23	+instructions found via [the front Certbot web page][cb] instead, telling
	24	+it what OS and web stack you’re using. Chances are good that they’ve got
	25	+a good guide for you already.
156	26
157	27
158	28	# Configuring Let’s Encrypt, the Easy Way
159	29
160	30	If your web serving needs are simple, [Certbot][cb] can configure nginx
161		-for you and keep its certificates up to date. You can follow the Certbot
162		-documentation for [nginx on Ubuntu 18.04 LTS guide][cbnu] as-is, though
163		-we’d recommend one small change: to use the version of Certbot in the
164		-Ubuntu package repository rather than the first-party Certbot package
165		-that the guide recommends.
166		-
167		-The primary local configuration you need is to tell nginx how to proxy
168		-certain URLs down to the Fossil instance you started above with the
169		-`fslsrv` script:
170		-
171		- location / {
172		- include scgi_params;
173		- scgi_pass 127.0.0.1:12345;
174		- scgi_param HTTPS "on";
175		- scgi_param SCRIPT_NAME "";
176		- }
177		-
178		-The TCP port number in that snippet is the key: it has to match the port
179		-number generated by `fslsrv` from the base port number passed to the
180		-`start_one` function.
	31	+for you and keep its certificates up to date. Simply follow Certbot’s
	32	+[nginx on Ubuntu 18.04 LTS guide][cbnu]. We’d recommend one small
	33	+change: to use the version of Certbot in the Ubuntu package repository
	34	+rather than download it from the Certbot site.
	35	+
	36	+You should be able to use the nginx configuration given in our [Serving
	37	+via nginx on Debian][nod] guide with little to no change. The main thing
	38	+to watch out for is that the TCP port number in the nginx configuration
	39	+needs to match the value you gave when starting Fossil. If you followed
	40	+that guide’s advice, it will be 9000. Another option is to use [the
	41	+`fslsrv` script](/file/tools/fslsrv), in which case the TCP port number
	42	+will be 12345 or higher.
181	43
182	44
183	45	# Configuring Let’s Encrypt, the Hard Way
184	46
185	47	If you’re finding that you can’t get certificates to be issued or
		@@ -193,11 +55,12 @@
193	55	Environment][acme] protocol (ACME) to determine whether a given client
194	56	actually has control over the domain(s) for which it wants a certificate
195	57	minted. Let’s Encrypt will not blithely let you mint certificates for
196	58	`google.com` and `paypal.com` just because you ask for it!
197	59
198		-Your author’s configuration, glossed above, is complicated enough that
	60	+Your author’s configuration, glossed [in the HTTP-only guide][nod],
	61	+is complicated enough that
199	62	the current version of Certbot (0.28 at the time of this writing) can’t
200	63	cope with it. That’s the primary motivation for me to write this guide:
201	64	I’m addressing the “me” years hence who needs to upgrade to Ubuntu 20.04
202	65	or 22.04 LTS and has forgotten all of this stuff. 😉
203	66
		@@ -216,24 +79,12 @@
216	79	entirely.
217	80
218	81
219	82	## Step 2: Configuring nginx
220	83
221		-On Ubuntu systems, at least, the primary user-level configuration file
222		-is `/etc/nginx/sites-enabled/default`. For a configuration like I
223		-described at the top of this article, I recommend that this file contain
224		-only a list of include statements, one for each site that server hosts:
225		-
226		- include local/example
227		- include local/foo
228		-
229		-Those files then each define one domain’s configuration. Here,
230		-`/etc/nginx/local/example` contains the configuration for
231		-`.example.com` and `.example.net`; and `local/foo` contains the
232		-configuration for `*.foo.net`.
233		-
234		-Here’s an example configuration:
	84	+This is a straightforward extension to [the HTTP-only
	85	+configuration](./server/debian/nginx.md#config):
235	86
236	87	server {
237	88	server_name .foo.net;
238	89
239	90	include local/tls-common;
		@@ -268,12 +119,13 @@
268	119	include local/http-certbot-only;
269	120	access_log /var/log/nginx/foo.net-http-access.log;
270	121	error_log /var/log/nginx/foo.net-http-error.log;
271	122	}
272	123
273		-Notice that we need two `server { }` blocks: one for HTTPS service, and
274		-one for HTTP-only service:
	124	+One big difference between this and the HTTP-only case is
	125	+that we need two `server { }` blocks: one for HTTPS service, and
	126	+one for HTTP-only service.
275	127
276	128
277	129	### HTTP over TLS (HTTPS) Service
278	130
279	131	The first `server { }` block includes this file, `local/tls-common`:
		@@ -385,43 +237,17 @@
385	237	# Force everything else to HTTPS with a permanent redirect.
386	238	#return 301 https://$host$request_uri;
387	239
388	240	As written above, this configuration does nothing other than to tell
389	241	nginx that it’s allowed to serve content via HTTP on port 80 as well.
390		-
391	242	We’ll uncomment the `rewrite` and `return` directives below, when we’re
392	243	ready to begin testing.
393	244
394		-
395		-#### Why the Repetition?
396		-
397		-These `server { }` blocks contain several directives that have to be
398		-either completely repeated or copied with only trivial changes when
399		-you’re hosting multiple domains from a single server.
400		-
401		-You might then wonder, why haven’t I factored some of those directives
402		-into the included files `local/tls-common` and
403		-`local/http-certbot-only`? Why can’t the HTTP-only `server { }` block
404		-above be just two lines? That is, why can I not say:
405		-
406		- server_name .foo.net;
407		- include local/http-certbot-only;
408		-
409		-Then in `local/http-certbot-only` say:
410		-
411		- root /var/www/$host;
412		- access_log /var/log/nginx/$host-http-access.log;
413		- error_log /var/log/nginx/$host-http-error.log;
414		-
415		-Sadly, nginx doesn’t allow variable substitution into these particular
416		-directives. As I understand it, allowing that would make nginx slower,
417		-so we must largely repeat these directives in each HTTP `server { }`
418		-block.
419		-
420		-These configurations are, as shown, as small as I know how to get them.
421		-If you know of a way to reduce some of this repetition, [I solicit your
422		-advice][fd].
	245	+Notice that this configuration is very different from that in the
	246	+[HTTP-only nginx on Debian][nod] guide. Most of that guide’s nginx
	247	+directives moved up into the TLS `server { }` block, because we
	248	+eventually want this site to be as close to HTTPS-only as we can get it.
423	249
424	250
425	251	## Step 3: Dry Run
426	252
427	253	We want to first request a dry run, because Let’s Encrypt puts some
		@@ -541,29 +367,19 @@
541	367	it would actually [cause an infinite redirect loop if
542	368	enabled](./ssl.wiki#rloop).
543	369
544	370
545	371
546		-## Step 6: Re-Sync Your Repositories
	372	+## Step 6: Re-Point Fossil at Your Repositories
547	373
548		-Now that the repositories hosted by this server are available via HTTPS,
549		-you need to tell Fossil about it:
	374	+As of Fossil 2.9, the permanent HTTP-to-HTTPS redirect we enabled above
	375	+causes Fossil to remember the new URL automatically the first time it’s
	376	+redirected to it. All you need to do to switch your syncs to HTTPS is:
550	377
551	378	$ cd ~/path/to/checkout
552		- $ fossil sync https://example.com/code
553		-
554		-Once that’s done per repository file, all checkouts of that repo will
555		-from that point on use the HTTPS URI to sync.
556		-
557		-You might wonder if that’s necessary, since we have the automatic
558		-HTTP-to-HTTPS redirect on this site now. If you clone or sync one of
559		-these nginx-hosted Fossil repositories over an untrustworthy network
560		-that allows [MITM attacks][mitm], that redirect won’t protect you from a
561		-sufficiently capable and motivated attacker unless you’ve also gone
562		-ahead and [enabled HSTS](#hsts). You can put off the need to enable
563		-HSTS by explicitly using HTTPS URIs.
564		-
	379	+ $ fossil sync
	380	+
565	381
566	382	## Step 7: Renewing Automatically
567	383
568	384	Now that the configuration is solid, you can renew the LE cert with the
569	385	`certbot` command from above without the `--dry-run` flag plus a restart
		@@ -588,27 +404,21 @@
588	404	-----------
589	405
590	406	<a id=”evolution”></a>
591	407	Document Evolution
592	408
593		-TLS and web proxying are a constantly evolving technology. This article
594		-replaces my [earlier effort][2016], which had whole sections that were
595		-basically obsolete within about a year of posting it. Two years on, and
596		-I was encouraging readers to ignore about half of that HOWTO. I am now
597		-writing this document about 3 years later because Let’s Encrypt
598		-deprecated key technology that HOWTO depended on, to the point that
599		-following that old HOWTO is more likely to confuse than enlighten.
	409	+Large parts of this article have been rewritten several times now due to
	410	+shifting technology in the TLS and proxying spheres.
600	411
601	412	There is no particularly good reason to expect that this sort of thing
602		-will not continue to happen, so this effort is expected to be a living
	413	+will not continue to happen, so we consider this to be a living
603	414	document. If you do not have commit access on the `fossil-scm.org`
604	415	repository to update this document as the world changes around it, you
605	416	can discuss this document [on the forum][fd]. This document’s author
606	417	keeps an eye on the forum and expects to keep this document updated with
607	418	ideas that appear in that thread.
608	419
609		-[2016]: https://www.mail-archive.com/[email protected]/msg22907.html
610	420	[acme]: https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment
611	421	[cb]: https://certbot.eff.org/
612	422	[cbnu]: https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx
613	423	[fd]: https://fossil-scm.org/forum/forumpost/ae6a4ee157
614	424	[hsts]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
		@@ -616,7 +426,5 @@
616	426	[mitm]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
617	427	[nest]: https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/
618	428	[ocsp]: https://en.wikipedia.org/wiki/OCSP_stapling
619	429	[qslc]: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
620	430	[qslt]: https://www.ssllabs.com/ssltest/
621		-[scgi]: https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
622		-[vps]: https://en.wikipedia.org/wiki/Virtual_private_server
623	431

	--- www/tls-nginx.md
	+++ www/tls-nginx.md
	@@ -3,183 +3,45 @@
3	One of the [many ways](./ssl.wiki) to provide TLS-encrypted HTTP access
4	(a.k.a. HTTPS) to Fossil is to run it behind a web proxy that supports
5	TLS. This document explains how to use the powerful [nginx web
6	server](http://nginx.org/) to do that.
7
8
9	## Benefits
10
11	This scheme is complicated, even with the benefit of this guide and
12	pre-built binary packages. Why should you put up with this complexity?
13	Because it gives many benefits that are difficult or impossible to get
14	with the less complicated options:
15
16	* Power — nginx is one of the most powerful web servers in the
17	world. The chance that you will run into a web serving wall that you
18	can’t scale with nginx is very low.
19
20	To give you some idea of the sort of thing you can readily
21	accomplish with nginx, your author runs a single public web server
22	that provides transparent name-based virtual hosting for four
23	separate domains:
24
25	* One is entirely static, not involving any dynamic content or
26	Fossil integration at all.
27
28	* Another is served almost entirely by Fossil, with a few select
29	static content exceptions punched past Fossil, which are handled
30	entirely via nginx.
31
32	* The other two domains are aliases for one another — e.g.
33	`example.com` and `example.net` — with most of the content being
34	static. This pair of domains has three different Fossil repo
35	proxies attached to various sections of the URI hierarchy.
36
37	All of this is done with minimal configuration repetition between
38	the site configurations.
39
40	* Integration — Because nginx is so popular, it integrates with
41	many different technologies, and many other systems integrate with it in
42	turn. This makes it great middleware, sitting between the outer web
43	world and interior site services like Fossil. It allows Fossil to
44	participate seamlessly as part of a larger web stack.
45
46	* Availability — nginx is already in most operating system binary
47	package repositories, so you don’t need to go out of your way to get it.
48
49
50	## Fossil Remote Access Methods
51
52	Fossil provides four major ways to access a repository it’s serving
53	remotely, three of which are straightforward to use with nginx:
54
55	* HTTP — Fossil has a built-in HTTP server: `fossil server`.
56	While this method is efficient and it’s possible to use nginx to
57	proxy access to another HTTP server, this option is overkill for our
58	purposes. nginx is itself a fully featured HTTP server, so we will
59	choose in this guide not to make nginx reinterpret Fossil’s
60	implementation of HTTP.
61
62	* CGI — This method is simple but inefficient, because it launches
63	a separate Fossil instance on every HTTP hit.
64
65	Since Fossil is a relatively small self-contained program, and it’s
66	designed to start up quickly, this method can work well in a
67	surprisingly large number of cases.
68
69	Nevertheless, we will avoid this option in this document because
70	we’re already buying into a certain amount of complexity here in
71	order to gain power. There’s no sense in throwing away any of that
72	hard-won performance on CGI overhead.
73
74	* SCGI — The [SCGI protocol][scgi] provides the simplicity of CGI
75	without its performance problems.
76
77	* SSH — This method exists primarily to avoid the need for HTTPS
78	in the first place. There is probably a way to get nginx to proxy
79	Fossil to HTTPS via SSH, but it would be pointlessly complicated.
80
81	SCGI it is, then.
82
83
84	# Installing
85
86	The first step is to install the pieces we’ll be working with. This
87	varies on different operating systems, so to avoid overcomplicating this
88	guide, we’re going to assume you’re using Ubuntu Server 18.04 LTS, a
89	common Tier 1 offering for [virtual private servers][vps].
90
91	SSH into your server, then say:
92
93	$ sudo apt install certbot fossil nginx
94
95	For other operating systems, simply visit [the front Certbot web
96	page][cb] and tell it what OS and web stack you’re using. Chances are
97	good that they’ve got a good guide for you already.
98
99
100	# Running Fossil in SCGI Mode
101
102	You presumably already have a working Fossil configuration on the public
103	server you’re trying to set up and are just following this guide to
104	replace HTTP service with HTTPS.
105
106	(You can adjust the advice in this guide to get both HTTP and HTTPS
107	service on the same site, but I strongly recommend that you do not do
108	that: the good excuses remaining for continuing to allow HTTP on public
109	web servers are running thin these days.)
110
111	I run my Fossil SCGI server instances with a variant of [the `fslsrv`
112	shell script](/file/tools/fslsrv) currently hosted in the Fossil source
113	code repository. You’ll want to download that and make a copy of it, so
114	you can customize it to your particular needs.
115
116	This script allows running multiple Fossil SCGI servers, one per
117	repository, each bound to a different high-numbered `localhost` port, so
118	that only nginx can see and proxy them out to the public. The
119	“`example`” repo is on TCP port localhost:12345, and the “`foo`” repo is
120	on localhost:12346.
121
122	As written, the `fslsrv` script expects repositories to be stored in the
123	calling user’s home directory under `~/museum`, because where else do
124	you keep Fossils?
125
126	That home directory also needs to have a directory to hold log files,
127	`~/log/fossil/*.log`. Fossil doesn’t put out much logging, but when it
128	does, it’s better to have it captured than to need to re-create the
129	problem after the fact.
130
131	The use of `--baseurl` in this script lets us have each Fossil
132	repository mounted in a different location in the URL scheme. Here, for
133	example, we’re saying that the “`example`” repository is hosted under
134	the `/code` URI on its domains, but that the “`foo`” repo is hosted at
135	the top level of its domain. You’ll want to do something like the
136	former for a Fossil repo that’s just one piece of a larger site, but the
137	latter for a repo that is basically the whole point of the site.
138
139	You might also want another script to automate the update, build, and
140	deployment steps for new Fossil versions:
141
142	#!/bin/sh
143	cd $HOME/src/fossil/trunk
144	fossil up
145	make -j11
146	killall fossil
147	sudo make install
148	fslsrv
149
150	The `killall fossil` step is needed only on OSes that refuse to let you
151	replace a running binary on disk.
152
153	As written, the `fslsrv` script assumes a Linux environment. It expects
154	`/bin/bash` to exist, and it depends on non-POSIX tools like `pgrep`.
155	It should not be difficult to port to systems like macOS or the BSDs.
156
157
158	# Configuring Let’s Encrypt, the Easy Way
159
160	If your web serving needs are simple, [Certbot][cb] can configure nginx
161	for you and keep its certificates up to date. You can follow the Certbot
162	documentation for [nginx on Ubuntu 18.04 LTS guide][cbnu] as-is, though
163	we’d recommend one small change: to use the version of Certbot in the
164	Ubuntu package repository rather than the first-party Certbot package
165	that the guide recommends.
166
167	The primary local configuration you need is to tell nginx how to proxy
168	certain URLs down to the Fossil instance you started above with the
169	`fslsrv` script:
170
171	location / {
172	include scgi_params;
173	scgi_pass 127.0.0.1:12345;
174	scgi_param HTTPS "on";
175	scgi_param SCRIPT_NAME "";
176	}
177
178	The TCP port number in that snippet is the key: it has to match the port
179	number generated by `fslsrv` from the base port number passed to the
180	`start_one` function.
181
182
183	# Configuring Let’s Encrypt, the Hard Way
184
185	If you’re finding that you can’t get certificates to be issued or
	@@ -193,11 +55,12 @@
193	Environment][acme] protocol (ACME) to determine whether a given client
194	actually has control over the domain(s) for which it wants a certificate
195	minted. Let’s Encrypt will not blithely let you mint certificates for
196	`google.com` and `paypal.com` just because you ask for it!
197
198	Your author’s configuration, glossed above, is complicated enough that

199	the current version of Certbot (0.28 at the time of this writing) can’t
200	cope with it. That’s the primary motivation for me to write this guide:
201	I’m addressing the “me” years hence who needs to upgrade to Ubuntu 20.04
202	or 22.04 LTS and has forgotten all of this stuff. 😉
203
	@@ -216,24 +79,12 @@
216	entirely.
217
218
219	## Step 2: Configuring nginx
220
221	On Ubuntu systems, at least, the primary user-level configuration file
222	is `/etc/nginx/sites-enabled/default`. For a configuration like I
223	described at the top of this article, I recommend that this file contain
224	only a list of include statements, one for each site that server hosts:
225
226	include local/example
227	include local/foo
228
229	Those files then each define one domain’s configuration. Here,
230	`/etc/nginx/local/example` contains the configuration for
231	`.example.com` and `.example.net`; and `local/foo` contains the
232	configuration for `*.foo.net`.
233
234	Here’s an example configuration:
235
236	server {
237	server_name .foo.net;
238
239	include local/tls-common;
	@@ -268,12 +119,13 @@
268	include local/http-certbot-only;
269	access_log /var/log/nginx/foo.net-http-access.log;
270	error_log /var/log/nginx/foo.net-http-error.log;
271	}
272
273	Notice that we need two `server { }` blocks: one for HTTPS service, and
274	one for HTTP-only service:

275
276
277	### HTTP over TLS (HTTPS) Service
278
279	The first `server { }` block includes this file, `local/tls-common`:
	@@ -385,43 +237,17 @@
385	# Force everything else to HTTPS with a permanent redirect.
386	#return 301 https://$host$request_uri;
387
388	As written above, this configuration does nothing other than to tell
389	nginx that it’s allowed to serve content via HTTP on port 80 as well.
390
391	We’ll uncomment the `rewrite` and `return` directives below, when we’re
392	ready to begin testing.
393
394
395	#### Why the Repetition?
396
397	These `server { }` blocks contain several directives that have to be
398	either completely repeated or copied with only trivial changes when
399	you’re hosting multiple domains from a single server.
400
401	You might then wonder, why haven’t I factored some of those directives
402	into the included files `local/tls-common` and
403	`local/http-certbot-only`? Why can’t the HTTP-only `server { }` block
404	above be just two lines? That is, why can I not say:
405
406	server_name .foo.net;
407	include local/http-certbot-only;
408
409	Then in `local/http-certbot-only` say:
410
411	root /var/www/$host;
412	access_log /var/log/nginx/$host-http-access.log;
413	error_log /var/log/nginx/$host-http-error.log;
414
415	Sadly, nginx doesn’t allow variable substitution into these particular
416	directives. As I understand it, allowing that would make nginx slower,
417	so we must largely repeat these directives in each HTTP `server { }`
418	block.
419
420	These configurations are, as shown, as small as I know how to get them.
421	If you know of a way to reduce some of this repetition, [I solicit your
422	advice][fd].
423
424
425	## Step 3: Dry Run
426
427	We want to first request a dry run, because Let’s Encrypt puts some
	@@ -541,29 +367,19 @@
541	it would actually [cause an infinite redirect loop if
542	enabled](./ssl.wiki#rloop).
543
544
545
546	## Step 6: Re-Sync Your Repositories
547
548	Now that the repositories hosted by this server are available via HTTPS,
549	you need to tell Fossil about it:

550
551	$ cd ~/path/to/checkout
552	$ fossil sync https://example.com/code
553
554	Once that’s done per repository file, all checkouts of that repo will
555	from that point on use the HTTPS URI to sync.
556
557	You might wonder if that’s necessary, since we have the automatic
558	HTTP-to-HTTPS redirect on this site now. If you clone or sync one of
559	these nginx-hosted Fossil repositories over an untrustworthy network
560	that allows [MITM attacks][mitm], that redirect won’t protect you from a
561	sufficiently capable and motivated attacker unless you’ve also gone
562	ahead and [enabled HSTS](#hsts). You can put off the need to enable
563	HSTS by explicitly using HTTPS URIs.
564
565
566	## Step 7: Renewing Automatically
567
568	Now that the configuration is solid, you can renew the LE cert with the
569	`certbot` command from above without the `--dry-run` flag plus a restart
	@@ -588,27 +404,21 @@
588	-----------
589
590	<a id=”evolution”></a>
591	Document Evolution
592
593	TLS and web proxying are a constantly evolving technology. This article
594	replaces my [earlier effort][2016], which had whole sections that were
595	basically obsolete within about a year of posting it. Two years on, and
596	I was encouraging readers to ignore about half of that HOWTO. I am now
597	writing this document about 3 years later because Let’s Encrypt
598	deprecated key technology that HOWTO depended on, to the point that
599	following that old HOWTO is more likely to confuse than enlighten.
600
601	There is no particularly good reason to expect that this sort of thing
602	will not continue to happen, so this effort is expected to be a living
603	document. If you do not have commit access on the `fossil-scm.org`
604	repository to update this document as the world changes around it, you
605	can discuss this document [on the forum][fd]. This document’s author
606	keeps an eye on the forum and expects to keep this document updated with
607	ideas that appear in that thread.
608
609	[2016]: https://www.mail-archive.com/[email protected]/msg22907.html
610	[acme]: https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment
611	[cb]: https://certbot.eff.org/
612	[cbnu]: https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx
613	[fd]: https://fossil-scm.org/forum/forumpost/ae6a4ee157
614	[hsts]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
	@@ -616,7 +426,5 @@
616	[mitm]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
617	[nest]: https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/
618	[ocsp]: https://en.wikipedia.org/wiki/OCSP_stapling
619	[qslc]: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
620	[qslt]: https://www.ssllabs.com/ssltest/
621	[scgi]: https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
622	[vps]: https://en.wikipedia.org/wiki/Virtual_private_server
623

	--- www/tls-nginx.md
	+++ www/tls-nginx.md
	@@ -3,183 +3,45 @@
3	One of the [many ways](./ssl.wiki) to provide TLS-encrypted HTTP access
4	(a.k.a. HTTPS) to Fossil is to run it behind a web proxy that supports
5	TLS. This document explains how to use the powerful [nginx web
6	server](http://nginx.org/) to do that.
7
8	This document is an extension of the [Serving via nginx on Debian][nod]
9	document. Please read that first, then come back here to extend its
10	configuration with TLS.
11
12	[nod]: ./server/debian/nginx.md
13
14
15	## Install Certbot
16
17	The [nginx-on-Debian document][nod] had you install a few non-default
18	packages to the system, but there’s one more you need for this guide:
19
20	$ sudo apt install certbot
21
22	You can extend this guide to other operating systems by following the
23	instructions found via [the front Certbot web page][cb] instead, telling
24	it what OS and web stack you’re using. Chances are good that they’ve got
25	a good guide for you already.


































































































































26
27
28	# Configuring Let’s Encrypt, the Easy Way
29
30	If your web serving needs are simple, [Certbot][cb] can configure nginx
31	for you and keep its certificates up to date. Simply follow Certbot’s
32	[nginx on Ubuntu 18.04 LTS guide][cbnu]. We’d recommend one small
33	change: to use the version of Certbot in the Ubuntu package repository
34	rather than download it from the Certbot site.
35
36	You should be able to use the nginx configuration given in our [Serving
37	via nginx on Debian][nod] guide with little to no change. The main thing
38	to watch out for is that the TCP port number in the nginx configuration
39	needs to match the value you gave when starting Fossil. If you followed
40	that guide’s advice, it will be 9000. Another option is to use [the
41	`fslsrv` script](/file/tools/fslsrv), in which case the TCP port number
42	will be 12345 or higher.








43
44
45	# Configuring Let’s Encrypt, the Hard Way
46
47	If you’re finding that you can’t get certificates to be issued or
	@@ -193,11 +55,12 @@
55	Environment][acme] protocol (ACME) to determine whether a given client
56	actually has control over the domain(s) for which it wants a certificate
57	minted. Let’s Encrypt will not blithely let you mint certificates for
58	`google.com` and `paypal.com` just because you ask for it!
59
60	Your author’s configuration, glossed [in the HTTP-only guide][nod],
61	is complicated enough that
62	the current version of Certbot (0.28 at the time of this writing) can’t
63	cope with it. That’s the primary motivation for me to write this guide:
64	I’m addressing the “me” years hence who needs to upgrade to Ubuntu 20.04
65	or 22.04 LTS and has forgotten all of this stuff. 😉
66
	@@ -216,24 +79,12 @@
79	entirely.
80
81
82	## Step 2: Configuring nginx
83
84	This is a straightforward extension to [the HTTP-only
85	configuration](./server/debian/nginx.md#config):












86
87	server {
88	server_name .foo.net;
89
90	include local/tls-common;
	@@ -268,12 +119,13 @@
119	include local/http-certbot-only;
120	access_log /var/log/nginx/foo.net-http-access.log;
121	error_log /var/log/nginx/foo.net-http-error.log;
122	}
123
124	One big difference between this and the HTTP-only case is
125	that we need two `server { }` blocks: one for HTTPS service, and
126	one for HTTP-only service.
127
128
129	### HTTP over TLS (HTTPS) Service
130
131	The first `server { }` block includes this file, `local/tls-common`:
	@@ -385,43 +237,17 @@
237	# Force everything else to HTTPS with a permanent redirect.
238	#return 301 https://$host$request_uri;
239
240	As written above, this configuration does nothing other than to tell
241	nginx that it’s allowed to serve content via HTTP on port 80 as well.

242	We’ll uncomment the `rewrite` and `return` directives below, when we’re
243	ready to begin testing.
244
245	Notice that this configuration is very different from that in the
246	[HTTP-only nginx on Debian][nod] guide. Most of that guide’s nginx
247	directives moved up into the TLS `server { }` block, because we
248	eventually want this site to be as close to HTTPS-only as we can get it.

























249
250
251	## Step 3: Dry Run
252
253	We want to first request a dry run, because Let’s Encrypt puts some
	@@ -541,29 +367,19 @@
367	it would actually [cause an infinite redirect loop if
368	enabled](./ssl.wiki#rloop).
369
370
371
372	## Step 6: Re-Point Fossil at Your Repositories
373
374	As of Fossil 2.9, the permanent HTTP-to-HTTPS redirect we enabled above
375	causes Fossil to remember the new URL automatically the first time it’s
376	redirected to it. All you need to do to switch your syncs to HTTPS is:
377
378	$ cd ~/path/to/checkout
379	$ fossil sync
380











381
382	## Step 7: Renewing Automatically
383
384	Now that the configuration is solid, you can renew the LE cert with the
385	`certbot` command from above without the `--dry-run` flag plus a restart
	@@ -588,27 +404,21 @@
404	-----------
405
406	<a id=”evolution”></a>
407	Document Evolution
408
409	Large parts of this article have been rewritten several times now due to
410	shifting technology in the TLS and proxying spheres.





411
412	There is no particularly good reason to expect that this sort of thing
413	will not continue to happen, so we consider this to be a living
414	document. If you do not have commit access on the `fossil-scm.org`
415	repository to update this document as the world changes around it, you
416	can discuss this document [on the forum][fd]. This document’s author
417	keeps an eye on the forum and expects to keep this document updated with
418	ideas that appear in that thread.
419

420	[acme]: https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment
421	[cb]: https://certbot.eff.org/
422	[cbnu]: https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx
423	[fd]: https://fossil-scm.org/forum/forumpost/ae6a4ee157
424	[hsts]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
	@@ -616,7 +426,5 @@
426	[mitm]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
427	[nest]: https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/
428	[ocsp]: https://en.wikipedia.org/wiki/OCSP_stapling
429	[qslc]: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
430	[qslt]: https://www.ssllabs.com/ssltest/


431

M www/webui.wiki

+2 -2

		--- www/webui.wiki
		+++ www/webui.wiki
		@@ -52,11 +52,11 @@
52	52	repository, simply type this:
53	53
54	54	<b>fossil ui existing-repository.fossil</b>
55	55
56	56	Substitute the name of your repository, of course.
57		-The "ui" command will start a webserver running (it figures out an
	57	+The "ui" command will start a web server running (it figures out an
58	58	available TCP port to use on its own) and then automatically launches
59	59	your web browser to point at that server. If you run the "ui" command
60	60	from within an open check-out, you can omit the repository name:
61	61
62	62	<b>fossil ui</b>
		@@ -108,11 +108,11 @@
108	108
109	109	You can view summary reports of <b>branches</b> in the
110	110	check-in graph by visiting the "Branches" link on the
111	111	menu bar. From those pages you can follow hyperlinks to get additional
112	112	details. These screens allow you to easily keep track of what is going
113		-on with separate subteams within your project team.
	113	+on with separate sub-teams within your project team.
114	114
115	115	The "Files" link on the menu allows you to browse through the <b>file
116	116	hierarchy</b> of the project and to view complete changes histories on
117	117	individual files, with hyperlinks to the check-ins that made those
118	118	changes, and with diffs and annotated diffs between versions.
119	119

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -52,11 +52,11 @@
52	repository, simply type this:
53
54	<b>fossil ui existing-repository.fossil</b>
55
56	Substitute the name of your repository, of course.
57	The "ui" command will start a webserver running (it figures out an
58	available TCP port to use on its own) and then automatically launches
59	your web browser to point at that server. If you run the "ui" command
60	from within an open check-out, you can omit the repository name:
61
62	<b>fossil ui</b>
	@@ -108,11 +108,11 @@
108
109	You can view summary reports of <b>branches</b> in the
110	check-in graph by visiting the "Branches" link on the
111	menu bar. From those pages you can follow hyperlinks to get additional
112	details. These screens allow you to easily keep track of what is going
113	on with separate subteams within your project team.
114
115	The "Files" link on the menu allows you to browse through the <b>file
116	hierarchy</b> of the project and to view complete changes histories on
117	individual files, with hyperlinks to the check-ins that made those
118	changes, and with diffs and annotated diffs between versions.
119

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -52,11 +52,11 @@
52	repository, simply type this:
53
54	<b>fossil ui existing-repository.fossil</b>
55
56	Substitute the name of your repository, of course.
57	The "ui" command will start a web server running (it figures out an
58	available TCP port to use on its own) and then automatically launches
59	your web browser to point at that server. If you run the "ui" command
60	from within an open check-out, you can omit the repository name:
61
62	<b>fossil ui</b>
	@@ -108,11 +108,11 @@
108
109	You can view summary reports of <b>branches</b> in the
110	check-in graph by visiting the "Branches" link on the
111	menu bar. From those pages you can follow hyperlinks to get additional
112	details. These screens allow you to easily keep track of what is going
113	on with separate sub-teams within your project team.
114
115	The "Files" link on the menu allows you to browse through the <b>file
116	hierarchy</b> of the project and to view complete changes histories on
117	individual files, with hyperlinks to the check-ins that made those
118	changes, and with diffs and annotated diffs between versions.
119

M www/wikitheory.wiki

+1 -1

		--- www/wikitheory.wiki
		+++ www/wikitheory.wiki
		@@ -27,11 +27,11 @@
27	27	Each wiki page has its own revision history which is independent of
28	28	the sequence of check-ins (check-ins). Wiki pages can branch and merge
29	29	just like check-ins, though as of this writing (2008-07-29) there is
30	30	no mechanism in the user interface to support branching and merging.
31	31	The current implementation of the wiki shows the version of the wiki
32		-page that has the most recent timestamp.
	32	+page that has the most recent time stamp.
33	33
34	34	In other words, if two users make unrelated changes to the same wiki
35	35	page on separate repositories and those repositories are synced,
36	36	the wiki page will fork. The web interface will display whichever edit
37	37	was checked in last. The other edit can be found in the history. The
38	38

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -27,11 +27,11 @@
27	Each wiki page has its own revision history which is independent of
28	the sequence of check-ins (check-ins). Wiki pages can branch and merge
29	just like check-ins, though as of this writing (2008-07-29) there is
30	no mechanism in the user interface to support branching and merging.
31	The current implementation of the wiki shows the version of the wiki
32	page that has the most recent timestamp.
33
34	In other words, if two users make unrelated changes to the same wiki
35	page on separate repositories and those repositories are synced,
36	the wiki page will fork. The web interface will display whichever edit
37	was checked in last. The other edit can be found in the history. The
38

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -27,11 +27,11 @@
27	Each wiki page has its own revision history which is independent of
28	the sequence of check-ins (check-ins). Wiki pages can branch and merge
29	just like check-ins, though as of this writing (2008-07-29) there is
30	no mechanism in the user interface to support branching and merging.
31	The current implementation of the wiki shows the version of the wiki
32	page that has the most recent time stamp.
33
34	In other words, if two users make unrelated changes to the same wiki
35	page on separate repositories and those repositories are synced,
36	the wiki page will fork. The web interface will display whichever edit
37	was checked in last. The other edit can be found in the history. The
38

Fossil SCM

Keyboard Shortcuts