diff --git a/.gitignore b/.gitignore index 0137954..cc50a14 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,7 @@ .DS_Store Thumbs.db *.o +*.d *.swp *.out *.exe diff --git a/Makefile b/Makefile index 4a5694c..754f0c2 100644 --- a/Makefile +++ b/Makefile @@ -20,6 +20,7 @@ HEADERS_D = srcs SRCS_D = srcs SRCS = main.cpp \ + ft_itoa.cpp \ Webserv.cpp OBJS_D = builds diff --git a/default_error_pages/404.html b/default_error_pages/404.html new file mode 100644 index 0000000..df4d27c --- /dev/null +++ b/default_error_pages/404.html @@ -0,0 +1,11 @@ + + + + 404 Not Found + + +

404 Not Found

+
+

Le Webserv/0.1

+ + \ No newline at end of file diff --git a/srcs/Client.hpp b/srcs/Client.hpp index 9092f31..2536012 100644 --- a/srcs/Client.hpp +++ b/srcs/Client.hpp @@ -6,9 +6,9 @@ # include # include -class Client +struct Client { - public: + // public: // Client(Placeholder); // Client(); // Client(Client const &src); @@ -18,9 +18,11 @@ class Client int fd; std::string raw_request; std::map request; - std::map response; + // std::map response; + std::string response; + unsigned int status; - private: + // private: }; diff --git a/srcs/Webserv.cpp b/srcs/Webserv.cpp index eaf285d..537e274 100644 --- a/srcs/Webserv.cpp +++ b/srcs/Webserv.cpp @@ -53,7 +53,7 @@ void Webserv::init_virtual_servers() // ADD config param throw std::runtime_error("Socket init"); } - _bind(_socket_fd, 80); + _bind(_socket_fd, 4040); _listen(_socket_fd, 512); // 512 arbitrary if (_epoll_update(_socket_fd, EPOLLIN, EPOLL_CTL_ADD) == -1) @@ -93,9 +93,9 @@ void Webserv::start() if ((events[i].data.fd == _socket_fd) && (events[i].events & EPOLLIN)) _accept_connection(events[i].data.fd); else if (events[i].events & EPOLLIN) - _read_request(static_cast(events[i].data.ptr)); + _request(static_cast(events[i].data.ptr)); else if (events[i].events & EPOLLOUT) - _send_response(static_cast(events[i].data.ptr)); + _response(static_cast(events[i].data.ptr)); // NEED TO BREAK HERE IF SIGINT (or throw in _handle_signal ?) ++i; _actual_client = NULL; } @@ -131,6 +131,12 @@ void Webserv::_accept_connection(int fd) ////////// // READ // + +void Webserv::_request(Client *client) +{ + _read_request(client); +} + void Webserv::_read_request(Client *client) { char buf[BUFSIZE+1]; @@ -164,22 +170,32 @@ void Webserv::_read_request(Client *client) /////////// // WRITE // + +void Webserv::_response(Client *client) +{ + _send_response(client); + client->raw_request.clear(); + client->response.clear(); +} + void Webserv::_send_response(Client *client) { ssize_t ret; _actual_client = client; std::cerr << "send()\n"; - std::cerr << "RAW_REQUEST\n|\n" << client->raw_request << "|\n"; + std::cerr << "RAW_REQUEST\n|\n" << client->raw_request << "|\n"; // DEBUG - ret = ::send(client->fd, MSG_TEST, sizeof MSG_TEST - 1, 0); + _construct_response(client); + + ret = ::send(client->fd, client->response.data(), client->response.size(), 0); if (ret == -1) { std::perror("err send(): "); if (g_last_signal) _handle_last_signal(); // else - // _close_client(client->fd); + // _close_client(client->fd); return ; } @@ -188,8 +204,111 @@ void Webserv::_send_response(Client *client) // _close_client(client->fd); // else // _epoll_update(client->fd, EPOLLIN, EPOLL_CTL_MOD, client); +} - client->raw_request.clear(); +void Webserv::_construct_response(Client *client) +{ + client->status = 200; + client->response.append("Server: Webserv/0.1\r\n"); + + client->response.append("Connection: close\r\n"); + + _get_ressource(client); + + _insert_status_line(client); +} + +#define E404 "\r\n404 Not Found

