Recent Changes - Search:

Home Page



Other tools


edit SideBar

Nweb

Site.Nweb History

Hide minor edits - Show changes to output

August 10, 2016, at 03:43 PM by 127.0.0.1 -
Changed line 60 from:
Run as follows:
to:
Run as follows as the root user:
Changed lines 63-64 from:
* For regular users us a very large number like 8080 or 8181
to:
** '''./nweb 80 /webpages'''
* If all ready in use try the ports for regular users use a very large number like 8080 or 8181
Added lines 67-69:
* If you must run this as a regular user (not recommended) you need to change the code
** Change chroot to chdir
** There is reduced security running as a regular user because chroot limits the accessable files to just that single directory.
August 10, 2016, at 02:34 PM by 127.0.0.1 -
Added lines 57-58:

Note: very new compiler versions in 2016 spew out eight "Warnings" about not checking the return value of the write() system call even though the code explicitly tells the compile we know we want to do that. You can safely, ignore those warnings.
July 28, 2016, at 04:57 PM by 127.0.0.1 -
Changed line 24 from:
- Read the README online [[nmon24README]] ||
to:
- Read the README online [[nmon24_README]] ||
July 28, 2016, at 04:56 PM by 127.0.0.1 -
Changed lines 22-24 from:
website for testing purposes only ||
to:
website for testing purposes only \
And the README for changes and versions \\
- Read the README online [[nmon24README]] ||
July 26, 2016, at 08:00 AM by 127.0.0.1 -
Added lines 55-61:

Run as follows:
* ./nweb <port> <directory>
* For the root user the classic port number is 80
* For regular users us a very large number like 8080 or 8181
* The directory is the place you have put the webserver files like .html, .htm and .jpg and .gif files.
* Problems? Check the nweb.log file.
July 26, 2016, at 07:47 AM by 127.0.0.1 -
Added lines 378-379:

The code is in the nweb_extra.zip downloadable file but you can see it online here: [[client.c]]
July 25, 2016, at 08:29 PM by 127.0.0.1 -
Changed lines 402-405 from:



!Hands-on - setting and using x!
to:
#Once the GET request is send this client program just reads the socket until it closes and dumps the contents on the screen - don't ask for a binary file or it can muck up your terminal session.
It then exits.

!Hands-on - setting and using nweb!
July 25, 2016, at 08:24 PM by 127.0.0.1 -
Changed lines 376-405 from:
!Hands-on - settting and using nweb!
to:
!nweb client - probably the worst but working browser in the world!
We have focused on the webserver side but what does a browser do to request a file from the webserver.

In just 50 lines of C code we look at the basic system call it needs to make to connect to the socket of the webserver, sent the GET operation request and gt the file contents back.

To make this really simple we have hard coded most things.
If you want to use a different port, website or GET a different file you will need to change these lines of code and recompile before running the client again.

[@
#define PORT 8181 /* Port number as an integer - web server default is 80 */
#define IP_ADDRESS "192.168.0.8" /* IP Address as a string */
char *command = "GET /index.html HTTP/1.0 \r\n\r\n" ; /* Note: spaces are delimiters and VERY important */
@]

Ignoring the pexit() function which is used to report an error and exit.

In the main function we use the socket() function call to create a socket like we did in the webserver.
But next we do something vert different to the webserver.
# We use the connect() function to request to join our client's socket to an existing socket on the webserver's vis the IP Address and the webserver's port number.
# This is the clever bit - the connect() reaches over the network to the webserver and to the port number and to the inetd process on the webserver.
# The inetd process recognises the event and passes it to the program that made an accept() function.
# This sets up the by-directional streams of the two inter-connected network sockets so the two programs can communicate.
# If the connect() is successful the client can make the GET request before which we send "Send-bytes=" and the size in bytes of the GET request string. the size allows the webserver to prepare a buffer and read the request in one read() - GET might include lots of cookie information but PUT requests might send lots of data but so be huge.
# Be careful in this request format.
# nweb is not too fussy in the format.
# A regular webserver is not forgiving and will expect the "HTTP", version, spaces, carriage return and line feed characters exactly as above or will assume the browser is duff and ignore ill formed requests. But they will not have problems if the browser does not send lots of the other "stuff" like operating system, browser name/version and cookies as they are optional.



