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
Unified 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. - Your server should **never** crash.
- All requests should timeout if they are taking too long. - 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 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. - 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. - Your server should be compatible with `HTTP/1.1` protocol.
- You can compare your results with `NGINX` which will be used as the reference. - 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. - 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: 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. - 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. - Path to custom error pages.
- Limit client body size for uploads. - Limit client body size for uploads.
- Setup routes with one or multiple of the following settings: - Setup routes with one or multiple of the following settings:
- Define a list of accepted HTTP methods for the route. - 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 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. - Define a default file for the route if the URL is a directory.
- Specify a `CGI` to use for a certain file extension. - 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. > There is no need to pass through `poll` when reading the configuration file.
#### Testing your server #### 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). - 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 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). - 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. - 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. - Test possible memory leaks before to submit the project.
- Once again, the server should never crash and never leak memory. - 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 #### Functional
#### Localhost is about program your own HTTP server and test it with an actual browser. #### 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, take a look around the code and ask reasonable questions such as: #### Take the necessary time to understand the project and to test it, looking into the source code will help a lot.
###### 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.
### Configuration ### Basic server mechanics
#### Check the configuration file for the following: #### The student should be able to justify his choices and explain the following:
##### Look at the subject configuration file to compare it to the project configuration file. Check if it's formatted the same. ###### How does an HTTP server works?
##### Look for the HTTP response status codes list on internet. ###### Which function was used for I/O Multiplexing and how does it works?
##### Set up multiple servers with different port ###### Is the server using only one select (or equivalent) to read the client requests and write answers?
##### Set up multiple servers with different hostnames (use something like: curl --resolve example.com:80:127.0.0.1 http://example.com/) ###### Why is it important to use only one select and how was it achieved?
##### Setup default error page ###### 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)?
##### 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") ###### 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).
##### Setup routes in a server to different directories ###### If an error is returned by the previous functions on a socket, is the client removed?
##### Setup a default file to search for if you ask for a directory ###### Is writing and reading ALWAYS done through a select (or equivalent)?
##### Set up a list of methods accepted for a certain route (ex: try to delete something with and without permission)
### Basic checks ### Configuration file
###### Using telnet, curl, and prepared files demonstrate that the following features work correctly: #### Check the configuration file and ensure the following configs are working:
##### Test if the GET requests works well. ##### Setup a single server with a single port.
##### Test if the POST requests works well. ##### Setup multiple servers with different port.
##### Test if the DELETE requests works well. ##### Setup multiple servers with different hostnames (for example: curl --resolve test.com:80:127.0.0.1 http://test.com/).
##### Test an UNKNOWN request, it should not work, but the server is not supposed to crash. ##### Setup custom error pages.
##### For every test, there is a status code (RFC) that must be respected. ##### Limit the client body (for example: curl -X POST -H "Content-Type: plain/text" --data "BODY with something shorter or longer than body limit").
##### upload some files to the server and get them back. ##### 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. #### For each method be sure to check the status code (200, 404 etc):
##### Look at the request header and response header, It should be able to serve a fully static website. ###### Are the GET requests working properly?
##### Try a wrong URL on the server. ###### Are the POST requests working properly?
##### Try to list a directory. ###### Are the DELETE requests working properly?
##### Try a redirected URL. ###### Test a WRONG request, is the server still working properly?
##### Try logical things ###### 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 ### 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. ###### Configure multiple ports and websites and ensure it is working as expected.
##### In the configuration try to setup the same port multiple times. It should not work. ###### Configure the same port multiple times. The server should find the error.
##### 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 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 ### Siege & stress test
##### Use Siege to run some stress tests. ##### Use siege with a GET method on an empty page, availability should be at least 99.5% with the command `siege -b [IP]:[PORT]`.
##### 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 (you could use some tools like top).
##### Check if there is no memory leak (monitor the process memory usage it should not go up indefinitely).
##### Check if there is no hanging connection. ##### 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 ### Bonus Part
##### + There's more than one CGI system such as [Python, C++,Perle]. ##### +There's more than one CGI system such as [Python,C++,Perl].
##### + Browse http://[IP]:[PORT]/mysql.php and check if the student create a php page that can connect to a database. ##### +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