404 Not Found


Le Webserv/0.1

" +#define E500 "\r\n500 Internal Server Error

500 Internal Server Error


Le Webserv/0.1

" +void Webserv::_insert_status_line(Client *client) +{ + std::string status_line; + + status_line.append("HTTP/1.1 "); + // WIP, maybe make a map for status response + switch (client->status) + { + case (200): + status_line.append("200 OK"); + break; + case (404): + status_line.append("404 Not Found"); + client->response.append(E404); + break; + case (500): + status_line.append("500 Internal Server Error"); + client->response.append(E500); + break; + } + status_line.append("\r\n"); + + client->response.insert(0, status_line); +} + +#define ROOT "website" +#define INDEX "index.html" +#define FILENAME "rfc2119_no_link.html" +#define MAX_FILESIZE 1000000 // (1Mo) +void Webserv::_get_ressource(Client *client) +{ + std::ifstream ifd; // For chunk, ifstream directly in struct CLient for multiples read without close() ? + char buf[MAX_FILESIZE+1]; + char *tmp; + + // Mini parsing à l'arrache du PATH + std::string path; + path = client->raw_request.substr(0, client->raw_request.find("\r\n")); + path = path.substr(0, path.rfind(" ")); + path = path.substr(path.find("/")); + if (path == "/") + path.append(INDEX); + path.insert(0, ROOT); + + if (access(path.data(), R_OK) == -1) + { + std::perror("err access()"); + client->status = 404; + return ; + } + + ifd.open(path.data(), std::ios::binary | std::ios::ate); // std::ios::binary (binary for files like images ?) + if (!ifd) + { + std::cerr << path << ": open fail" << '\n'; + client->status = 500; + } + else + { + // WIP : Chunk or not chunk (if filesize too big) + std::streampos size = ifd.tellg(); + if (size > MAX_FILESIZE) + { + // Then chunk + client->status = 500; // WIP temp + std::cerr << "File too large for non chunk body\n"; + ifd.close(); + return ; + } + + ifd.seekg(0, std::ios::beg); + ifd.read(buf, size); + buf[ifd.gcount()] = '\0'; + + client->response.append("Content-Type: text/html; charset=UTF-8\r\n"); + + client->response.append("Content-Length: "); + tmp = ::ft_itoa(ifd.gcount()); + client->response.append(tmp); + delete tmp; + client->response.append("\r\n"); + + // Body + client->response.append("\r\n"); + client->response.append(buf); + + + ifd.close(); + } } @@ -238,6 +357,7 @@ void Webserv::_handle_last_signal() else if (g_last_signal == SIGINT) { g_run = false; + // maybe a throw here instead of "g_run" ? } g_last_signal = 0; } diff --git a/srcs/Webserv.hpp b/srcs/Webserv.hpp index b1fc02f..4a12004 100644 --- a/srcs/Webserv.hpp +++ b/srcs/Webserv.hpp @@ -24,6 +24,10 @@ # include "Client.hpp" # include "Server.hpp" # include // signal +# include // itoa +# include // ifstream +char *ft_itoa(int n); +# include // access # define BUFSIZE 8192 # define TIMEOUT 3000 @@ -67,8 +71,16 @@ class Webserv std::vector _clients; void _accept_connection(int fd); + + void _request(Client *client); void _read_request(Client *client); + + void _response(Client *client); void _send_response(Client *client); + void _construct_response(Client *client); + void _insert_status_line(Client *client); + void _get_ressource(Client *client); + int _epoll_update(int fd, uint32_t events, int op); int _epoll_update(int fd, uint32_t events, int op, void *ptr); diff --git a/srcs/ft_itoa.cpp b/srcs/ft_itoa.cpp new file mode 100644 index 0000000..1e996a9 --- /dev/null +++ b/srcs/ft_itoa.cpp @@ -0,0 +1,50 @@ + +#include + +static int eval_is_negative(int *n) +{ + if (*n < 0) + { + *n = *n * -1; + return (1); + } + return (0); +} + +static int eval_digit_nbr(int n) +{ + int digit_nbr; + + if (n == 0) + return (1); + digit_nbr = 0; + while (n != 0) + { + digit_nbr++; + n = n / 10; + } + return (digit_nbr); +} + +char *ft_itoa(int n) +{ + int i; + char *str; + int is_negative; + + if (n == -2147483648) + return (strdup("-2147483648")); + is_negative = eval_is_negative(&n); + i = eval_digit_nbr(n) + is_negative; + str = new char[i+1]; + if (is_negative) + str[0] = '-'; + str[i] = '\0'; + while (i > 0 + is_negative) + { + i--; + str[i] = (n % 10) + '0'; + n = n / 10; + } + return (str); +} diff --git a/website/index.html b/website/index.html new file mode 100644 index 0000000..21ae979 --- /dev/null +++ b/website/index.html @@ -0,0 +1,11 @@ + + + + 404 Not Found + + +

