Subject

Chapter II 챕터 2

General rules 일반 규칙

• Your program should not crash in any circumstances (even when it runs out of memory), and should not quit unexpectedly. If it happens, your project will be considered non-functional and your grade will be 0.

• 어떤 상황에서든, 심지어는 프로그램을 구동시 메모리가 부족한 상황에서도 crash가 일어나서는 안됩니다. 만약 그런 상황이 발생한다면, 여러분의 프로젝트는 구동이 불가능하다고 여겨지며 0점 처리 될 것입니다.

• You have to turn in a Makefile which will compile your source files. It must not relink.

• 제출하신 소스코드 컴파일을 위해 Makefile을 제출하셔야 하며, 리링크가 발생하지 않아야 합니다.

• Your Makefile must at least contain the rules: $(NAME), all, clean, fclean and re.

• Makefile 제출시 아래의 룰은 적어도 반드시 포함되어야 합니다 : $(NAME), all, clean, fclean, re.

• Compile your code with c++ and the flags -Wall -Wextra -Werror

• 제출하신 코드는 c++ 컴파일러로 컴파일되어야 하며, -Wall -Wextra -Werror 플래그와 함께 컴파일되어야 합니다.

• Your code must comply with the C++ 98 standard. Then, it should still compile if you add the flag -std=c++98.

• 제출하신 코드는 C++ 98 기준에 부합해야하며, 컴파일시 플래그로 -std=c++98을 기입해야 합니다.

• Try to always develop using the most C++ features you can (for example, choose over <string.h>). You are allowed to use C functions, but always prefer their C++ versions if possible.

• 기능 개발시에 C++ 기능들을 전반적으로 활용해보도록 시도해보세요. (예를 들어, <string.h> 대신 을 선택하기) C언어 함수들은 여전히 사용 가능하지만, C++ 버전의 것을 사용해보는 것이 더 낫습니다.

• Any external library and Boost libraries are forbidden.

• 외부 라이브러리와 Boost 라이브러리는 활용이 금지됩니다.

---

Chapter III

챕터 III

Mandatory part

필수파트

subject	content
Program name	webserv
Turn in files	Makefile, *.{h, hpp}, *.cpp, *.tpp, *.ipp, configuration files
Makefile	NAME, all, clean, fclean, re
Arguments	[A configuration file]
External functions	Everything in C++ 98. htons, htonl, ntohs, ntohl, select, poll, epoll (epoll_create, epoll_ctl, epoll_wait), kqueue (kqueue, kevent), socket, accept, listen, send, recv, bind, connect, inet_addr, setsockopt, getsockname, fcntl
Libft authorized	n/a
Description	C++ 98 기반 HTTP 서버

You must write a HTTP server in C++ 98.

반드시 C++로 HTTP 서버를 구현해야 합니다.

Your executable will be run as follows:

실행파일은 아래와 같이 실행하면 됩니다:

./webserv [configuration file]

---

! Even if poll() is mentionned in the subject and the evaluation scale, you can use any equivalent such as select(), kqueue(), or epoll().

poll() 함수가 서브젝트에서 언급되어 있기는 하지만, 이와 동등한 함수인 select(), kqueue(), epoll() 등의 함수도 사용할 수 있습니다.

Please read the RFC and do some tests with telnet and NGINX before starting this project. Even if you don’t have to implement all the RFC, reading it will help
you develop the required features.

RFC를 주의깊게 읽고 telnet과 nginx로 몇가지 테스트를 진행해보세요. RFC에 언급된 모든 기능을 구현하는 것은 아니더라고 해도, 이를 숙지하는 것은 요구사항에 있는 기능을 개발할 때에 도움이 될 것입니다.

---

III.1 Requirements

III.1 요구사항

• Your program has to take a configuration file as argument, or use a default path.

• 프로그램은 매개변수, 혹은 기본 경로에 있는 설정파일을 사용해야 합니다.

• You can’t execve another web server.

• 다른 종류의 웹서버를 내부적으로 실행하면 안됩니다.

• Your server must never block and the client can be bounced properly if necessary.

• 여러분의 서버는 정지되면 안되고, 클라이언트는 필요시 적절하게 연결을 끊어야 합니다.

• It must be non-blocking and use only 1 poll() (or equivalent) for all the I/O operations between the client and the server (listen included).

서버와 클라이언트 사이에 listen을 포함한 모든 I/O 통신 작업을 수행할 때, 반드시 non-blocking 이어야하며 하나의 poll(), 혹은 그와 동등한 것을 사용해야 합니다.

• poll() (or equivalent) must check read and write at the same time.

• poll() (혹은 사용하는 동등한 함수)는 read 와 write를 동시에 확인해야 합니다.

• You must never do a read or a write operation without going through poll() (or equivalent).

• poll() (혹은 사용하는 동등한 함수)를 하지 않고 read나 write를 해서는 안됩니다.