!Hands-on - setting and using x!
July 25, 2016, at 07:35 PM by 127.0.0.1 -
Changed line 10 from:
Details of running nweb are at the bottom.\\
to:
Details of running nweb are at the bottom of this page.\\
July 25, 2016, at 07:34 PM by 127.0.0.1 -
Added lines 10-11:
Details of running nweb are at the bottom.\\
\\
Changed lines 361-362 from:
Then there is the GET for the favicon.ico
to:
Then there is the GET for the favicon.ico (I hope you can workout the various parts of the GET and response SENT
[@
Changed lines 374-376 from:


!Hands-on!
to:
@]

!Hands-on - settting and using nweb!
July 25, 2016, at 07:32 PM by 127.0.0.1 -
Changed lines 419-420 from:
$ cat sample_index.html
to:

[@
Changed lines 454-456 from:
Assuming the user of the directory is call debbie
to:
Assuming the user of the directory is call debbie.
Note: high port numbers can be used by regular users - only root can use port numbers in a lower number - this number range is dependant on your operating system.
Changed lines 473-474 from:
'''If you have root access then you can run nweb with the classic default port number of 80.
to:

'''If you have root access then you can run nweb with the classic default port number of 80'''
July 25, 2016, at 07:29 PM by 127.0.0.1 -
Changed line 266 from:
To understand a little about this HTTP we are going to look at the nweb log file nweb.log as it records the incoming message and what it sent:
to:
To understand a little about this HTTP we are going to look at the nweb log file nweb.log as it records the incoming message and what it sent (but not the contents of the file):
Changed lines 268-269 from:
INFO: request:%blue%GET /temperature.html%% %red%HTTP/1.1%% %green%
**Host:pi.aixncc.uk.ibm.com%%**Connection: keep-alive
to:
INFO: request:GET /temperature.html HTTP/1.1
**Host:pi.aixncc.uk.ibm.com**Connection: keep-alive
Changed line 276 from:
INFO: SEND:temperature.html:22
to:
INFO: SEND:temperature.html
Changed lines 312-314 from:
:21
INFO: request:%blue%GET /temperature.html%% %red%HTTP/1.1%% %green%**Host:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent:
to:

INFO: request:%blue%'''GET /temperature.html'''%% %red%'''HTTP/1.1'''%% %green%'''**Host:pi.aixncc.uk.ibm.com'''%%
**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent:
Changed line 318 from:
INFO: SEND:temperature.html:22
to:
INFO: SEND:temperature.html
Changed lines 331-333 from:
* %green%GREEN - this is the machine the browser is communicating to - in complicated configurations the request \\
might be handled by a different machine.%%
* BLACK - this is other stuff that the browser sends as it might help the webserver decide what to send back.
to:
* %green%GREEN - this is the host machine the browser is communicating with - in complicated configurations the request \\
might be handled by a different set of machines. This is ignored in nweb.%%
* BLACK - this is all the other stuff that the browser sends as it might help the webserver decide what to send back.
Changed lines 335-343 from:
** The Operating system NT 6.1 - also known as Windows 7!,
** The browser is Chrome but faking being other browsers if necessary,
** Connection: keep-alive is about handling many requests over the one socket - nweb does NOT do this as its \\
complicated but would be more efficient in CPU terms
** There is also en-GB showing a preference for proper English as opposed to American :-)
* I removed all my browser cookies before this web request - otherwise there could be KB's if cookies attached \\
to the end of the request.

The:
to:
** The Operating system the browser is running on - here "Windows NT 6.1" - also known as Windows 7!,
** The browser is "Chrome" but can fake being other browsers at particular version numbers, if necessary,
** The "Connection: keep-alive" is about handling many requests over the one socket - nweb does NOT do this as its \\
complicated but would be more efficient in CPU time setting up sockets for each request
** There is also "en-GB" showing a preference for proper English as opposed to American :-)
* I removed all my browser stored cookies before this web request - otherwise there could be large block of cookies adding KB's to the end of the GET request.

The response section:
Changed lines 344-351 from:
Is the sending of the data but that has a HTTP header send first and this is
the lines following
Server: nweb/24.0
Content-Length: 389934
Connection: close
Content-Type: text/html

to:
This is the sending of the data (not including the contents of the file) but that has a HTTP header send first and this is the lines following
%blue'''Server: nweb/24.0'''%%
%red%'''Content-Length: 389934'''%%
%magenta%'''Connection: close'''%%
%green%'''Content-Type: text/html'''%%

Changed lines 352-353 from:
Server is the name of the server and its version
Content-Length is as you might guess the length of the file - this allows the browser to get some buffer
to:
* Server: nweb/24'''%% is the name of the server and its version
* %red%'''Content-Length'''%% is as you might guess the length of the file - this allows the browser to get some buffer
Changed lines 355-356 from:
Connection: close is a waning that nweb will close the connection rather than use keep-alive.
Content-Type: lets the browser know the format of the data.
to:
* %magenta%'''Connection: close'''%% is a waning that nweb will close the connection rather than use keep-alive.
* %green%'''Content-Type:'''%% lets the browser know the format of the data.
Changed lines 359-362 from:



:22
to:
Then there is the GET for the favicon.ico
Changed line 365 from:
en-GB,en-US;q=0.8,en;q=0.6****:23
to:
en-GB,en-US;q=0.8,en;q=0.6****
Changed lines 374-375 from:
!hands-on!
Example use on nweb:
to:
!Hands-on!

Assuming a machine with hostname and domain of nigel.acme.com and a user called debbie

'''Compiling'''
It is just a single 200 line C program and assuming your C compiler is installed and called cc:
* cc -O3 -nweb25.c -o nweb
** Note: -O3 set the compiler to optimise the code for higher performance.

'''Setting up a directory for the tiny sample webpage supplied in nweb_extra.zip
Changed lines 386-389 from:
$ mkdir /home/nag/webpages
$ cd /home/nag/webpages
$ cp /tmp/nweb.tar .
$ tar xvf nweb.tar
to:
$ mkdir /home/debbie/webpages
$ cd /home/debbie/webpages
$ cp /tmp/nweb_extra.zip .
$ unzip nweb_extra.zip
Changed lines 391-398 from:
nweb.c
nweb_aix
nweb_linux_intel
sample_index.html
nweb.gif


$ cat sample_index.html
to:
index.html
nigel.jpg
favicon.ico
client.c
@]

Make sure these files have read permission.
* client.c is an example code of how a browser fetches the files from the webserver.

'''The example index.html file has this contents''':

[@
Added lines 404-420:
<TITLE>nweb
</TITLE>
<BODY BGCOLOR="lightblue">
<H1>nweb Test page</H1>
<IMG SRC="nigel.jpg">
<p>
Not pretty but it should prove that nweb works :-)
<p>
Feedback is welcome to Nigel Griffiths nag@uk.ibm.com
</table>
</BODY>
</HTML>
@]

'''A more complex webpage index.html file'''
$ cat sample_index.html
<HTML>
Added lines 432-435:
<OL>
<LI>This is an ordered list.
<LI>Which means each line is numbered.
</OL>
Changed lines 438-446 from:
<B>The End</B>
to:

<P> start a new paragraph

A line break<BR>forcing a new line

<A HREF="\otherfile.html">A further website page, if you click on the text here </a>


<B>The End in bold</B>
Deleted lines 448-455:

$ cp sample_index.html index.html
$ chmod ugo+x nweb
$ chmod ugo+r *.html nweb.gif
$ nweb 8181 /home/nag/webpages &
$ hostname
nigel.acme.com
Added lines 450-466:

'''Running nweb'''

Assuming the user of the directory is call debbie
[@
$ cd /home/debbie/webpages
# make the nweb binary executable
$ chmod ugo+x nweb

# make the files readable
$ chmod ugo+r *.html *.jpg *.ico

$ nweb 8181 /home/debbie/webpages
$ hostname
nigel.acme.com

@]
Added lines 469-480:

'''If you have root access then you can run nweb with the classic default port number of 80.

If you have some other programming already using port 80 this will fail - check the nweb.log
[@
$ nweb 80 /home/debbie/webpages
@]

Start your browser and access the website - note the missing port number as 80 is the default:
* http://nigel.acme.com/index.html

July 25, 2016, at 06:34 PM by 127.0.0.1 -
Added line 5:
\\
Added lines 12-24:
!Downloads!
||border=1
||'''Download File''' ||'''Comments'''||
||[[http://sourceforge.net/projects/nmon/files/nweb25.c|nweb25.c]] ||Current version 25 - 24th July 2016 \\
Added SIGCHLD support for operating systems that don't support the System V signal SIGCLD ||
||[[http://sourceforge.net/projects/nmon/files/nweb24.c|nweb24.c]] ||Version 24 - 23rd July 2016 \\
Added chroot() for security ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_extra.zip|nweb24_extra.zip]] ||Current version 24 client.c and a miniature example of a \\
website for testing purposes only ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_Ubuntu_RaspberryPi3_ARM|nweb24_Ubuntu_RaspberryPi3_ARM]] ||Version 24 compiled for Raspberry Pi 3 ARM running \\
Ubuntu 16.04 ||
||[[http://sourceforge.net/projects/nmon/files/nweb_AIX6_POWER|nweb_AIX6_POWER]] ||Version 24 compiled for AIX 6 (or above) on POWER ||
Changed lines 260-266 from:
!Over that socket we are going to use HTTP!

HTTP is short for Hypertext Transfer Protocol. This is used by your browser to "talk to the webserver to
make requests for files to be sent from the webserver and for sending the webserver data that is wants from
the user of a browser application.

to understand a little about this we are going to look at the nweb log file nweb.log:
to:
!Over that socket between the client browser and the webserver we are going to use HTTP!

HTTP is short for Hypertext Transfer Protocol. This is used by your browser to "talk to the webserver to do two things:
# GET operations - make requests for files to be sent from the webserver and
# PUT operation - for sending the webserver data that is wants from the user of a browser application.

To understand a little about this HTTP we are going to look at the nweb log file nweb.log as it records the incoming message and what it sent:
Changed lines 268-272 from:
:21
INFO: request:%blue%GET /temperature.html%% %red%HTTP/1.1%% %green%**Host:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1
**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/51.0.2704.103 Safari/537.36
to:
INFO: request:%blue%GET /temperature.html%% %red%HTTP/1.1%% %green%
**Host:pi.aixncc.uk.ibm.com%%**Connection: keep-alive
**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1
**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Added line 275:
Changed lines 284-286 from:
This is an extract of the nweb.log file while a single browser requests a single web page.
This is a very simple one file webpage but the browser automatically also requests a favicom.ico.
This is the tiny picture that the browser places on the tab for this open page.
to:
This is an extract of the nweb.log file while a single browser requests a single web page. We have the
# incoming GET, the file is wants and then loads of optional information that the browser thinks might be useful
# followed by the SENDing of the file including a header with the protocol version "1.1", the "200 OK" - which tells the browser the GET was handled OK and some other details we talk about below.
This is a very simple one file webpage but the browser will automatically also make a 2nd requests a "favicon.ico" file.
This is the tiny picture that the browser places on the tab for this webpage.
Changed line 308 from:
interactive protocols - these are used to send information to the webserver for server side application code to deal with.
to:
interactive parts of the HTTP protocol - these are used to send information to the webserver for server side application code to deal with.
Deleted lines 421-434:


!Downloads!
||border=1
||'''Download File''' ||'''Comments'''||
||[[http://sourceforge.net/projects/nmon/files/nweb25.c|nweb25.c]] ||Current version 25 - 24th July 2016 \\
Added SIGCHLD support for operating systems that don't support the System V signal SIGCLD ||
||[[http://sourceforge.net/projects/nmon/files/nweb24.c|nweb24.c]] ||Version 24 - 23rd July 2016 \\
Added chroot() for security ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_extra.zip|nweb24_extra.zip]] ||Current version 24 client.c and a miniature example of a \\
website for testing purposes only ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_Ubuntu_RaspberryPi3_ARM|nweb24_Ubuntu_RaspberryPi3_ARM]] ||Version 24 compiled for Raspberry Pi 3 ARM running \\
Ubuntu 16.04 ||
||[[http://sourceforge.net/projects/nmon/files/nweb_AIX6_POWER|nweb_AIX6_POWER]] ||Version 24 compiled for AIX 6 (or above) on POWER ||
July 25, 2016, at 05:40 PM by 127.0.0.1 -
Changed line 408 from:
[++Downloads++]
to:
!Downloads!
July 25, 2016, at 05:39 PM by 127.0.0.1 -
Changed lines 257-259 from:
**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
to:
**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/51.0.2704.103 Safari/537.36
**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Changed lines 313-314 from:
* %red%RED - this is the HHTP protocol version number. 1.1 is the minimal level these days. nweb ignores all the more complicated stuff.%%
* %green%GREEN - this is the machine the browser is communicating to - in complicated configurations the request might be handled by a different machine.%%
to:
* %red%RED - this is the HHTP protocol version number. 1.1 is the minimal level these days. nweb ignores all \\
the more complicated stuff.%%
* %green%GREEN - this is the machine the browser is communicating to - in complicated configurations the request \\
might be handled by a different machine.%%
Changed lines 321-322 from:
** Connection: keep-alive is about handling many requests over the one socket - nweb does NOT do this as its complicated but would be more efficient in CPU terms
to:
** Connection: keep-alive is about handling many requests over the one socket - nweb does NOT do this as its \\
complicated but would be more efficient in CPU terms
Changed lines 324-325 from:
* I removed all my browser cookies before this web request - otherwise there could be KB's if cookies attached to the end of the request.
to:
* I removed all my browser cookies before this web request - otherwise there could be KB's if cookies attached \\
to the end of the request.
Changed lines 415-416 from:
||[[http://sourceforge.net/projects/nmon/files/nweb24_extra.zip|nweb24_extra.zip]] ||Current version 24 client.c and a miniature example of a website for testing purposes only ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_Ubuntu_RaspberryPi3_ARM|nweb24_Ubuntu_RaspberryPi3_ARM]] ||Version 24 compiled for Raspberry Pi 3 ARM running Ubuntu 16.04 ||
to:
||[[http://sourceforge.net/projects/nmon/files/nweb24_extra.zip|nweb24_extra.zip]] ||Current version 24 client.c and a miniature example of a \\
website for testing purposes only ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_Ubuntu_RaspberryPi3_ARM|nweb24_Ubuntu_RaspberryPi3_ARM]] ||Version 24 compiled for Raspberry Pi 3 ARM running \\
Ubuntu 16.04 ||
July 25, 2016, at 04:53 PM by 127.0.0.1 -
Changed lines 45-46 from:
** This function is a convenient way to handle storing logging messages, report an error and (if necessary) stop nweb completely.
to:
** This function is a convenient way to handle storing logging messages, report an error and (if necessary)
stop nweb completely.
Changed lines 133-135 from:
* As itís a stream (no natural structure), you have to decide the protocol structure to get a discrete message sent and understood at the other end.
* For HTTP, the request message and response message header are finished with carriage return (CR or "/r" in the C code) and line feed (LF and "/n" in the C code) but the end of the requested file is highlighted by closing the socket. There are alternatives in HTTP but this is the simplest way to do it.
to:
* As itís a stream (no natural structure), you have to decide the protocol structure to get a discrete message sent \\
and understood at the other end.
* For HTTP, the request message and response message header are finished with carriage return (CR or "/r" in \\
the C code) and line feed (LF and "/n" in the C code) but the end of the requested file is highlighted by closing \\
the socket. There are alternatives in HTTP but this is the simplest way to do it.
Changed lines 143-144 from:
The arguments used in the nweb program are very typical for a regular general purpose socket using IP and other options are rare in the writerís experience.
to:
The arguments used in the nweb program are very typical for a regular general purpose socket using IP and other
options are rare in the writerís experience.
Changed lines 147-148 from:
When a remote client process is trying to contact your server is will use the IP address (often found by using a DNS service to convert a hostname to an IP
to:
When a remote client process is trying to contact your server is will use the IP address (often found by using a
DNS service to convert a hostname to an IP
Changed lines 155-156 from:
But in this case, the nweb program bind() function lets inetd know it wants to handle the particular port number you told nweb to use.
to:
But in this case, the nweb program bind() function lets inetd know it wants to handle the particular port number you
told nweb to use.
Changed lines 162-163 from:
The accept() function actually stops your nweb program until there is a socket connection request to this IP address and port number.
to:
The accept() function actually stops your nweb program until there is a socket connection request to this IP address and
port number.
Changed lines 165-166 from:
If you read bytes from the socket you get characters written from the client end and if you write bytes to the socket they get transmitted to the client process.
to:
If you read bytes from the socket you get characters written from the client end and if you write bytes to the socket
they get transmitted to the client process.
Changed lines 168-169 from:
Normally, you want to allow multiple clients to access your servers service and if this process does a read or write operation it could block until there are characters to be read or the written characters can be transmitted.
to:
Normally, you want to allow multiple clients to access your servers service and if this process does a read or write
operation it could block until there are characters to be read or the written characters can be transmitted.
Changed lines 192-193 from:
** This function changes directory and then makes that directory the new top level direction for the process. It is the top root / directory. Only files in it are possible to read and write. It is used here for security as it is then impossible for nweb to send any file from a different directory tree.
to:
** This function changes directory and then makes that directory the new top level direction for the process. \\
It is the top root / directory. Only files in it are possible to read and write. \\
It is used here for security as it is then impossible for nweb to send any file from a different directory tree.
Changed lines 197-199 from:
** This function sets the process group. The effect is for this process to break away from the other processes started by this user so it will not be effected by what happens to the users. This means the user can logging off and nweb will carry on running. This is called becoming a new process group leader.
to:
** This function sets the process group. The effect is for this process to break away from the other processes \\
started by this user so it will not be effected by what happens to the users. This means the user can logging off \\
and nweb will carry on running. This is called becoming a new process group leader.
July 25, 2016, at 04:50 PM by 127.0.0.1 -
Changed lines 204-205 from:
The nweb.c code only shows you the server side of the socket. For the record here is the code that is required for the client side. Fortunately, the client side is much simpler are you only need to supply the IP address and the port number to make the connection to the server. In the below the servers IP address is 192.168.0.42 and the server port is 8181.
to:
The nweb.c code only shows you the server side of the socket. For the record here is the code that is required
for the client side. Fortunately, the client side is much simpler are you only need to supply the IP address and
the port number to make the connection to the server. In the below the servers IP address is 192.168.0.42 and
the server port is 8181.
Changed lines 226-227 from:
Warning: the bind() and connect() functions take a structure as the argument that must be zero filled before the setting particular options. In the nweb.c the structure is made a static C variable to ensure a it is zero filled when the program is started. If this structure was on the stack as a variable within the function or in the heap of the process it could be filled with old data and so its content not be zero filled. In which case you need to ensure it is zero filled using the bzero() function can be used to do this.
to:
Warning: the bind() and connect() functions take a structure as the argument that must be zero filled before the
setting particular options. In the nweb.c the structure is made a static C variable to ensure a it is zero filled
when the program is started. If this structure was on the stack as a variable within the function or in the heap
of the process it could be filled with old data and so its content not be zero filled. In which case you need to
ensure it is zero filled using the bzero() function can be used to do this.
Changed lines 234-235 from:
HTTP is short for Hypertext Transfer Protocol. This is used by your browser to "talk to the webserver to make requests for files to be sent from the webserver and for sending the webserver data that is wants from the user of a browser application.
to:
HTTP is short for Hypertext Transfer Protocol. This is used by your browser to "talk to the webserver to
make requests for files to be sent from the webserver and for sending the webserver data that is wants from
the user of a browser application.
Changed lines 242-245 from:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8**Accept-Encoding: gzip, deflate, sdch**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****
to:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1
**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
**Accept-Encoding: gzip, deflate, sdch
**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****
Changed lines 275-276 from:
The more complex POST operations is simply ignored as this is a static webserver and we are not handling more interactive protocols - these are used to send information to the webserver for server side application code to deal with.
to:
The more complex POST operations is simply ignored as this is a static webserver and we are not handling more
interactive protocols - these are used to send information to the webserver for server side application code to deal with.
Changed lines 282-285 from:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8**Accept-Encoding: gzip, deflate, sdch**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****
to:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8**Accept-Encoding: gzip, deflate, sdch
**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****
Changed line 298 from:
* %green%GREEN - this is the machine the browser is communicating to - in complecated configurations the request might be handled by a different machine.%%
to:
* %green%GREEN - this is the machine the browser is communicating to - in complicated configurations the request might be handled by a different machine.%%
Changed lines 303-304 from:
** Connection: keep-alive is about handling many requests over the one socket - nweb does NOT do this as its complicated but would be more effeicent in CPU terms
** There is also en-GB showng a preference for proper English as oppossed to American :-)
to:
** Connection: keep-alive is about handling many requests over the one socket - nweb does NOT do this as its complicated but would be more efficient in CPU terms
** There is also en-GB showing a preference for proper English as opposed to American :-)
Changed lines 319-320 from:
Content-Length is as you might guess the length of the file - this allows the browser to get some buffer space ready
to:
Content-Length is as you might guess the length of the file - this allows the browser to get some buffer
space ready
Changed lines 322-326 from:
Content-Type: lets the browser know the format of the data. Text is the just words and image is a clue that the data is going to have to be displayed as a picture.



to:
Content-Type: lets the browser know the format of the data.
Text is the just words and image is a clue that the data is going to have to be displayed as a picture.



Changed lines 329-333 from:
INFO: request:GET /favicon.ico HTTP/1.1**Host: pi.aixncc.uk.ibm.com**Connection: keep-alive**Pragma: no-cache**Cache-Control: no-cache**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: */***Referer: http://pi.aixncc.uk.ibm.com/temperature.html**Accept-Encoding: gzip, deflate, sdch**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****:23
to:
INFO: request:GET /favicon.ico HTTP/1.1**Host: pi.aixncc.uk.ibm.com**Connection: keep-alive**Pragma:
no-cache**Cache-Control: no-cache**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: */***Referer:
http://pi.aixncc.uk.ibm.com/temperature.html**Accept-Encoding: gzip, deflate, sdch**Accept-Language:
en-GB,en-US;q=0.8,en;q=0.6****:23
July 25, 2016, at 04:30 PM by 127.0.0.1 -
Changed lines 19-20 from:
Well, look no further = nweb is what you need. This is a simple web server to understand (only 200 lines of C source code), so you work out how it functions to server out files for a web browser and make changes.
Add to this the fact it runs just as a regular user (if you use a high port number), it can not run any server side scripts or programs, so it canít open up any special privileges or security holes.
to:
Well, look no further = nweb is what you need.
This is a simple web server to understand (only 200 lines of C source code), so you work out how it functions
to server out files for a web browser and make changes.
Add to this the fact it runs just as a regular user (if you use a high port number), it can not run any
server side scripts or programs, so it canít open up any special privileges or security holes.
Changed lines 31-33 from:
If your favourite static file type is not in this list, you can simply add it in the source code and recompile to allow it - a few seconds work

The file supplied includes the UNIX source code in C and a precompiled AIX and Linux on Intel versions. The source will compile with the IBM VisualAge C compiler or the GNU C compiler and should run unchanged on AIX, Linux or any other UNIX version for which you care to compile it.
to:
If your favourite static file type is not in this list, you can simply add it in the source code and recompile to
allow it - a few seconds work

The file supplied includes the UNIX source code in C and a precompiled AIX and Linux on Intel versions.
The source will compile with the IBM VisualAge C compiler or the GNU C compiler and should run unchanged on AIX,
Linux or any other UNIX version for which you care to compile it.
Changed lines 46-47 from:
nweb breaks from the terminal session so it can't output onto your screen any progress of good operations, nor any errors so these are saved in the nweb.log file.
to:
nweb breaks from the terminal session so it can't output onto your screen any progress of good operations, nor any
errors so these are saved in the nweb.log file.
Changed lines 51-52 from:
In other cases like a fatal problem, the details written to the log and nweb stops - so if nweb seems to disappear - check the log.
to:
In other cases like a fatal problem, the details written to the log and nweb stops - so if nweb seems to disappear -
check the log.
Changed lines 56-57 from:
This function is called in a child process, one for each web request and so allows the main web server process to continue waiting for more connections.
Checks are made to ensure the request is safe and can be completed, it then transmits the requested static file to the browser/user and exits.
to:
This function is called in a child process, one for each web request and so allows the main web server process to continue
waiting for more connections.
Checks are made to ensure the request is safe and can be completed, it then transmits the requested static file to the
browser/user and exits.
Changed lines 61-63 from:
** This is the main web server process function. After checking the command parameters, it creates a socket for incoming browser requests and then sits in a loop accepting requests and starting child processes to handle them. It should never end.

to:
** This is the main web server process function.
After checking the command parameters, it creates a socket for incoming browser requests and then sits in a loop
accepting requests and starting child processes to handle them. It should never end.

Changed lines 104-105 from:
As you may not have come across some of these system calls before, these are explained in more detail below and in particular how they all fit together.
to:
As you may not have come across some of these system calls before, these are explained in more detail below and
in particular how they all fit together.
Changed lines 113-114 from:
Instead of reading and writing a file or a pipe, in this case, of process to process communication, we read and write a socket between the processes.
to:
Instead of reading and writing a file or a pipe, in this case, of process to process communication, we read and write
a socket between the processes.
July 25, 2016, at 04:28 PM by 127.0.0.1 -
Changed lines 241-243 from:
* <img src='http:/docs/nweb_diagram1.gif' />
to:
[@
<img src='http:/docs/nweb_diagram1.gif' />
@]
July 25, 2016, at 04:27 PM by 127.0.0.1 -
Added lines 210-302:

!Over that socket we are going to use HTTP!

HTTP is short for Hypertext Transfer Protocol. This is used by your browser to "talk to the webserver to make requests for files to be sent from the webserver and for sending the webserver data that is wants from the user of a browser application.

to understand a little about this we are going to look at the nweb log file nweb.log:
[@
:21
INFO: request:%blue%GET /temperature.html%% %red%HTTP/1.1%% %green%**Host:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8**Accept-Encoding: gzip, deflate, sdch**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****
INFO: SEND:temperature.html:22
INFO: Header:HTTP/1.1 200 OK
Server: nweb/24.0
Content-Length: 389934
Connection: close
Content-Type: text/html
@]

This is an extract of the nweb.log file while a single browser requests a single web page.
This is a very simple one file webpage but the browser automatically also requests a favicom.ico.
This is the tiny picture that the browser places on the tab for this open page.
This means two GET file operations to the webserver.

Normally, even a simple webpage included dozens of picture files, artwork graphic
files to make the page look pretty and gif images. Then there could be more
text and images for adverts.
Each of those will generate a further GET file operations to the webserver.
The extra files that a webpage needs is actually encoded in the webpage we
returned to the browswer. Then browser goes through that original webpage and
look for the instructions to fetch an extra file.
They look like this:
* <img src='http:/docs/nweb_diagram1.gif' />
This reads:
* <img /> = this is a link to a image
* src='****' = this is the place to get the image

Note: nweb only responds to the simple GET file operations.
The more complex POST operations is simply ignored as this is a static webserver and we are not handling more interactive protocols - these are used to send information to the webserver for server side application code to deal with.
For example logging in or sending screen field contents to the application.


:21
INFO: request:%blue%GET /temperature.html%% %red%HTTP/1.1%% %green%**Host:
pi.aixncc.uk.ibm.com%%**Connection: keep-alive**Cache-Control: max-age=0**Upgrade-Insecure-Requests: 1**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8**Accept-Encoding: gzip, deflate, sdch**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****
INFO: SEND:temperature.html:22
INFO: Header:HTTP/1.1 200 OK
Server: nweb/24.0
Content-Length: 389934
Connection: close
Content-Type: text/html

Note:
* %blue%BLUE - this is the webserver request and the file name is what
the browser wants sent back to it. nweb have to check the file exists, is
readable and sent it back%%
* %red%RED - this is the HHTP protocol version number. 1.1 is the minimal level these days. nweb ignores all the more complicated stuff.%%
* %green%GREEN - this is the machine the browser is communicating to - in complecated configurations the request might be handled by a different machine.%%
* BLACK - this is other stuff that the browser sends as it might help the webserver decide what to send back.
* Some of it is worrying as it includes:
** The Operating system NT 6.1 - also known as Windows 7!,
** The browser is Chrome but faking being other browsers if necessary,
** Connection: keep-alive is about handling many requests over the one socket - nweb does NOT do this as its complicated but would be more effeicent in CPU terms
** There is also en-GB showng a preference for proper English as oppossed to American :-)
* I removed all my browser cookies before this web request - otherwise there could be KB's if cookies attached to the end of the request.

The:
* INFO: SEND:temperature.html
Is the sending of the data but that has a HTTP header send first and this is
the lines following
Server: nweb/24.0
Content-Length: 389934
Connection: close
Content-Type: text/html


Notes:
Server is the name of the server and its version
Content-Length is as you might guess the length of the file - this allows the browser to get some buffer space ready
Connection: close is a waning that nweb will close the connection rather than use keep-alive.
Content-Type: lets the browser know the format of the data. Text is the just words and image is a clue that the data is going to have to be displayed as a picture.




:22
INFO: request:GET /favicon.ico HTTP/1.1**Host: pi.aixncc.uk.ibm.com**Connection: keep-alive**Pragma: no-cache**Cache-Control: no-cache**User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36**Accept: */***Referer: http://pi.aixncc.uk.ibm.com/temperature.html**Accept-Encoding: gzip, deflate, sdch**Accept-Language: en-GB,en-US;q=0.8,en;q=0.6****:23
INFO: SEND:favicon.ico:23
INFO: Header:HTTP/1.1 200 OK
Server: nweb/24.0
Content-Length: 1334
Connection: close
Content-Type: image/ico
July 25, 2016, at 04:18 PM by 127.0.0.1 -
Changed lines 34-36 from:

'''Summary of the functions within nweb'''
to:
!Summary of the functions within nweb!
Changed lines 54-55 from:
'''Pseudo code of the program'''
to:
!Pseudo code of the program!
Changed lines 90-91 from:
'''System Calls'''
to:
!System Calls!
Changed lines 95-96 from:
to:
Following a worked example is the best way to learn.
Changed line 103 from:
to:
|| border=1
Changed lines 152-154 from:
fucntions but that is more complicated so we avoided in this webserver
example.
to:
functions but that is more complicated so we avoided in this webserver example.
Added lines 188-189:
!Now lets look at the actual code !
Added line 211:
!hands-on!
Changed line 236 from:
<LI>This is an unordered list.
to:
<LI>This is an un-ordered list.
July 25, 2016, at 04:14 PM by 127.0.0.1 -
Changed line 13 from:
Have you ever:
to:
Have you ever:
July 25, 2016, at 12:14 PM by 127.0.0.1 -
Changed lines 103-107 from:
||socket || Order your line and telephone! ||
||bind || have a telephone number assigned ||
||listen || tell your telecoms provider you are ready for calls ||
||accept || wait for a call and answer the call ||
||fork sub-process || hand call to someone else to deal with ||
to:

||socket() ||Order your line and telephone! ||
||bind()||Have a telephone number assigned ||
||listen()||Tell your telecomms provider you are ready for calls ||
||accept()||Wait for a call and answer the phone ||
||fork() a sub-process to \\
return the requested file||Hand call to someone else to deal with ||
July 25, 2016, at 11:26 AM by 127.0.0.1 -
Added lines 102-107:
!Telephone Analogue!
||socket || Order your line and telephone! ||
||bind || have a telephone number assigned ||
||listen || tell your telecoms provider you are ready for calls ||
||accept || wait for a call and answer the call ||
||fork sub-process || hand call to someone else to deal with ||
July 25, 2016, at 11:21 AM by 127.0.0.1 -
Changed line 6 from:
It is a static page only server (no fancy live content) and only spepcific files types.\\
to:
It is a static page only server (no fancy live content) and only specific files types.\\
Changed line 21 from:
If you want it to run with the standard web server port of 80 you tyipically
to:
If you want it to run with the standard web server port of 80 you typically
Changed line 40 from:
** This function is a convenient way to hangle storing logging messages, report an error and (if nessesary) stop nweb completely.
to:
** This function is a convenient way to handle storing logging messages, report an error and (if necessary) stop nweb completely.
Changed lines 95-96 from:
It can hard from the sjust the code or the manaul to see what they do and how they together make up a web server.
to:
It can hard from just the code or the manual to see what they do and how they together make up a web server.
Changed line 110 from:
* As itís a stream (no natural structure), you have to decide the protocol structure to get a descrete message sent and understtod at the other end.
to:
* As itís a stream (no natural structure), you have to decide the protocol structure to get a discrete message sent and understood at the other end.
Changed line 135 from:
If you read bytes from the socket you get characters written from the client end and if you write bytes to the socket they get tramsmitted to the client process.
to:
If you read bytes from the socket you get characters written from the client end and if you write bytes to the socket they get transmitted to the client process.
Changed line 178 from:
file descriptor to acces them.
to:
file descriptor to access them.
July 25, 2016, at 11:08 AM by 127.0.0.1 -
Changed lines 252-253 from:
||[[http://sourceforge.net/projects/nmon/files/nweb24.c|nweb24.c]] ||Version 24 - 23rd July 2016 ||
to:
||[[http://sourceforge.net/projects/nmon/files/nweb24.c|nweb24.c]] ||Version 24 - 23rd July 2016 \\
Added chroot() for security ||
July 25, 2016, at 11:07 AM by 127.0.0.1 -
Added lines 1-257:
[+++nweb Tiny Webserver Example+++]

||http:/docs/nweb_spider.gif ||\\
'''%blue%[++nweb Tiny Safe Webserver++]\\
nweb is a 200 lines of C code example of how a webserver actually works at its core.\\
It is a static page only server (no fancy live content) and only spepcific files types.\\
It actually works too and a few 100's people use it on the Internet for for their own projects.\\
\\
Note: This code is a simple code sample and so NOT under any license or Copyrighted. Use it any way you like.%%'''||

!nweb - A Tiny Safe Web Server with source code!

Have you ever:
# Wondered how a web server actually works via a simple example?
# Wanted to run a tiny safe web server (but were worried about using a fully blown web server may cause security issues)?
# Wondered how to write a program that accepts incoming messages via a network socket?
# Just wanted your own web server to experiment, extend and learn with.

Well, look no further = nweb is what you need. This is a simple web server to understand (only 200 lines of C source code), so you work out how it functions to server out files for a web browser and make changes.
Add to this the fact it runs just as a regular user (if you use a high port number), it can not run any server side scripts or programs, so it canít open up any special privileges or security holes.
If you want it to run with the standard web server port of 80 you tyipically
need to start it as the superuser root.

nweb only transmits to the browser the following types of files
* Static web pages with extensions .html or .htm
* Graphical images .gif or .png or .jgp or .jpeg or .ico (tiny picture for the browswer tab)
* Useful file types like compressed binary files and archives .zip , gz and .tar
If your favourite static file type is not in this list, you can simply add it in the source code and recompile to allow it - a few seconds work

The file supplied includes the UNIX source code in C and a precompiled AIX and Linux on Intel versions. The source will compile with the IBM VisualAge C compiler or the GNU C compiler and should run unchanged on AIX, Linux or any other UNIX version for which you care to compile it.
On UNIX (assuming the compiler is in your path) just type:
* cc -O3 nweb.c -o nweb


'''Summary of the functions within nweb'''

There are only four functions in the source code and these are explained below:

* logger()
** This function is a convenient way to hangle storing logging messages, report an error and (if nessesary) stop nweb completely.
nweb breaks from the terminal session so it can't output onto your screen any progress of good operations, nor any errors so these are saved in the nweb.log file.
In some cases the failure can be reported to the user's web browser as a fake
web page describing the issue for example if the browser can't find or access
the requested file.
In other cases like a fatal problem, the details written to the log and nweb stops - so if nweb seems to disappear - check the log.
It is called from the main function and also from the web function if an error canít be reported back to the web server user.
* web()
** This is the function that actually deals with the HTTP browser request and returning the data to the browser and to user.
This function is called in a child process, one for each web request and so allows the main web server process to continue waiting for more connections.
Checks are made to ensure the request is safe and can be completed, it then transmits the requested static file to the browser/user and exits.
* main()
** This is the main web server process function. After checking the command parameters, it creates a socket for incoming browser requests and then sits in a loop accepting requests and starting child processes to handle them. It should never end.


'''Pseudo code of the program'''

Below is the pseudo code for the ~200 lines of source code. It should help you to understand the flow of the program.

[@
web() - this function returns the requested data back to the browser
{
read from the socket the request
check itís a simple GET command
check no parent directory requested to escape the web servers home directory
if no file name given assume index.html
check the file extension is valid and supported
check the file is readable by opening it
transmit the HTTP header to the browser
transmit the file contents to the browser
stop
}

main()
{
check the arguments supplied are valid
check the directory supplied is sensible and not a security risk
create a socket, bind it to a port number and start listening for requests
become a daemon process so it continues if the user logs out
ignore child programs (to avoid zombies on their death)
forever {
accept incoming socket connection
fork a child process
if the child process
then call the web function
else close socket
}
}
@]


'''System Calls'''

As you may not have come across some of these system calls before, these are explained in more detail below and in particular how they all fit together.
Although, you can always look them up in the manual or on the web.
It can hard from the sjust the code or the manaul to see what they do and how they together make up a web server.

http:/docs/nweb_diagram1.gif

In UNIX and Linux most I/O is performed by the read and write system calls.
Instead of reading and writing a file or a pipe, in this case, of process to process communication, we read and write a socket between the processes.


The socket(), bind(), listen() and accept() network system calls, all work together to create a web server process.
Combined they set up a socket ready for use to communicate over a network.
A socket is:
* An input output stream like that of regular pipes and files.
* But it can also be used over a network to allow remote access to/from a server
* A socket is bidirectional - you read and write the same socket. Obviously write one end and read from the other.
* This means regular read and write functions are used to send and receive data.
* As itís a stream (no natural structure), you have to decide the protocol structure to get a descrete message sent and understtod at the other end.
* For HTTP, the request message and response message header are finished with carriage return (CR or "/r" in the C code) and line feed (LF and "/n" in the C code) but the end of the requested file is highlighted by closing the socket. There are alternatives in HTTP but this is the simplest way to do it.

The socket() function creates the socket and returns the file descriptor which
can be used with any function that uses file descriptors like read, write,
close. The arguments to socket() tell the operating system what type of socket and communication you need.
There are dozens of permutations and combinations available.
The arguments used in the nweb program are very typical for a regular general purpose socket using IP and other options are rare in the writerís experience.

The bind() function attaches a particular port number to the socket.
When a remote client process is trying to contact your server is will use the IP address (often found by using a DNS service to convert a hostname to an IP
address) and the port number.
The port number tells the operating system inetd process, which service you want on the server.
The port details on most UNIX machines are listed in the /etc/services files.
Included in here will be standard port numbers for services like FTP, telnet and web servers (usually port 80 or 8080).
You should check the port numbers in this /etc/services file to make sure you donít try one which is already in use.
Although, if you try you should get an error message as it is normally impossible for two servers to use the same port number
But in this case, the nweb program bind() function lets inetd know it wants to handle the particular port number you told nweb to use.

The listen() function call tells the operating system you are now ready to accept incoming requests.
This is the final switch that makes the socket available to local and remote
programs over the network.

The accept() function actually stops your nweb program until there is a socket connection request to this IP address and port number.
Once the accept function call returns it means that the socket file descriptor it returns is live.
If you read bytes from the socket you get characters written from the client end and if you write bytes to the socket they get tramsmitted to the client process.
But it is not normal to simply read or write a single socket.
Normally, you want to allow multiple clients to access your servers service and if this process does a read or write operation it could block until there are characters to be read or the written characters can be transmitted.
in other words this server process should be running the accept function again to allow a new connection to start.
The way to handle this is for the server process to start a child process that
does the "talking" to the client and any work it needs done and for the main
server process to close the socket and rerun the accept function and so await the next client connection.
Note: When the child process is started it inherits the parents open sockets and so the child keeps the socket alive.
Note: The alternative to forking sub-processes is using multi-threaded
fucntions but that is more complicated so we avoided in this webserver
example.

So it is normal in network servers for you to find code that looks like this (in pseudo code form):
[@
socket() - create the resources
bind() - to a port
listen() - ready to handle data
forever {
accept() - the connection
Start a child to handle the work
}
@]

!Other system call functions used!

* chroot()
** This function changes directory and then makes that directory the new top level direction for the process. It is the top root / directory. Only files in it are possible to read and write. It is used here for security as it is then impossible for nweb to send any file from a different directory tree.

* setpgrp
** This function sets the process group. The effect is for this process to break away from the other processes started by this user so it will not be effected by what happens to the users. This means the user can logging off and nweb will carry on running. This is called becoming a new process group leader.

* signal
** This function decides what happens when software interrupts arrive for the
process. Within the nweb.c code, the main server wants to ignore the death of
a child signal. Without this the main server process would have to run the
wait system call for each child process or they would be forever stuck in the
"zombie" state waiting to the parent to call the wait() function. Eventually,
there would be to many 1000's zombie processes and the users environment would hang as they could not create further processes.

* open(), read(), write() and close()
These are the regular C library system call functions but they are used for
the reading of the sockets and files sent to the client web browsers.
To a UNIX or Linux process the socket and files behave teh same way and use a
file descriptor to acces them.
Note: the socket is "opened" with the accept() function - the open() in the code is for opening the requested file.

The nweb.c code only shows you the server side of the socket. For the record here is the code that is required for the client side. Fortunately, the client side is much simpler are you only need to supply the IP address and the port number to make the connection to the server. In the below the servers IP address is 192.168.0.42 and the server port is 8181.

[@
int sockfd;
static struct sockaddr_in serv_addr;

if((sockfd = socket(AF_INET, SOCK_STREAM,0)) <0)
pexit("Network socket system call");

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = inet_addr("196.168.0.42");
serv_addr.sin_port = htons(8181);

if(connect(connectfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) <0)
pexit("Network connect system call");

/* now the sockfd can be used to communicate to the server */
@]

Warning: the bind() and connect() functions take a structure as the argument that must be zero filled before the setting particular options. In the nweb.c the structure is made a static C variable to ensure a it is zero filled when the program is started. If this structure was on the stack as a variable within the function or in the heap of the process it could be filled with old data and so its content not be zero filled. In which case you need to ensure it is zero filled using the bzero() function can be used to do this.

Example use on nweb:
[@
$ mkdir /home/nag/webpages
$ cd /home/nag/webpages
$ cp /tmp/nweb.tar .
$ tar xvf nweb.tar
$ ls
nweb.c
nweb_aix
nweb_linux_intel
sample_index.html
nweb.gif


$ cat sample_index.html
<HTML>
<HEAD>
nweb test
</HEAD>
<BODY>
This is a test page.
<H1>Header level 1</H1>
<H2>Header level 2</H2>
<UL>
<LI>This is an unordered list.
<LI>Which means bullet points.
</UL>
This is a sample gif image
<IMG SRC="nweb.gif">
<B>The End</B>
</BODY>
</HTML>

$ cp sample_index.html index.html
$ chmod ugo+x nweb
$ chmod ugo+r *.html nweb.gif
$ nweb 8181 /home/nag/webpages &
$ hostname
nigel.acme.com

@]
Start your browser and access the website:
* http://nigel.acme.com:8181/index.html


[++Downloads++]
||border=1
||'''Download File''' ||'''Comments'''||
||[[http://sourceforge.net/projects/nmon/files/nweb25.c|nweb25.c]] ||Current version 25 - 24th July 2016 \\
Added SIGCHLD support for operating systems that don't support the System V signal SIGCLD ||
||[[http://sourceforge.net/projects/nmon/files/nweb24.c|nweb24.c]] ||Version 24 - 23rd July 2016 ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_extra.zip|nweb24_extra.zip]] ||Current version 24 client.c and a miniature example of a website for testing purposes only ||
||[[http://sourceforge.net/projects/nmon/files/nweb24_Ubuntu_RaspberryPi3_ARM|nweb24_Ubuntu_RaspberryPi3_ARM]] ||Version 24 compiled for Raspberry Pi 3 ARM running Ubuntu 16.04 ||
||[[http://sourceforge.net/projects/nmon/files/nweb_AIX6_POWER|nweb_AIX6_POWER]] ||Version 24 compiled for AIX 6 (or above) on POWER ||

- - - The End - - -
Edit - History - Print - Recent Changes - Search
Page last modified on August 10, 2016, at 03:43 PM