RAJAGIRI SCHOOL OF ENGINEERING & TECHNOLOGY

RAJAGIRI VALLEY, KAKKANAD, COCHIN 682 039

DIVISION OF COMPUTING SCIENCES

NETWORK COMPUTING MODULE V

Index
HTTP3 SMTP7 POP311 CGI13 SAMPLE PROGRAM.16

1. HTTP protocol- What is HTTP?

Computers on the World Wide Web use the HyperText Transfer Protocol to talk with each other. The HTTP provides a set of instructions for accurate information exchange. The communication between the client (your browser) and the server (a software located on a remote computer) involves requests sent by the client and responses from the server. Each client-server transaction, whether a request or a response, consists of three main parts

1. A response or request line 2. Header information 3. The body

A client connects to the server at port 80 (unless its been changed by the system administrator) and sends in its request. The request line from the client consists of a request method, the address of the file requested and the HTTP version number. GET /mypage.html HTTP/1.1 This request calls for mypage.html file using the GET HTTP method; the version of HTTP used is 1.1. After the request line comes the header data which consists of configuration information about the client and its document viewing preferences. The header is a series of lines, each of which contains a specific detail about the client. The header ends with a blank line. A header may look like this: ACCEPT: */* ACCEPT_LANGUAGE:en-us REFERER:http://www.simplygraphix.com/wedes.html USER_AGENT:Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) ... Most of the lines in the header are self-explanatory. The ACCEPT identifies the various kinds of files which the client can display. The USER_AGENT specifies the browser and gives details on its version number. The body of the request will contain data sent by the client via POST method. The server now responds. Again, the response consists of three parts. The response line contains information on the HTTP version number, a status code that indicates the result of the request from the client and a description of the status code in 'English'. HTTP/1.1 200 OK The HTTP version used is 1.1 and the status code 200 and 'OK' explain the result of the client's request.

The header from the server contains information about the server software and the document sent to the client. Date: Wed, 16 Aug 2000, 13:25:54 GMT Server: NCSA/1.5.2 Last-modified: Sat, 22 Jan 2000, 05:15:43 Content-type: text/html Content-length: 12443 The header is followed by a blank line that indicates the end of the header information. From the example above, the server sends an html document of size 12443 bytes as shown by the Content-type and Contentlength lines. The server line gives details about the server software. The HTTP is a stateless protocol, which means that the connection between the browser and the server is lost once the transaction ends.

HTTP Client Methods

Following are the commonly used HTTP methods GET POST HEAD PUT DELETE GET

1.1.1

It is used to retrieve HTML documents from the server. It is a part of the request line from the client and tells the server to pass a copy of the document back to the browser or run a CGI program. GET is also used to send user information from an HTML form. Through this, the data is sent as a part of the URL in 'name-value' pairs. Suppose your HTML form looks like this: <FORM NAME="myform" ACTION="cgi-bin/validate.cgi" METHOD="GET"> First Name: <INPUT TYPE="TEXT" NAME="fname" SIZE="20"><BR> Last Name: <INPUT TYPE="TEXT" NAME="lname" SIZE="20"> <BR> <INPUT TYPE="SUBMIT" VALUE="SUBMIT"> </FORM> This code will be displayed in the browser as:

First Name: Last Name:

SUBMIT

When you submit this form, the data is attached to the URL in name-value pairs. Each name-value pair demarcated by a '&'. Data is separated from the actual URL with a '?' sign. Thus after submission the address/location bar of the browser will show us as: www.sitename/cgi-bin/validate.cgi?fname=f1&lname=l1 You can also call CGI programs by supplying data with the URL in a HTML link like: <A HREF="http://www.somesite.com/cgi-program.cgi?name1 =value1&name2=value2>Link to somesite</A> which shows up as: Link to somesite If you move your mouse over this link, you will be able to see the URL and the attached data in the status bar of your browser.

1.1.2

POST

Data from the POST method is sent by the client as a part of the request body. The server receives this data and sends it to a CGI program along with other variables. The METHOD attribute inside the <FORM> tag will carry POST as its value. The big advantage in using POST over GET is that the data is not open to prying eyes. Also, via GET, you can transfer only a limited amount of data; POST exerts no such limitations. The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. 1.1.3 HEAD The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request should be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. 1.1.4 PUT The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity should be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource,

and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server must inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes should be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response should be given that reflects the nature of the problem.

1.1.5 DELETE The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method may be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server should not indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location. A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

2. SMTP
SMTP or Simple Mail Transfer Protocol is a way to transfer email reliably and efficiently. SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most cases verified to exist) and then the message text is transferred. SMTP is the language that mail servers use to communicate among themselves. Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. SMTP is used to send mail to the recipient's mailbox. The recipient may use various methods to access the emails in his mailbox. A couple of methods that are very popular are POP3 and IMAP. These protocols allow a user to access his messages stored on a remote mail server.

2.1 Basics of SMTP

When the user wants to send a message to someone, the sender-SMTP establishes a two-way transmission channel to a receiver-SMTP. SMTP commands are generated by the sender-SMTP and sent to the receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in response to the commands. In case a direct connection does not exist between the sender and the final destination, the message may be sent via one or more relay SMTP-servers. The relay SMTP-servers first act as receivers and then relays the message to the next SMTP. To be able to provide the relay capability the SMTP-server must be supplied with the name of the ultimate destination host as well as the destination mailbox name. Once the transmission channel is established, the SMTP-sender sends a MAIL command indicating the sender of the mail. If the SMTP-receiver can accept mail it responds with an OK reply. The SMTP-sender then sends a RCPT command identifying a recipient of the mail. If the SMTP-receiver can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The SMTP-sender and SMTP-receiver may negotiate several recipients. When the recipients have been negotiated the SMTP-sender sends the mail data, terminating with a special sequence. If the SMTP-receiver successfully processes the mail data it responds with an OK reply. The dialog is purposely lock-step, one-at-a-time.

2.2 SMTP Commands

Given below are some basic commands with their brief descriptions. The SMTP standard defines many more commands, most of which are optional to implement.

2.2.1 HELLO (HELO)

This is the first command that is sent when a connection is established. It is used to identify the senderSMTP to the receiver-SMTP. The argument field contains the host name of the sender-SMTP. HELO <SP> <domain> <CRLF>

<SP> stands for a space and <CRLF> stands for a combination of Carriage Return and Linefeed. The receiver-SMTP identifies itself to the sender-SMTP in the connection greeting reply, and in the response to this command.

2.2.1 MAIL (MAIL)

There are three steps to SMTP mail transactions. The transaction is started with a MAIL command which gives the sender identification. A series of one or more RCPT commands follows giving the receiver information. Then a DATA command gives the mail data. And finally, the end of mail data indicator confirms the transaction. The first step in the procedure is the MAIL command. The <reverse-path> contains the source mailbox. MAIL <SP> FROM:<reverse-path> <CRLF> If accepted, the receiver-SMTP returns a 250 OK reply. The <reverse-path> can contain more than just a mailbox. The <reverse-path> is a reverse source routing list of hosts and source mailbox. The first host in the <reverse-path> should be the host sending this command.

2.2.2 RECIPIENT (RCPT)

This command gives a forward-path identifying one recipient. If accepted, the receiver-SMTP returns a 250 OK reply, and stores the forward-path. If the recipient is unknown the receiver-SMTP returns a 550 Failure reply. This second step of the procedure can be repeated any number of times. RCPT <SP> TO:<forward-path> <CRLF> The <forward-path> can contain more than just a mailbox. The <forward-path> is a source routing list of hosts and the destination mailbox. The first host in the <forward-path> should be the host receiving this command.

2.2.3 DATA (DATA)

The third step in the procedure is the DATA command. DATA <CRLF> If accepted, the receiver-SMTP returns a 354 Intermediate reply and considers all succeeding lines to be the message text. When the end of text is received and stored the SMTP-receiver sends a 250 OK reply. Since the mail data is sent on the transmission channel the end of the mail data must be indicated so that the command and reply dialog can be resumed. SMTP indicates the end of the mail data by sending a line containing only a period. The mail data includes the memo header items such as Date, Subject, To, Cc, From etc

2.2.4 VERIFY (VRFY)

This command asks the receiver to confirm that the argument identifies a user. If it is a user name, the full name of the user (if known) and the fully specified mailbox are returned. VRFY <SP> <user name> <CRLF>

2.2.5 RESET (RSET)

This command specifies that the current mail transaction is to be aborted. The receiver must send an OK reply. RSET <CRLF>

2.2.6 NOOP (NOOP) 8

This command does not affect any parameters or previously entered commands. It specifies no action other than that the receiver send an OK reply. NOOP <CRLF>

2.2.7 QUIT (QUIT)

This command specifies that the receiver must send an OK reply, and then close the transmission channel. QUIT <CRLF> In order to make SMTP workable, the following minimum implementation is required for all receivers: MAIL RCPT DATA RSET NOOP QUIT

2.3 Relaying of Messages

The sender specifies the forward-path of the recipient while sending the mail. This forward-path includes not only the address of the recipient but also the route that is to be taken to reach there. This information is useful if there is not direct link between the sender and the recipient. The forward-path may be a source route of the form "@ONE,@TWO:XYZ@THREE", where ONE, TWO, and THREE are hosts. ONE is the name of the host who is receiving this command. ONE will forward this message to host TWO. TWO will in turn forward the message to THREE which is the host on which the user XYZ has a mailbox. Conceptually the elements of the forward-path are moved to the reverse-path as the message is relayed from one server-SMTP to another. The reverse-path is a reverse source route, (i.e., a source route from the current location of the message to the originator of the message). The reverse-path is used in case a reply has to be sent to the sender. If a server-SMTP has accepted the task of relaying the mail and later finds that the forward-path is incorrect or that the mail cannot be delivered for whatever reason, then it must construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path).

2.4 Time Stamps and Return Path in Message Header

When the receiver-SMTP accepts a message either for relaying or for final delivery it inserts at the beginning of the mail data a time stamp line. The time stamp line indicates the identity of the host that sent the message, and the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines. When the receiver-SMTP makes the "final delivery" of a message it inserts at the beginning of the mail data a return path line. The return path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message leaves the SMTP world.

2.5 Mail Exchangers

A mail exchanger is the host name of a smtp server that is a gateway for all mails entering a domain. In other words, it is a server that takes care of all mails sent to addresses within that domain. When an smtp server needs to send an email to a address, say abc@xyz.com it queries the DNS for the mail exchangers for xyz.com. The sender can then connect to the mail exchanger and deliver the message. It is possible for a single domain to have multiple mail exchangers for reliability. Querying the DNS for Mail Exchangers for hotmail.com yielded the following results: Mx2@hotmail.com mx3@hotmail.com mx1@hotmail.com Note that mail exchangers will typically only accept mails addressed to users within that domain. SMTP servers provided by your ISP or local system administrator will accept mails for any destination and then relay it to the appropriate mail exchanger.

10

3. POP3
It is not possible for all computers to be continuously connected to the internet. These computers cannot run their own SMTP servers to manage incoming and outgoing mails because the server needs to be running and connected to the internet all the time. Imagine a situation where someone can only send mail to you while you are logged onto the Internet. This situation is certainly unacceptable and ways have been developed to remedy it. One solution is to maintain a mailbox on a machine (the server) which is continuously connected to the Internet. This machine would accept all mails on our behalf. We (the clients) could periodically connect to this server via the Internet to view or download the mails in our mailbox using a agreed upon protocol. Some of the ways to access ones mailbox are listed below: POP3 or the Post Office Protocol - Version 3 is one simple protocol that allows users to access their mailbox on a remote machine. POP3 does not provide "extensive manipulation operations of mail on the server". It was designed so that clients could download the mails from the servers which would then delete them. IMAP4 or the Internet Message Access Protocol - Version 4 was designed as a more powerful way of accessing and manipulating mail messages on a server. It was designed with the idea that a user would like to keep all his mails on the server, which would then be accessible from any client anywhere in the world. IMAP4 includes operations for "creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof."

3.1 How does POP3 work?

Initially, the server host starts the POP3 service by listening on TCP port 110. When a client host wishes to make use of the service, it establishes a TCP connection with the server host. When the connection is established, the POP3 server sends a greeting. The client and POP3 server then exchange commands and responses (respectively) until the connection is closed or aborted. Commands in the POP3 consist of a keyword, possibly followed by one or more arguments. All commands are terminated by a CRLF (Carriage Return and Line Feed) pair. Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair. There are currently two status indicators: positive ("+OK") and negative ("-ERR"). Responses to certain commands are multi-line. In these cases, lines sent are terminated by a CRLF pair. When all lines of the response have been sent, a final line is sent, consisting of a "." and a CRLF pair. A server responds to an unrecognized, unimplemented, or syntactically invalid command with a negative status indicator.

3.2 Commands in POP3 11

A list of valid commands is listed below. Note that the implementation of some commands is optional. Some of the arguments to a command may also be optional, such arguments are enclosed in square brackets. 3.2.1 USER name To authenticate using the USER and PASS command combination, the client must first issue the USER command. If the POP3 server responds with a positive status indicator ("+OK"), then the client may issue either the PASS command to complete the authentication.

3.2.2 PASS string When the client issues the PASS command, the POP3 server uses the argument pair from the USER and PASS commands to determine if the client should be given access to the appropriate mailbox. The password is sent in the clear on the network so this method is not good from a security viewpoint. 3.2.3 APOP name digest (Optional) The APOP command provides an alternate method of authentication, which does not involve sending a password in the clear over the network. A POP3 server which implements the APOP command will include a timestamp in its banner greeting. The POP3 client makes note of this timestamp, and then issues the APOP command. The `name' parameter has identical semantics to the `name' parameter of the USER command. The `digest' parameter is calculated by applying the MD5 algorithm to a string consisting of the timestamp followed by the password. 3.2.4 STAT The response consists of the number of messages in the mailbox and the size of the mailbox in octets (bytes). 3.2.5 LIST [msg] The response consists of the message-number of the message and the exact size of the message in octets. If the msg argument (optional) was given then the information is listed for that particular message number, else a multi-line listing containing information for all messages in the mailbox is returned. 3.2.6 RETR msg The POP3 server sends the entire message corresponding to the given message-number. 3.2.7 DELE msg The POP3 server marks the message as deleted. The POP3 server does not actually delete the message until the user gives the QUIT command. 3.2.8 NOOP The POP3 server does nothing, it merely replies with a positive response. 3.2.9 RSET If any messages have been marked as deleted by the POP3 server, they are unmarked. 3.2.10 QUIT The POP3 server removes all messages marked as deleted from the mailbox. The server then closes the TCP connection.

12

4. CGI 4.1 Overview

The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information.

Figure
Since a CGI program is executable, it is basically the equivalent of letting the world run a program on your system, which isn't the safest thing to do. Therefore, there are some security precautions that need to be implemented when it comes to using CGI programs. Probably the one that will affect the typical Web user the most is the fact that CGI programs need to reside in a special directory, so that the Web server knows to execute the program rather than just display it to the browser. This directory is usually under direct control of the webmaster, prohibiting the average user from creating CGI programs. The sequence of events happening through CGI scripting is listed as follows: A client makes an HTTP request by means of a URL. This URL could be typed into the location window of a browser, be a hyperlink or be specified in the Action attribute of an HTML form tag. From the URL the web server determines that is should activate the gateway program listed in the URL and send any parameters via the URL to that program. The gateway program processes the information and returns HTML text to the web server. The server in turn adds a MIME header and returns the HTML text to the browser. The web browser displays the document received from the web browser

4.2 How information is transferred from the web browser to a CGI program?
There are two methods, which can be used to access forms. These methods are GET and POST. Depending on which method used, we will receive the encoded results of the form in a different way. The GET method If the form has METHOD="GET" in its FORM tag, the CGI program will receive the encoded form input in the environment variable QUERY_STRING. The value of all the fields are concatenated and passed to the URL specified in the action attribute of the form tag. The basic procedure is to split the data by the ampersands. Each fields values appear in the name-value format. Any character with a special meaning in the forms data is encoded using a special encoding scheme known as URL encoding.

13

The POST method If the form has METHOD="POST" in its FORM tag, the CGI program will receive the encoded form input on stdin. The server will NOT send an EOF on the end of the data; instead you should use the environment variable CONTENT_LENGTH to determine how much data should be read from stdin.

4.3 How to get information from the server?

Each time a client requests the URL corresponding to the CGI program, the server will execute it in realtime. The web server must be configure to recognize an HTTP request for a CGI program. It involves informing the web server of the directory where the CGI programs reside. A directory called /cgi-bin is where all of the CGI programs currently reside. CGI uses environment variables to send CGI program its parameters. The two major environment variables we will use for this purpose are: REQUEST_METHOD This environment variable indicates the data submission method-whether it is GET or POST QUERY_STRING If the method is GET, QUERY_STRING is defined as anything which follows the first ? in the URL. This string will usually be an information query and is considered as the input.. This string is encoded in the standard URL format of changing spaces to +, and encoding special characters with %xx hexadecimal encoding. PATH_INFO CGI allows for extra information to be embedded in the URL for your gateway which can be used to transmit extra context-specific information to the scripts. This information is usually made available as "extra" information after the path of your gateway in the URL. This information is not encoded by the server in any way. CONTENT_LENGTH If the method is POST, get the length of the input in number of bytes from the CONTENT_LENGTH environment variable. Then read that many bytes from the standard input. 4.4 How a CGI program returns back to the client? Regardless of how the web server passes information to the CGI program, the CGI program always-return information to the server by writing to the standard output. Standard output is the default device, which a program sends its output to. In the case of a CGI program, the standard output device is the web server software running in the computers memory. The web server then processes that output and sends the data back to the browser that had originally submitted the request. CGI programs can return a myriad of document types. They can send back an image to the client, and HTML document, a plaintext document, or perhaps even an audio clip. They can also return references to

14

other documents. The client must know what kind of document you're sending it so it can present it accordingly. In order for the client to know this, your CGI program must tell the server what type of document it is returning. In order to tell the server what kind of document you are sending back, whether it be a full document or a reference to one, CGI requires you to place a short header on your output. This header is ASCII text, consisting of lines separated by either linefeeds or carriage returns (or both) followed by a single blank line. The output body then follows in whatever native format.

A full document with a corresponding MIME type In this case, you must tell the server what kind of document you will be outputting via a MIME type. Common MIME types are things such as text/html for HTML, and text/plain for straight ASCII text. For example, to send back HTML to the client, your output should read: Content-type: text/html <HTML><HEAD> <TITLE>output of HTML from CGI script</TITLE> </HEAD><BODY> <H1>Sample output</H1> What do you think of <STRONG>this?</STRONG> </BODY></HTML>

A reference to another document Instead of outputting the document, you can just tell the browser where to get the new one, or have the server automatically output the new one for you. For example, say you want to reference a file on your Gopher server. In this case, you should know the full URL of what you want to reference and output something like: Content-type: text/html Location: gopher://httprules.foobar.org/0 <HTML><HEAD> <TITLE>Sorry...it moved</TITLE> </HEAD><BODY> <H1>Go to gopher instead</H1> Now available at <A HREF="gopher://httprules.foobar.org/0">a new location</A> on our gopher server. </BODY></HTML>

15

1. SAMPLE PROGRAM
/* This program checks a username and password against a list in the file (passw.fle in server's root directory) using the format =username&=password. If it is the same, opens index.htm in the directory ok under the server's root directory. If not displays "INVALID ENTRY" and logs the username, password and time into data.txt in the server's root directory. The file passw.fle must be created in the root directory of your server For example =xyz&=abc123. This will allow xyz to use abc123 as his password.The file data.txt will be created when the first invalid entry is entered. */ /* THE HTML FORM FILE looks like below

Enter your username and password.

Username

Password

Send

*/ // #include <stdio.h> #include <stdlib.h> #include <fstream.h> 16 PASSWORD.C

