ytursyna
/
public
forked from root/public
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Browse Source

feat(localhost): complete subject and audit 

audit completely refactored and improved (more clear, more questions, irrelevant question removed, bonuses updated)
small improvements on the subject
mikysett 2 years ago
parent
ea634fe36e
commit
05f8f75d05
2 changed files with 52 additions and 51 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 11
      subjects/localhost/README.md
  2. 92
      subjects/localhost/audit/README.md

11
subjects/localhost/README.md
unescape_control_characters View File

@ -16,8 +16,8 @@ Here you will learn the basics of the protocol and a good place to start could b
- Your server should **never** crash.
- All requests should timeout if they are taking too long.
- Your server should be able to listen on multiple ports and instantiate multiple servers at the same time.
- Your server must receive a request from the browser/client and send a response using the `HTTP` header and body.
- You must use only one process and one thread.
- Your server must receive a request from the browser/client and send a response using the `HTTP` header and body.
- Your server should be compatible with `HTTP/1.1` protocol.
- You can compare your results with `NGINX` which will be used as the reference.
- Your server should be compatible with the last version of your chosen browser.
@ -43,13 +43,13 @@ Here you will learn the basics of the protocol and a good place to start could b
In the file you should be able to specify the following:
- Choose the host (server_address) and one port or multiple ports for each server.
- The host (server_address) and one or multiple ports for each server.
- The first server for a host:port will be the default if the "server_name" didn't match any other server.
- Path to custom error pages.
- Limit client body size for uploads.
- Setup routes with one or multiple of the following settings:
- Define a list of accepted HTTP methods for the route.
- Define an HTTP redirection.
- Define HTTP redirections.
- Define a directory or a file from where the file should be searched (for example, if `/test` is rooted to `/usr/Desktop`, the URL `/test/my_page.html` will route to `/usr/Desktop/my_page.html`).
- Define a default file for the route if the URL is a directory.
- Specify a `CGI` to use for a certain file extension.
@ -62,8 +62,9 @@ In the file you should be able to specify the following:
> There is no need to pass through `poll` when reading the configuration file.
#### Testing your server
- Do stress tests (for example with `siege -b [IP]:[PORT]`), it must stay available at all costs (availability should be up to 95.99).
- Create and provide during the audit tests for as many cases as you can (redirections, bad configuration files, static and dynamic pages, default error pages and so on).
- Do stress tests (for example with `siege -b [IP]:[PORT]`), it must stay available at all costs (availability should be up to 99.5).
- Create tests for as many cases as you can (redirections, bad configuration files, static and dynamic pages, default error pages and so on).
- You will be requested to provide and explain your tests during the audits.
- You can use the language you prefer to write tests, as long as they are exhaustive and the auditor can check their behavior.
- Test possible memory leaks before to submit the project.
- Once again, the server should never crash and never leak memory.

92
subjects/localhost/audit/README.md
unescape_control_characters View File

