Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Implement origin blocking via the Cors struct.

Describe alternatives you've considered

Additional context
This feature request is open just in case if any new contributor would like to try and implement it. In the meantime, I just implemented an algorithm to find all the headers from a plain String in the utils directory and now I will read more about how CORS works.

What is the feature you want to improve or implement?
When looking running an informal audit of this codebase, I noticed there are zero test cases at all. Considering VRS attempts to parse (even a subset of) HTTP on its own, I find this extremely surprising. Ideally, there should be a decent range of request-response pairs, as well as some form of fuzzing to catch parsing errors.

Additional information:
As currently structured, I don't think the implementation of the server is particularly testable. It uses a hardcoded address+port (as well as requiring root/admin to run), and there is no other way for code to send the core of the server a request. Reorganizing the server to have some form of fn serve_request(configuration: Configuration, input: impl Read, output: impl Write) (note that this signature is infallible- errors should be written to the output here [HTTP status code] and/or a configured logger) would drastically increase the testability of the server and build confidence in its correctness.

If a refactor that introduces these features occurs, I'm willing to help build a test suite to run on them.

There is a lot of unwraps that should be ?s with error handling, ideally returning appropriate HTTP error status code in server response. The most egregious are unwraps on reading from socket, and on parsing utf8, both are trivially exploitable for DOS attacks:

1. Open a connection, send no data, close connection: read will error, unwrap will panic, server will crash.
2. Send a request with malformed (non-utf8 URI): from_utf8 will error, unwrap will panic, server will crash.

Multi-threading is safer since panics only kill the thread they occur on, but they should still be avoided.

What is the feature you want to improve or implement?
Error-handling in the codebase.

Additional information:
Currently, the project heavily relies on the excessive usage of unwraps in the main logic of the code. I believe that we could replace all possible panics in the server with more graceful errors and decrease the use of unwraps.

I'm going to implement this change myself, submitting this issue in order to track the changes happening.

What is the feature you want to improve or implement?

It would be nice to implement a way for the host to just be able to write their documents in markdown syntax and when an end user tries to access that document it gets interpreted into HTML before being sent to the browser.

Additional information:

I want to implement this because it's more convenient for some people to write documents in markdown than in HTML.

The way this would work is, for example, the server host creates a helloworld.md file in /var/www/static and when a user tries to access http://localhost:80/helloworld.html the server finds a file with the same name but in the markdown extension (.md), it interprets it to HTML and then it sends back the HTML it generated.

This could add some overhead on the server-side because in the worst case scenario the markdown document could be very large and hundreds of lines, so parsing and interpreting the document before sending it back could take a long time. In the future this could be improved by implementing caching for the documents, but this is only going to be considered if I decide that this idea is worth implementing into the final product.

Would love to hear feedback for this idea from anyone passing by. This is probably going to be considered for v1.2.0.

Describe the bug
vrs serves files that are outside /var/www/static by using .. in path. This allows potentially sensistive files to be read from the server, for example /etc/passwd

To Reproduce

> sudo ./setup.sh
> cargo build
> sudo ./target/debug/vrs &
> echo "GET /../../../etc/passwd HTTP/1.1" | nc localhost 80
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1322

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
vscode:x:1000:1000::/home/vscode:/bin/bash
systemd-timesync:x:101:103:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:104:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:105:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:106::/nonexistent:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin

Expected behavior
404 or 400 error