#include <fcntl.h> #include <conio.h> #include <time.h> #pragma #pragma #pragma #define #define #define hdrstop warn -aus warn -sig strsize 42 EXTRA 5 datafile "../data.txt"

// FUNCTIONS // FUNCTION NoEntre() void NoEntre(char *paswd) { char str[] = " INVALID PASSWORD! "; char str2[] = "UNABLE TO OPEN DATA FILE."; time_t t; FILE *f; //will enter every password entry if it is incorrect. f = fopen(datafile, "a"); // print the CGI response header printf(<html>\n> printf(<head><title>CGI Output</title></head>\n); printf(<body>); //if the file's directory does not exist (the file can not //be created). if(f == NULL) printf("<p><h1>%s </h1></p>\n", str2) ; /*print INVALID PASSWORD! and put the invalid password and time in data.txt */ else { printf("<p><h1>%s </h1></p>\n", str) ; fputs(paswd, f); time(&t); fputs(" ",f); fputs(ctime(&t), f); } printf("</body>\n") ; printf("</html>\n") ; exit(0) ; fclose(f); 17

} // FUNCTION unencode() //Converts the environmental space string to multiple strings and takes out the &, +, =, and %. And adds carriage returns and spaces where needed.// void unencode(char *src, char *last, char *dest) { for(; src != last; src++, dest++) if(*src == '+') *dest = ' '; else if(*src == '&') *dest = '\n'; else if(*src == '&') *dest = ' '; else if(*src == '=') *dest = ' '; else if(*src == '%') { int code; if(sscanf(src+1, "%2x", &code) != 1) code ='?'; *dest = code; src +=2; } else *dest = *src; *dest = '\n'; *++dest = '\0'; } // FUNCTION inputfile() int inputfile(char *pasw, int lensize, char *usern) { //puts the stdin (environment variable) into username. fgets(usern, lensize+1, stdin); unencode(usern, usern+lensize, pasw); return 1; } 18