@ -1,65 +1,65 @@
#### Functional
#### Localhost is about program your own HTTP server and test it with an actual browser.
###### Take The necessary time to understand the project and to test it, take a look around the code and ask reasonable questions such as:
###### Explain the basics of an HTTP server.
###### Ask which function they used for I/O Multiplexing.
###### Ask to get an explanation of how select (or equivalent) is working.
###### Ask if they use only one select (or equivalent) and how they've managed the server with one select to accept and read the client requests.
###### There should be only one read or one write per client per select (or equivalent). Ask to show you the code that goes from the select (or equivalent) to the read and write of a client.
###### Check the return value for I/O functions[read,recv,write,send] and check if the returned value is well checked. (checking only -1 or 0 is not good you should check both).
###### Writing or reading ANY file descriptor without going through the select (or equivalent) is strictly.
#### Localhost is about creating your own HTTP server and test it with an actual browser.
#### Take the necessary time to understand the project and to test it, looking into the source code will help a lot.
### Configuration
### Basic server mechanics
#### Check the configuration file for the following:
##### Look at the subject configuration file to compare it to the project configuration file. Check if it's formatted the same.
##### Look for the HTTP response status codes list on internet.
##### Set up multiple servers with different port
##### Set up multiple servers with different hostnames (use something like: curl --resolve example.com:80:127.0.0.1 http://example.com/)
##### Setup default error page
##### Limit the client body (use curl -X POST -H "Content-Type: plain/text" --data "BODY IS HERE write something shorter or longer than body limit")
##### Setup routes in a server to different directories
##### Setup a default file to search for if you ask for a directory
##### Set up a list of methods accepted for a certain route (ex: try to delete something with and without permission)
#### The student should be able to justify his choices and explain the following:
###### How does an HTTP server works?
###### Which function was used for I/O Multiplexing and how does it works?
###### Is the server using only one select (or equivalent) to read the client requests and write answers?
###### Why is it important to use only one select and how was it achieved?
###### Read the code that goes from the select (or equivalent) to the read and write of a client, is there only one read or write per client per select (or equivalent)?
###### Are the return values for I/O functions [read,recv,write,send] checked properly? (checking only -1 or 0 is not enough, both should be checked).
###### If an error is returned by the previous functions on a socket, is the client removed?
###### Is writing and reading ALWAYS done through a select (or equivalent)?
### Basic checks
### Configuration file
###### Using telnet, curl, and prepared files demonstrate that the following features work correctly:
##### Test if the GET requests works well.
##### Test if the POST requests works well.
##### Test if the DELETE requests works well.
##### Test an UNKNOWN request, it should not work, but the server is not supposed to crash.
##### For every test, there is a status code (RFC) that must be respected.
##### upload some files to the server and get them back.
#### Check the configuration file and ensure the following configs are working:
##### Setup a single server with a single port.
##### Setup multiple servers with different port.
##### Setup multiple servers with different hostnames (for example: curl --resolve test.com:80:127.0.0.1 http://test.com/).
##### Setup custom error pages.
##### Limit the client body (for example: curl -X POST -H "Content-Type: plain/text" --data "BODY with something shorter or longer than body limit").
##### Setup routes and ensure they are taken into account.
##### Setup a default file in case the path is a directory.
##### Setup a list of accepted methods for a route (for example: try to DELETE something with and without permission).
### Check with a browser
### Methods and cookies
##### Use the reference browser of the team, open the network part of it, and try to connect to the server with it.
##### Look at the request header and response header, It should be able to serve a fully static website.
##### Try a wrong URL on the server.
##### Try to list a directory.
##### Try a redirected URL.
##### Try logical things
#### For each method be sure to check the status code (200, 404 etc):
###### Are the GET requests working properly?
###### Are the POST requests working properly?
###### Are the DELETE requests working properly?
###### Test a WRONG request, is the server still working properly?
###### Upload some files to the server and get them back to test they were not corrupted.
###### A working session and cookies system is present on the server?
### Cookies and session
### Interaction with the browser
##### It should be a working session and cookies system on the webserver.
#### Open the browser used by the team during tests and its developer tools panel to help you with tests.
###### Is te browser connecting with the server with no issues?
###### Are the request and response headers correct? (It should serve a full static website without any problem).
###### Try a wrong URL on the server, is it handled properly?
###### Try to list a directory, is it handled properly?
###### Try a redirected URL, is it handled properly?
###### Check the implemented CGI, does it works properly with chunked and unchunked data?
### Port issues
##### In the configuration file setup multiple ports and use different websites, use the browser to check that the configuration is working as expected, and show the right website.
##### In the configuration try to setup the same port multiple times. It should not work.
##### Launch multiple servers at the same time with different configurations but with common ports. check if it's working and ask why the server should work if one of the configurations isn't working?.
###### Configure multiple ports and websites and ensure it is working as expected.
###### Configure the same port multiple times. The server should find the error.
###### Configure multiple servers at the same time with different configurations but with common ports. Ask why the server should work if one of the configurations isn't working.
### Siege & stress test
##### Use Siege to run some stress tests.
##### Availability should be above 95.99% for a simple get on an empty page with a `siege -b [IP]:[PORT]` on that page.
##### Check if there is no memory leak (monitor the process memory usage it should not go up indefinitely).
##### Use siege with a GET method on an empty page, availability should be at least 99.5% with the command `siege -b [IP]:[PORT]`.
##### Check if there is no memory leak (you could use some tools like top).
##### Check if there is no hanging connection.
##### You should be able to use siege indefinitely without restarting the server (look at siege -b).
### Bonus Part
##### + There's more than one CGI system such as [Python, C++,Perle].
##### + Browse http://[IP]:[PORT]/mysql.php and check if the student create a php page that can connect to a database.
##### +There's more than one CGI system such as [Python,C++,Perl].
##### +There is a second implementation of the server in a different language (repeat practical tests on it before to validate).

Write Preview
Loading…
Cancel
Save