• Checking the value of errno is strictly forbidden after a read or a write operation.

• read/write 이후에 errno를 확인하는 것은 엄격하게 금지됩니다.

• You don’t need to use poll() (or equivalent) before reading your configuration file.

•

! Because you have to use non-blocking file descriptors, it is possible to use read/recv or write/send functions with no poll() (or equivalent), and your server wouldn’t be blocking. But it would consume more system resources. 
Thus, if you try to read/recv or write/send in any file descriptor without using poll() (or equivalent), your grade will be 0.

non-blocking FD 를 사용해야만 하기 때문에 여러분의 서버가 poll() (혹은 사용하는 동등한 함수) 없이 read/recv 또는 write/send 만으로 블로킹이 되지 않을 지도 모릅니다.
다시 한번 말하지만, read/recv 또는 write/send 를 어떤 FD 던간에 poll() (혹은 사용하는 동등한 함수) 없이 사용한다면 여러분은 0점을 맞게 될 것입니다.

• You can use every macro and define like FD_SET, FD_CLR, FD_ISSET, FD_ZERO (understanding what and how they do it is very useful).

• FD_SET, FD_CLR, FD_ISSET, FD_ZERO 와 같은 모든 macro와 define을 사용할 수 있습니다. (이게 무엇이고, 어디에 유용하게 쓰이는 지를 이해해보세요.)

• A request to your server should never hang forever.

• 서버로 온 리퀘스트가 영원히 머물면 안됩니다.

• Your server must be compatible with the web browser of your choice.

• 서버는 웹 브라우저와 호환 가능해야 합니다.

• We will consider that NGINX is HTTP 1.1 compliant and may be used to compare headers and answer behaviors.

• 평가시에는 NginX는 HTTP 1.1과 호환되며, 헤더와 응답 동작을 비교하는 데에 사용될 수 있습니다.

• Your HTTP response status codes must be accurate.

• 서버가 보내어주는 HTTP 응답 상태코드는 정확해야 합니다.

• You server must have default error pages if none are provided.

• 에러페이지가 제공되지 않는 경우에는 기본 에러 페이지를 사용해야 합니다.

• You can’t use fork for something else than CGI (like PHP, or Python, and so forth).

• CGI (PHP, Python 등등에서와 같이)를 제외하고서는 fork()를 사용할 수 없습니다.

• You must be able to serve a fully static website.

• 여러분의 서버는 정적 웹사이트를 제공할 수 있어야 합니다.

• Clients must be able to upload files.

• 클라이언트에서 파일을 업로드할 수 있어야 합니다.

• You need at least GET, POST, and DELETE methods.

• GET, POST, DELETE 메소드를 처리할 수 있어야 합니다.

• Stress tests your server. It must stay available at all cost.

• 서버를 만들었다면 스트레스 테스트를 진행해보세요. 서버에 부하가 가해지는 와중에도 동작할 수 있어야 합니다. (테스터 참고)

• Your server must be able to listen to multiple ports (see Configuration file).

• 여러분의 서버는 여러 개의 포트에서 리스닝할 수 있어야 합니다. (설정 파일을 보세요)

---

III.2 For MacOS only

III.2 맥 유저 한정 참고

Since MacOS doesn’t implement write() the same way as other Unix OSes, you are allowed to use fcntl().
You must use file descriptors in non-blocking mode in order to get a behavior similar to the one of other Unix OSes.

macOS 가 다른 unix OS 와 다르게 구현이 되었기 따문에 저희는 여러분이 fcntl 을 사용할 수 있도록 하겠습니다.
여러분은 반드시 다른 OS 와 비슷한 결과를 갖기 위해서 non-blocking FD 를 사용해야 합니다. 

However, you are allowed to use fcntl() only as follows: fcntl(fd, F_SETFL, O_NONBLOCK);
Any other flag is forbidden.

여러분은 fcntl 을 다음과 같은 형태로만 사용할 수 있습니다 : fcntl(fd, F_SETFL, O_NONBLOCK);
다른 flag 들은 사용해서는 안됩니다.

---

III.3 Configuration file

III.3 설정 파일

You can get some inspiration from the ’server’ part of NGINX configuration file.

설정 파일을 만들기 위해, Nginx 설정 파일의 'server' 파트를 참고할 수 있습니다.

In the configuration file, you should be able to:

설정 파일에서는 다음과 같은 것들이 가능해야 합니다.

• Choose the port and host of each ’server’.

• 각각의 'server'의 포트와 호스트 선택.

• Setup the server_names or not.

• server_name을 설정 혹은 비설정.

• The first server for a host:port will be the default for this host:port (that means it will answer to all the requests that don’t belong to an other server).

• 첫 번째 서버의 host:port는 해당 host:port의 기본 설정이 됩니다. 이는 다른 서버에 속하지 않는 요청을 응답하는 데에 사용됩니다.