Le index (˘ ͜ʖ˘)

+
+

(˚3˚)

+ + \ No newline at end of file diff --git a/website/rfc2119_no_link.html b/website/rfc2119_no_link.html new file mode 100644 index 0000000..eec8fe5 --- /dev/null +++ b/website/rfc2119_no_link.html @@ -0,0 +1,300 @@ + + + + rfc2119 + + +
+This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference. +
+
+The following 'Verified' errata have been incorporated in this document: + EID 493, EID 494, EID 495, EID 496, EID 498, EID 499, EID 500, EID 5101 +
+ +
Network Working Group                                         S. Bradner
+Request for Comments: 2119                            Harvard University
+BCP: 14                                                       March 1997
+Category: Best Current Practice
+
+
+        Key words for use in RFCs to Indicate Requirement Levels
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   In many standards track documents several words are used to signify
+   the requirements in the specification.  These words are often
+   capitalized.  This document defines these words as they should be
+   interpreted in IETF documents.  Authors who follow these guidelines
+   should incorporate this phrase near the beginning of their document:
+
+             The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
+       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
+       RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
+       be interpreted as described in RFC 2119.
+
+
EID 499 (Verified) is as follows:
+
+Section: Abstract
+
+Original Text:
+
+       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+       "OPTIONAL" in this document are to be interpreted as described in
+       RFC 2119.
+
+Corrected Text:
+
+       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
+       RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
+       be interpreted as described in RFC 2119.
+
+Notes:
+The phrase "NOT RECOMMENDED" is missing from this sentence. +
+
+ Note that the force of these words is modified by the requirement + level of the document in which they are used. + +1. MUST This word, or the terms "REQUIRED" or "SHALL", means that the + definition is an absolute requirement of the specification. +
+
EID 493 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+   definition is an absolute prohibition of the specification.
+
+Corrected Text:
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", means that the
+   definition is an absolute prohibition of the specification.
+
+Notes:
+ +
+
+
EID 498 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+Corrected Text:
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED", means that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+Notes:
+ +
+
+
EID 500 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+Corrected Text:
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", means that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+Notes:
+ +
+
+
+
EID 495 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
+   definition is an absolute requirement of the specification.
+
+
+Corrected Text:
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", means that the
+   definition is an absolute requirement of the specification.
+
+Notes:
+ +
+
+2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the + definition is an absolute prohibition of the specification. + +3. SHOULD This word, or the adjective "RECOMMENDED", mean that there + may exist valid reasons in particular circumstances to ignore a + particular item, but the full implications must be understood and + carefully weighed before choosing a different course. + +4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that + there may exist valid reasons in particular circumstances when the + particular behavior is acceptable or even useful, but the full + implications should be understood and the case carefully weighed + before implementing any behavior described with this label. + +5. MAY This word, or the adjective "OPTIONAL", mean that an item is + truly optional. One vendor may choose to include the item because a + particular marketplace requires it or because the vendor feels that + it enhances the product while another vendor may omit the same item. + An implementation which does not include a particular option MUST be + prepared to interoperate with another implementation which does + include the option, though perhaps with reduced functionality. In the + same vein an implementation which does include a particular option + MUST be prepared to interoperate with another implementation which + does not include the option (except, of course, for the feature the + option provides). +
+
EID 5101 (Verified) is as follows:
+
+Section: 5
+
+Original Text:
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides.)
+
+Corrected Text:
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides).
+
+Notes:
+Full stop should appear outside the parentheses in the last sentence. +
+
+6. Guidance in the use of these Imperatives + + Imperatives of the type defined in this memo must be used with care + and sparingly. In particular, they MUST only be used where it is + actually required for interoperation or to limit behavior which has + potential for causing harm (e.g., limiting retransmissions) For +
+
EID 494 (Verified) is as follows:
+
+Section: 6
+
+Original Text:
+
+(e.g., limiting retransmisssions)
+
+Corrected Text:
+
+(e.g., limiting retransmissions)
+
+Notes:
+ +
+
+
EID 496 (Verified) is as follows:
+
+Section: 6
+
+Original Text:
+
+   In particular, they MUST only be used where it is actually required
+   for interoperation or to limit behavior which has potential for
+   causing harm (e.g., limiting retransmisssions)  For example, they
+   must not be used to try to impose a particular method on
+   implementors where the method is not required for interoperability.   
+
+Corrected Text:
+
+   In particular, they MUST only be used where it is actually required
+   for interoperation or to limit behavior which has potential for
+   causing harm (e.g., limiting retransmissions).  For example, they
+   must not be used to try to impose a particular method on
+   implementors where the method is not required for interoperability.
+
+Notes:
+ +
+
example, they must not be used to try to impose a particular method + on implementors where the method is not required for + interoperability. + +7. Security Considerations + + These terms are frequently used to specify behavior with security + implications. The effects on security of not implementing a MUST or + SHOULD, or doing something the specification says MUST NOT or SHOULD + NOT be done may be very subtle. Document authors should take the time + to elaborate the security implications of not following + recommendations or requirements as most implementors will not have + had the benefit of the experience and discussion that produced the + specification. + +8. Acknowledgments + + The definitions of these terms are an amalgam of definitions taken + from a number of RFCs. In addition, suggestions have been + incorporated from a number of people including Robert Ullmann, Thomas + Narten, Neal McBurnett, and Robert Elz. + +9. Author's Address + + Scott Bradner + Harvard University + 1350 Mass. Ave. + Cambridge, MA 02138 + + phone - +1 617 495 3864 + + email - sob@harvard.edu + + + + + + +
\ No newline at end of file diff --git a/website/rfc2119_sigabrt.html b/website/rfc2119_sigabrt.html new file mode 100644 index 0000000..18be9ac --- /dev/null +++ b/website/rfc2119_sigabrt.html @@ -0,0 +1,312 @@ + + + + + + + + + rfc2119 + + + + + + + + + +
+This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference. +
+
+The following 'Verified' errata have been incorporated in this document: + EID 493, EID 494, EID 495, EID 496, EID 498, EID 499, EID 500, EID 5101 +
+ +
Network Working Group                                         S. Bradner
+Request for Comments: 2119                            Harvard University
+BCP: 14                                                       March 1997
+Category: Best Current Practice
+
+
+        Key words for use in RFCs to Indicate Requirement Levels
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   In many standards track documents several words are used to signify
+   the requirements in the specification.  These words are often
+   capitalized.  This document defines these words as they should be
+   interpreted in IETF documents.  Authors who follow these guidelines
+   should incorporate this phrase near the beginning of their document:
+
+             The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
+       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
+       RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
+       be interpreted as described in RFC 2119.
+
+
EID 499 (Verified) is as follows:
+
+Section: Abstract
+
+Original Text:
+
+       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+       "OPTIONAL" in this document are to be interpreted as described in
+       RFC 2119.
+
+Corrected Text:
+
+       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
+       RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to 
+       be interpreted as described in RFC 2119.
+
+Notes:
+The phrase "NOT RECOMMENDED" is missing from this sentence. +
+
+ Note that the force of these words is modified by the requirement + level of the document in which they are used. + +1. MUST This word, or the terms "REQUIRED" or "SHALL", means that the + definition is an absolute requirement of the specification. +
+
EID 493 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+   definition is an absolute prohibition of the specification.
+
+Corrected Text:
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", means that the
+   definition is an absolute prohibition of the specification.
+
+Notes:
+ +
+
+
EID 498 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+Corrected Text:
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED", means that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+Notes:
+ +
+
+
EID 500 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+Corrected Text:
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", means that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+Notes:
+ +
+
+
+
EID 495 (Verified) is as follows:
+
+Section: 1
+
+Original Text:
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
+   definition is an absolute requirement of the specification.
+
+
+Corrected Text:
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", means that the
+   definition is an absolute requirement of the specification.
+
+Notes:
+ +
+
+2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the + definition is an absolute prohibition of the specification. + +3. SHOULD This word, or the adjective "RECOMMENDED", mean that there + may exist valid reasons in particular circumstances to ignore a + particular item, but the full implications must be understood and + carefully weighed before choosing a different course. + +4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that + there may exist valid reasons in particular circumstances when the + particular behavior is acceptable or even useful, but the full + implications should be understood and the case carefully weighed + before implementing any behavior described with this label. + +5. MAY This word, or the adjective "OPTIONAL", mean that an item is + truly optional. One vendor may choose to include the item because a + particular marketplace requires it or because the vendor feels that + it enhances the product while another vendor may omit the same item. + An implementation which does not include a particular option MUST be + prepared to interoperate with another implementation which does + include the option, though perhaps with reduced functionality. In the + same vein an implementation which does include a particular option + MUST be prepared to interoperate with another implementation which + does not include the option (except, of course, for the feature the + option provides). +
+
EID 5101 (Verified) is as follows:
+
+Section: 5
+
+Original Text:
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides.)
+
+Corrected Text:
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides).
+
+Notes:
+Full stop should appear outside the parentheses in the last sentence. +
+
+6. Guidance in the use of these Imperatives + + Imperatives of the type defined in this memo must be used with care + and sparingly. In particular, they MUST only be used where it is + actually required for interoperation or to limit behavior which has + potential for causing harm (e.g., limiting retransmissions) For +
+
EID 494 (Verified) is as follows:
+
+Section: 6
+
+Original Text:
+
+(e.g., limiting retransmisssions)
+
+Corrected Text:
+
+(e.g., limiting retransmissions)
+
+Notes:
+ +
+
+
EID 496 (Verified) is as follows:
+
+Section: 6
+
+Original Text:
+
+   In particular, they MUST only be used where it is actually required
+   for interoperation or to limit behavior which has potential for
+   causing harm (e.g., limiting retransmisssions)  For example, they
+   must not be used to try to impose a particular method on
+   implementors where the method is not required for interoperability.   
+
+Corrected Text:
+
+   In particular, they MUST only be used where it is actually required
+   for interoperation or to limit behavior which has potential for
+   causing harm (e.g., limiting retransmissions).  For example, they
+   must not be used to try to impose a particular method on
+   implementors where the method is not required for interoperability.
+
+Notes:
+ +
+
example, they must not be used to try to impose a particular method + on implementors where the method is not required for + interoperability. + +7. Security Considerations + + These terms are frequently used to specify behavior with security + implications. The effects on security of not implementing a MUST or + SHOULD, or doing something the specification says MUST NOT or SHOULD + NOT be done may be very subtle. Document authors should take the time + to elaborate the security implications of not following + recommendations or requirements as most implementors will not have + had the benefit of the experience and discussion that produced the + specification. + +8. Acknowledgments + + The definitions of these terms are an amalgam of definitions taken + from a number of RFCs. In addition, suggestions have been + incorporated from a number of people including Robert Ullmann, Thomas + Narten, Neal McBurnett, and Robert Elz. + +9. Author's Address + + Scott Bradner + Harvard University + 1350 Mass. Ave. + Cambridge, MA 02138 + + phone - +1 617 495 3864 + + email - sob@harvard.edu + + + + + + +
\ No newline at end of file