Psycokwet / webserv

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

webserv

Some references before starting the project

(better go through this list by order)
  1. General understanding on OSI model
  2. How website works - part 1/2: Frontend, request, response, header, HTTP's methods
  3. How website works - part 2/2: web server, backend
  4. How to Build a simple HTTP server from scratch (using C)

Quelque idée sur le projet

En gros webserv c’est un minishell le bail. Sauf qu’au lieu de parser des commandes tu parses des requetes web.
Tu vas recevoir un truc sur un fd (socket), le lire, puis le parser.

Le projet peut être découpé assez simplement :

1. Réseau

Il y a toute une partie orchestration des connections, où il faut jongler avec les fd, qui lire, sur qui écrire, et comment gérer l’availabiliy.
On peut faire comme le lien "How to buil HTTP...from scratch".
Après il faudra que tu fasses un client pour tester, ou que tu testes avec curl.
Et derrière faut que t’étoffes en rendant chaque socket connectable avec select (qui est justement un gestionnaire de fd).
Le browser va sortir pour nous une requête automatiquement comme ça.


En gros :
Tu crées une socket en spécifiant host 10.24.3.23 et port 8080.
T’obtiens ton FD associé.
Maintenant si tu fais un “curl 10.24.3.23:8080” tu recevras la requête sur le FD et tu pourras la read()
Idem si tu vas dans google à l’adresse http://10.24.3.23:8080, ton browser va envoyer une requete GET à ce host:port que tu pourras read() sur le FD.
Après avoir fait curl, tu fais read(), et là c'est la partie parsing commence.

2. Parsing

Le parsing de la requête (grosse partie, je conseille de charger le moins possible la personne qui s’en occupe) - il s’agit de bien lire la requête pour comprendre ce que veut le user.

Et en gros le parsing va ressortir trois infos
1 - La méthode (donc en gros ce que le mec veut faire) : GET pour lire, PUT pour écrire, etc
2 - Les headers, une liste d’infos qui vont changer (ou non) ce que tu renvoies
3 - Le body, un bout de texte optionnel, qui contiendrait par exemple la page que l’utilisateur veut PUT dans le cas d’un PUT

Dans cette partie, il faut sortir un reponse du même HTTP protocol, comme ça


Après tu l'envois ver le même fd.
Et le taff de browser c'est lire le reponse qu'on l'a envoyé et afficher le fichier hello.html.

3. Autres

Config : le programme aura un fichier de config qui changera son comportement en fonction de l’url, du serveur appelé, etc

CGI : il faut aussi gérer la CGI (appel avec execve d’un éxecutable externe, puis renvoi de l’output de ce dernier, PHP par exemple)

A priori je dirais un sur le réseau, un sur le parsing, un sur le reste. Avec le troisième qui aide au parsing

About


Languages

Language:C++ 86.1%Language:Makefile 4.0%Language:C 3.1%Language:HTML 3.0%Language:CSS 2.0%Language:PHP 1.8%Language:Python 0.1%