IMPORTANT: This
project will be done individually.
GET <sp> <Document Requested> <sp> HTTP/1.0 <crlf>where :
{<Other Header Information> <crlf>}*
<crlf>
The function of a HTTP server is to parse the above request from a client, identify the file being requested and send the file across to the client. However, before sending the actual document, the HTTP server must send a response header to the client. The following shows a typical response from a HTTP server when the requested file is found on the server:
HTTP/1.1 <sp> 200 <sp> Document <sp> follows <crlf>
Server: <sp> <Server-Type> <crlf>
Content-type: <sp> <Document-Type> <crlf>
{<Other Header Information> <crlf>}*
<crlf>
<Document Data>
where :
HTTP/1.1 <sp> 404 File Not Found <crlf>where :
Server: <sp> <Server-Type> <crlf>
Content-type: <sp> <Document-Type> <crlf>
<crlf>
<Error Message>
git config --global user.name $USER git config --global user.email "$USER@purdue.edu" git clone ssh://$USER@data.cs.purdue.edu/homes/cs252/sourcecontrol/work/$USER/lab5-src.gitWhen you have done a group of modifications and you have reached a milestone, then it is time to push your changes. Type:
git commit -am "Type here a description of the changes you have made."
git push
If you want to see a list of all the changes you have done. Type
git logSee the git tutorial described above. It is important that you commit/push your changes at least twice a week. Then build the server by typing make. Run the server by typing daytime-server without arguments to get information about how to use the server. Run the server and read the sources to see how it is implemented. Some of the functionality of the HTTP server that you will implement is already available in this server.
The server that you will implement at this stage will not be concurrent, i.e., it will not serve more than one client at a time (it queues the remaining requests while processing each request). You can base your implementation on the example server given in [1] . The server should work as specified in the overview above. Make a copy of the daytime server and name it "myhttpd.cpp". Add the rules to the Makefile to build it.
- Open Passive Socket.
- Do Forever
- Accept new TCP connection
- Read request from TCP connection and parse it.
- Frame the appropriate response header depending on whether the URL requested is found on the server or not.
- Write the response header to TCP connection.
- Write requested document (if found) to TCP connection.
- Close TCP connection
POINTS WILL BE DEDUCTED FOR INCORRECT MAKEFILE.
If you want a review of threads see Introduction to Threads.
The format of the command should be:
myhttpd [-f|-t|-p] [<port>]
If no flags are passed the server will be an iterative server like in
the Basic Server section. If <port> is not passed, you will
choose your own default port number. Make sure it is larger than 1024
and less than
65536.
MAKE SURE THAT THERE IS A HELP FUNCTION AND YOUR CODE IS INDENTED AND EASY TO READ (there will be points for this).
Also implement sorting by name, size, and modification time.
MAKE SURE THAT THERE IS A HELP FUNCTION AND YOUR CODE IS INDENTED AND EASY TO READ (there will be points for this)
For purposes of pacing, you should have this stage completed by Monday, April 6th, at 11:59pm. Write your program in a directory called lab5-src. Make sure that your server can be built by typing "make" in one of the lab machines. You will turn in this part electronically by typing the following command:
git commit -am "Lab5 Part 1 submission"
git push
5. Verify that you have turned in your files correctly by typing:
git status
GET <sp> /cgi-bin/<script>?{<var>=<val>&}*{<var>=<val>}<sp> HTTP/1.0 <crlf>the child process that is processing the request will call execv on the program in cgi-bin/<script>.
{<Other Header Information> <crlf>}*
<crlf>
There are two ways the variable-value pairs in {<var>=<val>&}*{<var>=<val>} are passed to the cgi-bin script: the GET method and the POST method. You will implement the GET method and for extra points you may implement the POST method.
In the GET method the string of variables {<var>=<val>&}*{<var>=<val>} is passed to the <script> program as an environment variable QUERY_STRING. It is up to the <script> program to decode this string. Also if this string of variables exists, you should set the REQUEST_METHOD environment variable to "GET". The output of <script> will be sent back to the client.
In summary your cgi-bin implementation should:
HTTP/1.1 200 Document follows crlf Server: Server-Type crlf
The script or cgi program will print the content type and will generate an output that is sent to the browser.
For more information on how cgi-bin works see the Apache documentation.
Note. You will need to recompile the cgi-bin modules in lab5-src/http-root-dir/cgi-src
cd lab5-src/http-root-dir/cgi-src grep getline * ----- Replace all the occurrences of "getline" to "mygetline" make clean make
For example, a request of the form:
http://localhost:8080/cgi-bin/hello.so?a=bwill make your server load the loadable module hello.so into memory and then call the function httprun() in this module with ssock and querystring as parameters. It is up to the module to write the response to ssock. Your server needs to keep track of what modules have been already loaded to not call dlopen() multiple times for the same module.
There is an example of how to use loadable modules in your lab5-src directory included in your git repository.
Also, in this part, you will need to rewrite the script http-root-dir/cgi-src/jj.c
into a loadable module and name it jj-mod.c.
Hint: Use the call fdopen to be able to use buffered and formatter
calls such as fprintf() to write to the slave socket. For
example,
in the top of httprun() in jj-mod.c call
FILE * fssock = fdopen( ssock, "r+");
Then you can use the following to print to the slave socket:
fprintf (fssock, "tomato, and mayo.<P>%c",LF);
Remember to close ffsock at the end of httprun().
fclose( fssock);
MAKE SURE THAT THERE IS A HELP FUNCTION AND YOUR CODE IS INDENTED
AND EASY TO READ (there will be points for this)
You will implement a page http://localhost:<port>/stats
with the following:
You may notice that the logging features become somewhat complicated when multiple processes are involved (such as with the -f option). How do you coordinate writes to the log file between these processes? Successfully creating a logging feature that cleanly logs to the same file from multiple processes will earn 5 extra credit points.
Hint: look up the mmap() function manpage.
3. Write a short README file that includes:
a) Features in the
handout
that you have implemented
b) Features in the handout
that you have not implemented
c) Extra features
Include this file in your server's directory lab5-src/
4. You still need to turnin your project electronically.
Write your program in a directory called lab5-src. Make sure that your server can be built by typing "make" in one of the lab machines.
IMPORTANT: Do not include the http-root-dir in your submitted files.
REMEMBER: You have to do a "git add" on any new source files that you have created and added to your lab in order for git to know about them!
You will turn in this part electronically by typing the following command from a lab machine:
git add <any previously unversioned files>
git commit -am "Lab5 Part 1 submission"
git push
5. Verify that you have turned in your files correctly by typing:
git status
The deadline for electronic turnin is Monday
April 13th at 11:59pm. The presentations will take place the following week
during your PSO.
The grade will be based on how well your server works, the organization of your code, as well as the extra features you include to your project.
Reading and References