Fossil SCM
Added a bit more advice about caching to previous, and fixed a whitespace problem.
Commit
4d5a647735cb5d8ca09c96288c439f0d298ebc2e1d2a903551c24621e824c04d
Parent
1d0d69866dda0c1…
1 file changed
+7
-4
+7
-4
| --- www/server/debian/nginx.md | ||
| +++ www/server/debian/nginx.md | ||
| @@ -189,13 +189,13 @@ | ||
| 189 | 189 | configuration for SCGI][scgii], showing off a few ideas you might want to |
| 190 | 190 | try on your own site, such as static asset proxying. |
| 191 | 191 | |
| 192 | 192 | You also need a `local/code` file containing: |
| 193 | 193 | |
| 194 | - include scgi_params; | |
| 195 | - scgi_pass 127.0.0.1:12345; | |
| 196 | - scgi_param SCRIPT_NAME "/code"; | |
| 194 | + include scgi_params; | |
| 195 | + scgi_pass 127.0.0.1:12345; | |
| 196 | + scgi_param SCRIPT_NAME "/code"; | |
| 197 | 197 | |
| 198 | 198 | We separate that out because nginx refuses to inherit certain settings |
| 199 | 199 | between nested location blocks, so rather than repeat them, we extract |
| 200 | 200 | them to this separate file and include it from both locations where it’s |
| 201 | 201 | needed. You see this above where we set far-future expiration dates on |
| @@ -204,11 +204,14 @@ | ||
| 204 | 204 | can never change without the URL itself changing, which makes your |
| 205 | 205 | Fossil-based site considerably faster.(^Beware: If you use logical |
| 206 | 206 | versions in URLs like `/file/trunk/path/name/…` the rule above will |
| 207 | 207 | apply to them, too, requiring your users to toss the cache before |
| 208 | 208 | they’ll see updates to the referenced content. Trading off caching |
| 209 | -versus the possibility of stale data is a delicate dance.) | |
| 209 | +versus the possibility of stale data is a delicate dance. You can make | |
| 210 | +this arbitrarily complex. You might give a cache time of a day or a week | |
| 211 | +for URLs more likely to change and reserve the really-long times for | |
| 212 | +those impossible to change without changing the URL.) | |
| 210 | 213 | |
| 211 | 214 | Similarly, the `local/generic` file referenced above helps us reduce unnecessary |
| 212 | 215 | repetition among the multiple sites this configuration hosts: |
| 213 | 216 | |
| 214 | 217 | root /var/www/$host; |
| 215 | 218 |
| --- www/server/debian/nginx.md | |
| +++ www/server/debian/nginx.md | |
| @@ -189,13 +189,13 @@ | |
| 189 | configuration for SCGI][scgii], showing off a few ideas you might want to |
| 190 | try on your own site, such as static asset proxying. |
| 191 | |
| 192 | You also need a `local/code` file containing: |
| 193 | |
| 194 | include scgi_params; |
| 195 | scgi_pass 127.0.0.1:12345; |
| 196 | scgi_param SCRIPT_NAME "/code"; |
| 197 | |
| 198 | We separate that out because nginx refuses to inherit certain settings |
| 199 | between nested location blocks, so rather than repeat them, we extract |
| 200 | them to this separate file and include it from both locations where it’s |
| 201 | needed. You see this above where we set far-future expiration dates on |
| @@ -204,11 +204,14 @@ | |
| 204 | can never change without the URL itself changing, which makes your |
| 205 | Fossil-based site considerably faster.(^Beware: If you use logical |
| 206 | versions in URLs like `/file/trunk/path/name/…` the rule above will |
| 207 | apply to them, too, requiring your users to toss the cache before |
| 208 | they’ll see updates to the referenced content. Trading off caching |
| 209 | versus the possibility of stale data is a delicate dance.) |
| 210 | |
| 211 | Similarly, the `local/generic` file referenced above helps us reduce unnecessary |
| 212 | repetition among the multiple sites this configuration hosts: |
| 213 | |
| 214 | root /var/www/$host; |
| 215 |
| --- www/server/debian/nginx.md | |
| +++ www/server/debian/nginx.md | |
| @@ -189,13 +189,13 @@ | |
| 189 | configuration for SCGI][scgii], showing off a few ideas you might want to |
| 190 | try on your own site, such as static asset proxying. |
| 191 | |
| 192 | You also need a `local/code` file containing: |
| 193 | |
| 194 | include scgi_params; |
| 195 | scgi_pass 127.0.0.1:12345; |
| 196 | scgi_param SCRIPT_NAME "/code"; |
| 197 | |
| 198 | We separate that out because nginx refuses to inherit certain settings |
| 199 | between nested location blocks, so rather than repeat them, we extract |
| 200 | them to this separate file and include it from both locations where it’s |
| 201 | needed. You see this above where we set far-future expiration dates on |
| @@ -204,11 +204,14 @@ | |
| 204 | can never change without the URL itself changing, which makes your |
| 205 | Fossil-based site considerably faster.(^Beware: If you use logical |
| 206 | versions in URLs like `/file/trunk/path/name/…` the rule above will |
| 207 | apply to them, too, requiring your users to toss the cache before |
| 208 | they’ll see updates to the referenced content. Trading off caching |
| 209 | versus the possibility of stale data is a delicate dance. You can make |
| 210 | this arbitrarily complex. You might give a cache time of a day or a week |
| 211 | for URLs more likely to change and reserve the really-long times for |
| 212 | those impossible to change without changing the URL.) |
| 213 | |
| 214 | Similarly, the `local/generic` file referenced above helps us reduce unnecessary |
| 215 | repetition among the multiple sites this configuration hosts: |
| 216 | |
| 217 | root /var/www/$host; |
| 218 |