docs: add contributing, code of conduct and code guidelines pages [skip ci] (#497)

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,5 @@
 <!--- Provide a general summary of your changes in the Title above -->
+<!--- Read the docs/PULL_REQUESTS.md -->
 
 ## Description
 <!--- Describe your changes but try to be as concise as possible -->

CONTRIBUTING.md

@@ -0,0 +1,33 @@
+# Contributing to The Static Web Server project
+
+Looking to contribute? You’re welcome!
+
+## [Code of Conduct](./docs/CODE_OF_CONDUCT.md)
+
+First, **all** project interactions must follow [the code of conduct](./docs/CODE_OF_CONDUCT.md) to ensure everyone is treated with respect.
+
+## [Issues](https://github.com/static-web-server/static-web-server/issues/new/choose)
+
+- Filing an issue is a valuable contribution. Reporting bugs and providing details helps us improve SWS and stay informed about issues we might not have noticed otherwise.
+- [Security issues](./SECURITY.md) has some consideration to take into your account first.
+
+## [Pull Requests](./docs/PULL_REQUESTS.md)
+
+Consider checking the [list of issues](https://github.com/static-web-server/static-web-server/issues) if you want to submit something.
+
+- [Submitting a Pull Request](./docs/PULL_REQUESTS.md#submitting-a-pull-request)
+- [Commit Guidelines](./docs/COMMITS.md)
+
+## Documentation
+
+Improving SWS documentation greatly helps everyone trying to use it.
+
+- The main website documentation is hosted in the repository and can be improved by following [the documentation instructions](https://static-web-server.net/building-from-source/#building-documentation-from-source).
+- The API documentation (rendered at [docs.rs/static-web-server](https://docs.rs/static-web-serve)) is stored as rustdoc comments directly in the source.
+
+## Help
+
+Helping others integrate SWS into their workflows is a valuable way to contribute:
+
+- Answer questions in SWS's Discussions or on our Discord.
+- Write blog posts about using SWS, contributing features, or debugging issues. Your posts add unique insights and examples that may not fit in the SWS repo, helping more users find solutions and explore new use cases.

docs/CODE_OF_CONDUCT.md

@@ -0,0 +1,21 @@
+# Code of Conduct
+
+## Be Kind
+
+- Don't be mean.
+- Insulting anyone is prohibited.
+- Harassment of any kind is prohibited.
+- If another person feels uncomfortable with your remarks, stop it.
+- If a moderator deems your comment or conduct as inappropriate, stop it.
+- Disagreeing is fine, but keep it to technical arguments. Never attack the person.
+- Give the benefit of the doubt. Assume good intentions.
+- Show empathy. There are 3 interpretations to any message: what we thought, what we said, and what they understand.
+- This does mean we exclude people who are not kind. We are happy to make that sacrifice.
+
+## Or Else
+
+- Violations of the Code of Conduct will result in 1 warning.
+- If the violation is major, a moderator may just ban immediately.
+- If a warning has already been given, a moderator will ban the offender.
+- There is no process for appealing a ban.
+- Any violations can be reported to to the principal maintainer ([@joseluisq](https://github.com/joseluisq)) on either [Keybase](https://keybase.io/joseluisq) (preferred) or [Discord Server](https://discord.gg/VWvtZeWAA7).

docs/CODE_STYLE.md

@@ -0,0 +1,26 @@
+# Code Style
+
+SWS uses the default configuration of `rustfmt`.
+
+## cargo fmt
+
+`cargo fmt --all` does not work in SWS. Please use the following commands:
+
+### Linux/BSDs
+
+```sh
+rustfmt --check --edition 2021 $(git ls-files '*.rs')
+```
+
+### Windows
+
+```powershell
+Get-ChildItem . -Filter "*.rs" -Recurse | foreach { rustfmt --check --edition 2021 $_.FullName }
+```
+
+> **NOTE**: If you are using `rust-analyzer`, you can add the following two lines in your `settings.json` to make sure the features get taken into account when checking the project:
+>
+>    ```json
+>     "rust-analyzer.cargo.features": ["full"],
+>     "rust-analyzer.check.features": ["full"],
+>    ```

docs/COMMITS.md

@@ -0,0 +1,74 @@
+# Git Commit Guidelines
+
+We have very precise rules over how our git commit messages can be formatted.
+This leads to **more readable messages** that are easy to follow when looking through the **project history**.
+But also, we use the git commit messages to **generate the change log**.
+
+## Commit Message Format
+Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
+format that includes a **type**, a **scope** and a **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
+to read on github as well as in various git tools.
+
+## Type
+Must be one of the following:
+
+* **feat**: A new feature
+* **fix**: A bug fix
+* **docs**: Documentation only changes
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
+  semi-colons, etc)
+* **refactor**: A code change that neither fixes a bug or adds a feature
+* **perf**: A code change that improves performance
+* **test**: Adding missing tests
+* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
+    generation
+
+## Scope
+The scope should refer to a **module** in SWS that is being touched. Some examples:
+
+* server
+* http1
+* http2
+* tls
+* compression
+* fs
+* logger
+* rewrites
+* redirects
+* signals
+* winservice
+* handler
+* response
+* service
+* directory_listing
+* cors
+
+## Subject
+
+The subject contains succinct description of the change:
+
+* use the imperative, present tense: "change" not "changed" nor "changes"
+* don't capitalize first letter
+* no dot (.) at the end
+
+## Body
+
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
+The body should include the motivation for the change and contrast this with previous behavior.
+
+## Footer
+
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`

docs/PULL_REQUESTS.md

@@ -0,0 +1,49 @@
+# Pull Requests
+
+Pull requests are the way to submit changes to the SWS repository.
+
+## Submitting a Pull Request
+
+In most cases, it a good idea to discuss a potential change in an
+[issue](https://github.com/static-web-server/static-web-server/issues). This will allow other contributors to provide guidance and
+feedback _before_ significant code work is done, and can increase the
+likelihood of getting the pull request merged.
+
+### Tests
+
+If the change being proposed alters code (as opposed to only documentation for
+example), it is either adding new functionality to SWS or it is fixing
+existing, broken functionality. In both of these cases, the pull request should
+include one or more tests to ensure that SWS does not regress in the future.
+
+### Commits
+
+Once code, tests, and documentation have been written, a commit needs to be
+made. Following the [commit guidelines](./COMMITS.md) will help with the review
+process by making your change easier to understand, and makes it easier for
+SWS to produce a valuable changelog with each release.
+
+However, if your message doesn't perfectly match the guidelines, **do not worry!**,
+the person that eventually merges can easily fixup the message at that
+time.
+
+### Opening the Pull Request
+
+From within GitHub, open a new pull request from your personal branch.
+
+Once opened, pull requests are usually reviewed within a few days.
+
+### Discuss and Update
+
+You will probably get feedback or requests for changes to your Pull Request.
+This is a big part of the submission process so don't be discouraged! Some
+contributors may sign off on the Pull Request right away, others may have more
+detailed comments or feedback. This is a necessary part of the process in order
+to evaluate whether the changes are correct and necessary.
+
+Any community member can review a PR and you might get conflicting feedback.
+Keep an eye out for comments from code owners to provide guidance on
+conflicting feedback.
+
+You don't need to close the PR and create a new one to address feedback. You
+may simply push new commits to the existing branch.

docs/man/static-web-server.1.rst

@@ -1,121 +0,0 @@
-static-web-server(1)
-====================
-
-Name
-----
-
-static-web-server - About A cross-platform, high-performance and asynchronous web server for static files-serving.
-
-SYNOPSIS
---------
-
-*static-web-server* [OPTIONS]
-
-*static-web-server* [_OPTIONS_] *--help*
-
-*static-web-server* [_OPTIONS_] *--version*
-
-FLAGS
------
-
--h, --help::
-        Prints help information
--V, --version::
-        Prints version information
-
-OPTIONS
--------
-
---basic-auth <basic-auth>::
-It provides The "Basic" HTTP Authentication scheme using credentials as "user-id:password" pairs. Password must be encoded using the "BCrypt" password-hashing function [env: SERVER_BASIC_AUTH=]  [default: ]
-
--e, --cache-control-headers <cache-control-headers>::
-Enable cache control headers for incoming requests based on a set of file types. The file type list can be found on ``src/control_headers.rs`` file [env: SERVER_CACHE_CONTROL_HEADERS=]  [default: true]
-
--x, --compression <compression>::
-Gzip, Deflate or Brotli compression on demand determined by the Accept-Encoding header and applied to text-based web file types only [env: SERVER_COMPRESSION=]  [default: true]
-
--w, --config-file <config-file>::
-Server TOML configuration file path [env: SERVER_CONFIG_FILE=]
-
--j, --cors-allow-headers <cors-allow-headers>::
-Specify an optional CORS list of allowed headers separated by commas. Default "origin, content-type". It requires ``--cors-allow-origins`` to be used along with [env: SERVER_CORS_ALLOW_HEADERS=]  [default: origin, content-type]
-
--c, --cors-allow-origins <cors-allow-origins>::
-Specify an optional CORS list of allowed origin hosts separated by commas. Host ports or protocols aren't being checked. Use an asterisk (*) to allow any host [env: SERVER_CORS_ALLOW_ORIGINS=]  [default: ]
-
---cors-expose-headers <cors-expose-headers>::
-Specify an optional CORS list of exposed headers separated by commas. Default "origin, content-type". It requires ``--cors-expose-origins`` to be used along with [env: SERVER_CORS_EXPOSE_HEADERS=]  [default: origin, content-type]
-
--z, --directory-listing <directory-listing>::
-Enable directory listing for all requests ending with the slash character (‘/’) [env: SERVER_DIRECTORY_LISTING=]  [default: false]
-
---directory-listing-order <directory-listing-order>::
-Specify a default code number to order directory listing entries per ``Name``, ``Last modified`` or ``Size`` attributes (columns). Code numbers supported: 0 (Name asc), 1 (Name desc), 2 (Last modified asc), 3 (Last modified desc), 4 (Size asc), 5 (Size desc). Default 6 (unordered) [env: SERVER_DIRECTORY_LISTING_ORDER=] [default: 6]
-
--f, --fd <fd>::
-Instead of binding to a TCP port, accept incoming connections to an already-bound TCP socket listener on the specified file descriptor number (usually zero). Requires that the parent process (e.g. inetd, launchd, or systemd) binds an address and port on behalf of static-web-server, before arranging for the resulting file descriptor to be inherited by static-web-server. Cannot be used in conjunction with the port and host arguments. The included systemd unit file utilises this feature to increase security by allowing the static-web-server to be sandboxed more completely [env: SERVER_LISTEN_FD=]
-
--q, --grace-period <grace-period>::
-Defines a grace period in seconds after a ``SIGTERM`` signal is caught which will delay the server before to shut it down gracefully. The maximum value is 255 seconds [env: SERVER_GRACE_PERIOD=]  [default: 0]
-
--a, --host <host>::
-Host address (E.g 127.0.0.1 or ::1) [env: SERVER_HOST=]  [default: ::]
-
--t, --http2 <http2>::
-Enable HTTP/2 with TLS support [env: SERVER_HTTP2_TLS=]  [default: false]
-
---http2-tls-cert <http2-tls-cert>::
-Specify the file path to read the certificate [env: SERVER_HTTP2_TLS_CERT=]
-
---http2-tls-key <http2-tls-key>::
-Specify the file path to read the private key [env: SERVER_HTTP2_TLS_KEY=]
-
--g, --log-level <log-level>::
-Specify a logging level in lower case. Values: error, warn, info, debug or trace [env: SERVER_LOG_LEVEL=] [default: error]
-
---log-remote-address <log-remote-address>::
-Log incoming requests information along with its remote address if available using the ``info`` log level [env: SERVER_LOG_REMOTE_ADDRESS=]  [default: false]
-
---page-fallback <page-fallback>::
-HTML file path that is used for GET requests when the requested path doesn't exist. The fallback page is served with a 200 status code, useful when using client routers. If the path is not specified or simply doesn't exist then this feature will not be active [env: SERVER_FALLBACK_PAGE=]
-
---page404 <page404>::
-HTML file path for 404 errors. If the path is not specified or simply doesn't exist then the server will use a generic HTML error message [env: SERVER_ERROR_PAGE_404=]  [default: ./public/404.html]
-
---page50x <page50x>::
-HTML file path for 50x errors. If the path is not specified or simply doesn't exist then the server will use a generic HTML error message [env: SERVER_ERROR_PAGE_50X=]  [default: ./public/50x.html]
-
--p, --port <port>::
-Host port [env: SERVER_PORT=]  [default: 80]
-
--d, --root <root>::
-Root directory path of static files [env: SERVER_ROOT=]  [default: ./public]
-
---security-headers <security-headers>::
-Enable security headers by default when HTTP/2 feature is activated. Headers included: "Strict-Transport- Security: max-age=63072000; includeSubDomains; preload" (2 years max-age), "X-Frame-Options: DENY" and "Content-Security-Policy: frame-ancestors 'self'" [env: SERVER_SECURITY_HEADERS=]  [default: false]
-
--n, --threads-multiplier <threads-multiplier>::
-Number of worker threads multiplier that'll be multiplied by the number of system CPUs using the formula: ``worker threads = number of CPUs * n`` where ``n`` is the value that changes here. When multiplier value is 0 or 1 then one thread per core is used. Number of worker threads result should be a number between 1 and 32,768 though it is advised to keep this value on the smaller side [env: SERVER_THREADS_MULTIPLIER=] [default: 1]
-
-
-VERSION
--------
-2.9.0
-
-
-HOMEPAGE
---------
-https://static-web-server.net
-
-
-REPORTING BUGS
---------------
-
-Report bugs and feature requests in the issue tracker. Please do your best to provide a reproducible test case for bugs.
-
-https://github.com/static-web-server/static-web-server/issues
-
-AUTHORS
--------
-Jose Quintana <joseluisq.net>