• Setup default error pages.

• 기본 에러 페이지 설정.

• Limit client body size.

• 클라이언트의 body size 제한.

• Setup routes with one or multiple of the following rules/configuration (routes wont be using regexp):

• 라우트 설정, 다음 중 하나 또는 여러 개의 규칙/설정을 적용할 수 있어야 합니다. (라우트에서 정규식은 쓰이지 않습니다.)

◦ Define a list of accepted HTTP methods for the route.

◦ 해당 라우트가 요청받을 수 있는 HTTP 메소드 목록 정의

◦ Define a HTTP redirection.

◦ HTTP 리다이렉션 정의

◦ Define a directory or a file from where the file should be searched (for example, if url /kapouet is rooted to /tmp/www, url /kapouet/pouic/toto/pouet is /tmp/www/pouic/toto/pouet).

◦ 파일이 검색될 디렉토리나 파일을 정의 (예를 들어, $url/kapouet 의 루트로 /tmp/www 가 설정이 되었다면, $url/kapouet/pouic/toto/pouet는 /tmp/www/pouic/toto/pouet 가 됩니다 )

◦ Turn on or off directory listing.

◦ 디렉토리 리스닝 기능 켜고 끄기

◦ Set a default file to answer if the request is a directory.

◦ 리퀘스트가 디렉토리인 경우 응답할 기본 파일 설정

◦ Execute CGI based on certain file extension (for example .php).

◦ 특정 파일 확장자를 설정하여 CGI 실행 (예를 들어서, *.php)

◦ Make the route able to accept uploaded files and configure where they should be saved.

◦ 라우트를 업로드가 가능하도록 만들고 어디에 저장할 지 설정하기

∗ Because you won’t call the CGI directly, use the full path as PATH_INFO.
* 여러분은 CGI를 직접 호출하는 것이 아니기에, 전체 경로로 PATH_INFO를 사용합니다. 

∗ Just remember that, for chunked request, your server needs to unchunked it and the CGI will expect EOF as end of the body.
* chunked request를 받는 경우, 여러분의 서버는 해당 요청을 unchunk 해야하며, GCI는 동작시 body의 맨 끝에 EOF를 예상하고 있다는 것을 기억하세요.

∗ Same things for the output of the CGI. If no content_length is returned from the CGI, EOF will mark the end of the returned data.
* CGI의 아웃풋도 같은 방식입니다. 만약 content_length가 CGI로 부터 리턴이 된다면, EOF는 리턴된 데이터의 맨 끝을 의미합니다.

∗ Your program should call the CGI with the file requested as first argument.
* 여러분의 프로그램은 요청된 파일을 CGI의 첫 번째 매개변수로 호출해야합니다.

∗ The CGI should be run in the correct directory for relative path file access.
* CGI는 상대경로 접근을 위해 반드시 올바른 디렉토리에서 수행되어야 합니다.

∗ Your server should work with one CGI (php-CGI, Python, and so forth).
* 여러분의 서버는 하나의 CGI와 동작해야합니다. (php-CGI, python, 혹은 기타등등)

You must provide some configuration files and default basic files to test and demonstrate every feature works during evaluation.

평가시에는 여러분의 기능을 시연하기 위해 기본적으로 기본 파일들과 설정 파일들을 제공해야 합니다.

If you’ve got a question about one behavior, you should compare your program behavior with NGINX’s. For example, check how does server_name work.

동작이나 기능에 대해 의문을 가진다면 NginX의 것과 비교해보세요. 예를 들어 server_name이 NginX에서 어떻게 동작하는지 확인해보세요.

We’ve shared with you a small tester. It’s not mandatory to pass it if everything works fine with your browser and tests, but it can help you hunt some bugs.

인트라에 작은 테스터를 제공했습니다. 이를 통과하는 것이 멘다토리를 만족한다는 의미는 아니라는 것을 명심하세요. 하지만 여러가지 버그를 잡아내는 데에 도움을 줄 수 있을 것입니다.

The important thing is resilience. Your server should never die.

가장 중요한 것은 지속력입니다. 여러분의 서버는 죽으면 안됩니다. 절대로요.

Do not test with only one program. Write your tests with a more convenient language such as Python or Golang, and so forth. Even in C or C++ if you want to.

한 가지 프로그램만으로 테스트하지 마세요. Python이나 Golang, 심지어는 C와 C++로도 가능하니, 여러분이 사용 가능한 언어로 테스트를 만들어보세요.

---

Bonus part

보너스 파트

Here are the extra features you can add:

여기서는 여러분이 구현할 수 있는 추가 기능을 다룹니다.

• Support cookies and session management (prepare quick examples).

• 쿠키 / 세션 매니지먼트 기능

• Handle multiple CGI.

• 다중 CGI 지원