// FUNCTION readpassw() //checks the password and username against the password and username in the file (passw.fle). int readpasw(char *name) { char buff[60]; char string[60], string2[60]; int d=0; //open file for read ifstream fname("../passw.fle", ios::in || O_RDONLY); if(!fname) return 0; d = strlen(name); string2[0] = '\0'; strncat(string2, name, d); while(fname.getline(buff, sizeof(buff))) { strncpy(string, buff, sizeof(buff)); int e = strcmp(string, string2); if(e != 0) { string[0] = '\0'; buff[0] = '\0'; } else { fname.close(); return 1; } } fname.close(); return 2; } // FUNCTION readfile() //opens ok/index.html void readfile(void) { char filename[] = "../ok/index.htm"; char buffer[80]; 19

FILE *fname; //open file for read if((fname = fopen(filename, "r")) == NULL) { printf("UNABLE TO OPEN //OK//INDEX.HTM"); exit(1); ` } while(!feof(fname)) { fgets(buffer, sizeof(buffer), fname); printf("%s\n", buffer); } fclose(fname); }

// MAIN PROGRAM void main(void) { char *lenstr; //pointer to html string. char username[strsize + 1], password[strsize + 1]; username[0] = '\0'; password[0] = '\0'; long len; //holds the length of the html string. //Find an environment variable and assigns it to the pointer lenstr. lenstr = getenv("CONTENT_LENGTH"); //get the length of the string, if length too little or big runs NoEntre(). if(lenstr == NULL || sscanf(lenstr,"%ld",&len)!=1 || len > (strsize - 1)) NoEntre(username); else { int p = inputfile(password, len, username); if(p == 0) exit(1); 20

int j = readpasw(username); if(j == 0) { printf("\nUNABLE TO OPEN PASSWORD FILE."); exit(1); } if(j == 1) { readfile(); } if(j == 2) { NoEntre(username); } }

21