How Web Servers Work

Introduction to How Web Servers Work

Have you ever wondered about the mechanisms that delivered this page to you? Chances are you are
sitting at a computer right now, viewing this page in a browser. So, when you clicked on the link for this
page, or typed in its URL (uniform resource locator), what happened behind the scenes to bring this
page onto your screen?

If you've ever been curious about the process, or have ever wanted to know some of the specific
mechanisms that allow you to surf the Internet, then read on. In this article, you will learn how Web
servers bring pages into your home, school or office. Let's get started!

The Basic Process

Let's say that you are sitting at your computer, surfing the Web, and you get a call from a friend who says,
"I just read a great article! Type in this URL and check it out. It's at http://www.howstuffworks.com/web-
server.htm." So you type that URL into your browser and press return. And magically, no matter where in
the world that URL lives, the page pops up on your screen.

At the most basic level possible, the following diagram shows the steps that brought that page to your
screen:

Your browser formed a connection to a Web server, requested a page and received it.

Behind the Scenes

If you want to get into a bit more detail on the process of getting a Web page onto your computer screen,
here are the basic steps that occurred behind the scenes:
• The browser broke the URL into three parts:
1. The protocol ("http")
2. The server name ("www.howstuffworks.com")
3. The file name ("web-server.htm")
• The browser communicated with a name server to translate the server name
"www.howstuffworks.com" into an IP Address, which it uses to connect to the server machine.
• The browser then formed a connection to the server at that IP address on port 80. (We'll
discuss ports later in this article.)
• Following the HTTP protocol, the browser sent a GET request to the server, asking for the file
"http://www.howstuffworks.com/web-server.htm." (Note that cookies may be sent from browser
to server with the GET request -- see How Internet Cookies Work for details.)
 • The server then sent the HTML text for the Web page to the browser. (Cookies may also be
sent from server to browser in the header for the page.)
• The browser read the HTML tags and formatted the page onto your screen.
If you've never explored this process before, that's a lot of new vocabulary. To understand this whole
process in detail, you need to learn about IP addresses, ports, protocols... The following sections will lead
you through a complete explanation.

The Internet
So what is "the Internet"? The Internet is a gigantic collection of millions of computers, all linked together
on a computer network. The network allows all of the computers to communicate with one another. A
home computer may be linked to the Internet using a phone-line modem, DSL or cable modem that talks
to an Internet service provider (ISP). A computer in a business or university will usually have a network
interface card (NIC) that directly connects it to a local area network (LAN) inside the business. The
business can then connect its LAN to an ISP using a high-speed phone line like a T1 line. A T1 line can
handle approximately 1.5 million bits per second, while a normal phone line using a modem can typically
handle 30,000 to 50,000 bits per second.

ISPs then connect to larger ISPs, and the largest ISPs maintain fiber-optic "backbones" for an entire
nation or region. Backbones around the world are connected through fiber-optic lines, undersea cables
or satellite links (see An Atlas of Cyberspaces for some interesting backbone maps). In this way, every
computer on the Internet is connected to every other computer on the Internet.

Clients and Servers

In general, all of the machines on the Internet can be categorized as two types: servers and clients.
Those machines that provide services (like Web servers or FTP servers) to other machines are servers.
And the machines that are used to connect to those services are clients. When you connect to Yahoo! at
www.yahoo.com to read a page, Yahoo! is providing a machine (probably a cluster of very large
machines), for use on the Internet, to service your request. Yahoo! is providing a server. Your machine,
on the other hand, is probably providing no services to anyone else on the Internet. Therefore, it is a user
machine, also known as a client. It is possible and common for a machine to be both a server and a
client, but for our purposes here you can think of most machines as one or the other.

A server machine may provide one or more services on the Internet. For example, a server machine
might have software running on it that allows it to act as a Web server, an e-mail server and
an FTP server. Clients that come to a server machine do so with a specific intent, so clients direct their
requests to a specific software server running on the overall server machine. For example, if you are
running a Web browser on your machine, it will most likely want to talk to the Web server on the server
machine. Your Telnet application will want to talk to the Telnet server, your e-mail application will talk to
the e-mail server, and so on...

IP Addresses
To keep all of these machines straight, each machine on the Internet is assigned a unique address called
an IP address. IP stands for Internet protocol, and these addresses are 32-bit numbers, normally
expressed as four "octets" in a "dotted decimal number." A typical IP address looks like this:
216.27.61.137

The four numbers in an IP address are called octets because they can have values between 0 and 255,
which are 28 possibilities per octet.

Every machine on the Internet has a unique IP address. A server has a static IP address that does not
change very often. A home machine that is dialing up through a modem often has an IP address that is
assigned by the ISP when the machine dials in. That IP address is unique for that session -- it may be
different the next time the machine dials in. This way, an ISP only needs one IP address for each modem
it supports, rather than for each customer.

If you are working on a Windows machine, you can view a lot of the Internet information for your machine,
including your current IP address and hostname, with the command WINIPCFG.EXE (IPCONFIG.EXE for
Windows 2000/XP). On a UNIX machine, type nslookup at the command prompt, along with a machine
name, like www.howstuffworks.com -- e.g. "nslookup www.howstuffworks.com" -- to display the IP
address of the machine, and you can use the command hostname to learn the name of your machine.
(For more information on IP addresses, see IANA.)

As far as the Internet's machines are concerned, an IP address is all you need to talk to a server. For
example, in your browser, you can type the URLhttp://209.116.69.66 and arrive at the machine that
contains the Web server for HowStuffWorks. On some servers, the IP address alone is not sufficient, but
on most large servers it is -- keep reading for details.

Domain Names
Because most people have trouble remembering the strings of numbers that make up IP addresses, and
because IP addresses sometimes need to change, all servers on the Internet also have human-readable
names, called domain names. For example, www.howstuffworks.com is a permanent, human-
readable name. It is easier for most of us to remember www.howstuffworks.com than it is to remember
209.116.69.66.

The name www.howstuffworks.com actually has three parts:

1. The host name ("www")

2. The domain name ("howstuffworks")
3. The top-level domain name ("com")
Domain names within the ".com" domain are managed by the registrar called VeriSign. VeriSign also
manages ".net" domain names. Other registrars (like RegistryPro, NeuLevel and Public Interest Registry)
manage the other domains (like .pro, .biz and .org). VeriSign creates the top-level domain names and
guarantees that all names within a top-level domain are unique. VeriSign also maintains contact
information for each site and runs the "whois" database. The host name is created by the company
hosting the domain. "www" is a very common host name, but many places now either omit it or replace it
with a different host name that indicates a specific area of the site. For example, in encarta.msn.com, the
domain name for Microsoft's Encarta encyclopedia, "encarta" is designated as the host name instead of
"www."

Name Servers
A set of servers called domain name servers (DNS) maps the human-readable names to the IP
addresses. These servers are simple databases that map names to IP addresses, and they are
distributed all over the Internet. Most individual companies, ISPs and universities maintain small name
servers to map host names to IP addresses. There are also central name servers that use data supplied
by VeriSign to map domain names to IP addresses.

If you type the URL "http://www.howstuffworks.com/web-server.htm" into your browser, your browser
extracts the name "www.howstuffworks.com," passes it to a domain name server, and the domain name
server returns the correct IP address for www.howstuffworks.com. A number of name servers may be
involved to get the right IP address. For example, in the case of www.howstuffworks.com, the name
server for the "com" top-level domain will know the IP address for the name server that knows host
names, and a separate query to that name server, operated by the HowStuffWorks ISP, may deliver the
actual IP address for the HowStuffWorks server machine.

On a UNIX machine, you can access the same service using the nslookup command. Simply type a
name like "www.howstuffworks.com" into the command line, and the command will query the name
servers and deliver the corresponding IP address to you.

So here it is: The Internet is made up of millions of machines, each with a unique IP address. Many of
these machines are server machines, meaning that they provide services to other machines on the
Internet. You have heard of many of these servers: e-mail servers, Web servers, FTP servers, Gopher
servers and Telnet servers, to name a few. All of these are provided by server machines.

Ports
Any server machine makes its services available to the Internet using numbered ports, one for each
service that is available on the server. For example, if a server machine is running a Web server and an
FTP server, the Web server would typically be available on port 80, and the FTP server would be
available on port 21. Clients connect to a service at a specific IP address and on a specific port.

Each of the most well-known services is available at a well-known port number. Here are some common
port numbers:

• echo 7
• daytime 13
• qotd 17 (Quote of the Day)
• ftp 21
• telnet 23
• smtp 25 (Simple Mail Transfer, meaning e-mail)
• time 37
• nameserver 53
 • nicname 43 (Who Is)
• gopher 70
• finger 79
• WWW 80
If the server machine accepts connections on a port from the outside world, and if a firewall is not
protecting the port, you can connect to the port from anywhere on the Internet and use the service. Note
that there is nothing that forces, for example, a Web server to be on port 80. If you were to set up your
own machine and load Web server software on it, you could put the Web server on port 918, or any other
unused port, if you wanted to. Then, if your machine were known as xxx.yyy.com, someone on the
Internet could connect to your server with the URL http://xxx.yyy.com:918. The ":918" explicitly specifies
the port number, and would have to be included for someone to reach your server. When no port is
specified, the browser simply assumes that the server is using the well-known port 80.

Protocols
Once a client has connected to a service on a particular port, it accesses the service using a specific
protocol. The protocol is the pre-defined way that someone who wants to use a service talks with that
service. The "someone" could be a person, but more often it is a computer program like a Web browser.
Protocols are often text, and simply describe how the client and server will have their conversation.

Perhaps the simplest protocol is the daytime protocol. If you connect to port 13 on a machine that
supports a daytime server, the server will send you its impression of the current date and time and then
close the connection. The protocol is, "If you connect to me, I will send you the date and time and then
disconnect." Most UNIX machines support this server. If you would like to try it out, you can connect to
one with the Telnet application. In UNIX, the session would look like this:
%telnet web67.ntx.net 13
Trying 216.27.61.137...
Connected to web67.ntx.net.
Escape character is '^]'.
Sun Oct 25 08:34:06 1998
Connection closed by foreign host.

On a Windows machine, you can access this server by typing "telnet web67.ntx.net 13" at the MSDOS
prompt.

In this example, web67.ntx.net is the server's UNIX machine, and 13 is the port number for the daytime
service. The Telnet application connects to port 13 (telnet naturally connects to port 23, but you can direct
it to connect to any port), then the server sends the date and time and disconnects. Most versions of
Telnet allow you to specify a port number, so you can try this using whatever version of Telnet you have
available on your machine.

Most protocols are more involved than daytime and are specified in Request for Comment (RFC)
documents that are publicly available (seehttp://sunsite.auc.dk/RFC/ for a nice archive of all RFCs). Every
Web server on the Internet conforms to the HTTP protocol, summarized nicely in The Original HTTP as
defined in 1991. The most basic form of the protocol understood by an HTTP server involves just one
command: GET. If you connect to a server that understands the HTTP protocol and tell it to "GET
filename," the server will respond by sending you the contents of the named file and then disconnecting.
Here's a typical session:
%telnet www.howstuffworks.com 80
Trying 216.27.61.137...
Connected to howstuffworks.com.
Escape character is '^]'.
GET http://www.howstuffworks.com/
<html>
<head>
<title>Welcome to How Stuff Works</title>
...
</body>
</html>
Connection closed by foreign host.

In the original HTTP protocol, all you would have sent was the actual filename, such as "/" or "/web-
server.htm." The protocol was later modified to handle the sending of the complete URL. This has allowed
companies that host virtual domains, where many domains live on a single machine, to use one IP
address for all of the domains they host. It turns out that hundreds of domains are hosted on
209.116.69.66 -- the HowStuffWorks IP address.

Putting It All Together

Now you know a tremendous amount about the Internet. You know that when you type a URL into a
browser, the following steps occur:
• The browser breaks the URL into three parts:
1. The protocol ("http")
2. The server name ("www.howstuffworks.com")
3. The file name ("web-server.htm")
• The browser communicates with a name server to translate the server name,
"www.howstuffworks.com," into an IP address, which it uses to connect to that server machine.
• The browser then forms a connection to the Web server at that IP address on port 80.
• Following the HTTP protocol, the browser sends a GET request to the server, asking for the
file "http://www.howstuffworks.com/web-server.htm." (Note that cookies may be sent from
browser to server with the GET request -- see How Internet Cookies Work for details.)
• The server sends the HTML text for the Web page to the browser. (Cookies may also be sent
from server to browser in the header for the page.)
• The browser reads the HTML tags and formats the page onto your screen.

Extras: Security
You can see from this description that a Web server can be a pretty simple piece of software. It takes the
file name sent in with the GET command, retrieves that file and sends it down the wire to the browser.
Even if you take into account all of the code to handle the ports and port connections, you could easily
create a C program that implements a simple Web server in less than 500 lines of code. Obviously, a full-
blown enterprise-level Web server is more involved, but the basics are very simple.

Most servers add some level of security to the serving process. For example, if you have ever gone to a
Web page and had the browser pop up a dialog box asking for your name and password, you have
encountered a password-protected page. The server lets the owner of the page maintain a list of names
and passwords for those people who are allowed to access the page; the server lets only those people
who know the proper password see the page. More advanced servers add further security to allow
an encrypted connection between server and browser, so that sensitive information like credit card
numbers can be sent on the Internet.

That's really all there is to a Web server that delivers standard, static pages. Static pages are those that
do not change unless the creator edits the page.
Extras: Dynamic Pages
But what about the Web pages that are dynamic? For example:
• Any guest book allows you to enter a message in an HTML form, and the next time the guest
book is viewed, the page will contain the new entry.
• The whois form at Network Solutions allows you to enter a domain name on a form, and the
page returned is different depending on the domain name entered.
• Any search engine lets you enter keywords on an HTML form, and then it dynamically creates
a page based on the keywords you enter.
In all of these cases, the Web server is not simply "looking up a file." It is actually processing information
and generating a page based on the specifics of the query. In almost all cases, the Web server is using
something called CGI scripts to accomplish this feat. CGI scripts are a topic unto themselves, and are
described in the HowStuffWorks article How CGI Scripting Work.

How Domain Name Servers Work

Introduction to How Domain Name Servers Work

If you spend any time on the Internet sending e-mail or browsing the Web, then you use domain name
servers without even realizing it. Domain name servers, or DNS, are an incredibly important but
completely hidden part of the Internet, and they are fascinating. The DNS system forms one of the largest
and most active distributed databases on the planet. Without DNS, the Internet would shut down very
quickly.

When you use the Web or send an e-mail message, you use a domain name to do it. For example, the
URL "http://www.howstuffworks.com" contains the domain name howstuffworks.com. So does the e-
mail address "iknow@howstuffworks.com."

Human-readable names like "howstuffworks.com" are easy for people to remember, but they don't do
machines any good. All of the machines use names called IP addresses to refer to one another. For
example, the machine that humans refer to as "www.howstuffworks.com" has the IP
address 70.42.251.42. Every time you use a domain name, you use the Internet's domain name servers
(DNS) to translate the human-readable domain name into the machine-readable IP address. During a day
of browsing and e-mailing, you might access the domain name servers hundreds of times!

In this article, we'll take a look at the DNS system so you can understand how it works and appreciate its
amazing capabilities.

DNS Servers and IP Addresses

Domain name servers translate domain names to IP addresses. That sounds like a simple task, and it
would be -- except for five things:

• There are billions of IP addresses currently in use, and most machines have a human-
readable name as well.
• There are many billions of DNS requests made every day. A single person can easily make a
hundred or more DNS requests a day, and there are hundreds of millions of people and
machines using the Internet daily.
• Domain names and IP addresses change daily.
• New domain names get created daily.
• Millions of people do the work to change and add domain names and IP addresses every day.
The DNS system is a database, and no other database on the planet gets this many requests. No other
database on the planet has millions of people changing it every day, either. That is what makes the DNS
system so unique.

IP Addresses
To keep all of the machines on the Internet straight, each machine is assigned a unique address called
an IP address. IP stands for Internet protocol, and these addresses are 32-bit numbers normally
expressed as four "octets" in a "dotted decimal number." A typical IP address looks like this:
70.42.251.42

The four numbers in an IP address are called octets because they can have values between 0 and 255
(28 possibilities per octet).

Every machine on the Internet has its own IP address. A server has a static IP address that does not
change very often. A home machine that is dialing up through a modem often has an IP address that is
assigned by the ISP when you dial in. That IP address is unique for your session and may be different the
next time you dial in. In this way, an ISP only needs one IP address for each modem it supports, rather
than for every customer.

If you are working on a Windows machine, you can view your current IP address with the
command WINIPCFG.EXE (IPCONFIG.EXE for Windows 2000/XP). On a UNIX machine,
type nslookup along with a machine name (such as "nslookup www.howstuffworks.com") to display the
IP address of the machine (use the command hostname to learn the name of your machine).

For more information on IP addresses, see IANA.

As far as the Internet's machines are concerned, an IP address is all that you need to talk to a server. For
example, you can type in your browser the URLhttp://70.42.251.42 and you will arrive at the machine that
contains the Web server for HowStuffWorks. Domain names are strictly a human convenience.

The Distributed System

Name servers do two things all day long:
• They accept requests from programs to convert domain names into IP addresses.
• They accept requests from other name servers to convert domain names into IP addresses.
When a request comes in, the name server can do one of four things with it:
• It can answer the request with an IP address because it already knows the IP address for the
domain.
• It can contact another name server and try to find the IP address for the name requested. It
may have to do this multiple times.
• It can say, "I don't know the IP address for the domain you requested, but here's the IP
address for a name server that knows more than I do."
• It can return an error message because the requested domain name is invalid or does not
exist.

When you type a URL into your browser, the browser's first step is to convert the domain name and host
name into an IP address so that the browser can go request a Web page from the machine at that IP
address (see How Web Servers Work for details on the whole process). To do this conversion, the
browser has a conversation with a name server.
When you set up your machine on the Internet, you (or the software that you installed to connect to your
ISP) had to tell your machine what name server it should use for converting domain names to IP
addresses. On some systems, the DNS is dynamically fed to the machine when you connect to the ISP,
and on other machines it is hard-wired. If you are working on a Windows 95/98/ME machine, you can
view your current name server with the commandWINIPCFG.EXE (IPCONFIG for Windows 2000/XP). On
a UNIX machine, type nslookup along with your machine name. Any program on your machine that
needs to talk to a name server to resolve a domain name knows what name server to talk to because it
can get the IP address of your machine's name server from the operating system.

The browser therefore contacts its name server and says, "I need for you to convert a domain name to an
IP address for me." For example, if you type "www.howstuffworks.com" into your browser, the browser
needs to convert that URL into an IP address. The browser will hand "www.howstuffworks.com" to its
default name server and ask it to convert it.

The name server may already know the IP address for www.howstuffworks.com. That would be the case
if another request to resolve www.howstuffworks.com came in recently (name servers cache IP
addresses to speed things up). In that case, the name server can return the IP address immediately. Let's
assume, however, that the name server has to start from scratch.

A name server would start its search for an IP address by contacting one of the root name servers. The
root servers know the IP address for all of the name servers that handle the top-level domains. Your
name server would ask the root for www.howstuffworks.com, and the root would say (assuming no
caching), "I don't know the IP address for www.howstuffworks.com, but here's the IP address for the COM
name server." Obviously, these root servers are vital to this whole process, so:

• There are many of them scattered all over the planet.

• Every name server has a list of all of the known root servers. It contacts the first root server in
the list, and if that doesn't work it contacts the next one in the list, and so on.
Here is a typical list of root servers held by a typical name server:
; This file holds the information on root name servers
; needed to initialize cache of Internet domain name
; servers (e.g. reference this file in the
; "cache . " configuration file of BIND domain
: name servers).
;
; This file is made available by InterNIC registration
; services under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; End of File

The formatting is a little odd, but basically it shows you that the list contains the actual IP addresses of 13
different root servers.

The root server knows the IP addresses of the name servers handling the several hundred top-level
domains. It returns to your name server the IP address for a name server for the COM domain. Your
name server then sends a query to the COM name server asking it if it knows the IP address for
www.howstuffworks.com. The name server for the COM domain knows the IP addresses for the name
servers handling the HOWSTUFFWORKS.COM domain, so it returns those. Your name server then
contacts the name server for HOWSTUFFWORKS.COM and asks if it knows the IP address for
www.howstuffworks.com. It does, so it returns the IP address to your name server, which returns it to the
browser, which can then contact the server for www.howstuffworks.com to get a Web page.

One of the keys to making this work is redundancy. There are multiple name servers at every level, so if
one fails, there are others to handle the requests. There are, for example, three different machines
running name servers for HOWSTUFFWORKS.COM requests. All three would have to fail for there to be
a problem.

The other key is caching. Once a name server resolves a request, it caches all of the IP addresses it
receives. Once it has made a request to a root server for any COM domain, it knows the IP address for a
name server handling the COM domain, so it doesn't have to bug the root servers again for that
information. Name servers can do this for every request, and this caching helps to keep things from
bogging down.

Name servers do not cache forever, though. The caching has a component, called the Time To
Live (TTL), that controls how long a server will cache a piece of information. When the server receives an
IP address, it receives the TTL with it. The name server will cache the IP address for that period of time
(ranging from minutes to days) and then discard it. The TTL allows changes in name servers to
propagate. Not all name servers respect the TTL they receive, however. When HowStuffWorks moved its
machines over to new servers, it took three weeks for the transition to propagate throughout the Web. We
put a little tag that said "new server" in the upper left corner of the home page so people could tell
whether they were seeing the new or the old server during the transition.

Creating a New Domain Name

When someone wants to create a new domain, he or she has to do two things:
• Find a name server for the domain name to live on.
• Register the domain name.
Technically, there does not need to be a machine in the domain -- there just needs to be a name server
that can handle the requests for the domain name.

There are two ways to get a name server for a domain:

• You can create and administer it yourself.

• You can pay an ISP or hosting company to handle it for you.
Most larger companies have their own domain name servers. Most smaller companies pay someone.
The history of HowStuffWorks is typical. When howstuffworks.com was first created, it began as a parked
domain. This domain lived with a company calledwww.webhosting.com. Webhosting.com maintained the
name server and also maintained a machine that created the single "under construction" page for the
domain.

To create a domain, you fill out a form with a company that does domain name registration
(examples: register.com, verio.com, networksolutions.com). They create an "under construction page,"
create an entry in their name server, and submit the form's data into the whois database. Twice a day, the
COM, ORG, NET, etc. name servers get updates with the newest IP address information. At that point, a
domain exists and people can go see the "under construction" page.

HowStuffWorks then started publishing content under the domain www.howstuffworks.com. We set up a
hosting account with Tabnet (now part of Verio, Inc.), and Tabnet ran the DNS for HowStuffWorks as well
as the machine that hosted the HowStuffWorks Web pages. This type of machine is called a virtual Web
hosting machine and is capable of hosting multiple domains simultaneously. Five-hundred or so different
domains all shared the same processor.

As HowStuffWorks became more popular, it outgrew the virtual hosting machine and needed its own
server. At that point, we started maintaining our own machines dedicated to HowStuffWorks, and began
administering our own DNS. We currently have four servers:

• AUTH-NS1.HOWSTUFFWORKS.COM 70.42.150.19
• AUTH-NS2.HOWSTUFFWORKS.COM 70.42.150.20
• AUTH-NS3.HOWSTUFFWORKS.COM 70.42.251.19
• AUTH-NS4.HOWSTUFFWORKS.COM 70.42.251.20

Our primary DNS is auth-ns1.howstuffworks.com. Any changes we make to it propagate automatically

to the secondary, which is also maintained by our ISP.

All of these machines run name server software called BIND. BIND knows about all of the machines in
our domain through a text file on the main server that looks like this:
@ NS auth-ns1.howstuffworks.com.
@ NS auth-ns2.howstuffworks.com.
@ MX 10 mail

mail A 209.170.137.42

vip1 A 216.183.103.150
www CNAME vip1

Decoding this file from the top, you can see that:
• The first two lines point to the primary and secondary name servers.
• The next line is called the MX record. When you send e-mail to anyone at
howstuffworks.com, the piece of software sending the e-mail contacts the name server to get
the MX record so it knows where the SMTP server for HowStuffWorks is (see How E-mail
Works for details). Many larger systems have multiple machines handling incoming e-mail, and
therefore multiple MX records.
• The next line points to the machine that will handle a request to mail.howstuffworks.com.
• The next line points to the IP address that will handle a request to oak.howstuffworks.com.
 • The next line points to the IP address that will handle a request to howstuffworks.com (no
host name).

You can see from this file that there are several physical machines at separate IP addresses that make
up the HowStuffWorks server infrastructure. There are aliases for hosts like mail and www. There can be
aliases for anything. For example, there could be an entry in this file
for scoobydoo.howstuffworks.com, and it could point to the physical machine called walnut. There
could be an alias for yahoo.howstuffworks.com, and it could point to yahoo. There really is no limit to it.
We could also create multiple name servers and segment our domain.

As you can see from this description, DNS is a rather amazing distributed database. It handles billions of
requests for billions of names every day through a network of millions of name servers administered by
millions of people. Every time you send an e-mail message or view a URL, you are making requests to
multiple name servers scattered all over the globe. What's amazing is that the process is usually
completely invisible and extremely reliable!

What are the standard top-level domain names

and who controls them?
What are the standard top-level domain names and who controls them?

The article How Web Servers Work discusses the concept of domain names. "Howstuffworks.com" is a
domain name. The com portion of the name is called the top-level domain name. There is a very small
set of generic top-level domain names, which you will probably recognize:

• com - for commercial endeavors

• org - for non-profit organizations
• net - for network providers
• mil - for military organizations
• gov - for government organizations
• edu - for educational organizations
• info - for entities providing information services

There are also a number of top-level domain names for individual countries, including countries like
Canada (ca), Australia (au) and the United Kingdom (uk).

IANA, the Internet Assigned Numbers Association, provides world-wide management of the top-level
domain names. See the next page for more information and related links.

How CGI Scripting Works

Introduction to How CGI Scripting Works
The article How Web Pages Work discusses the basic features of HTML and shows you how to create
Web pages that contain text and graphics. It also shows you how to get your page "on the air" with a
hosting service. One of the questions frequently asked by new Web site designers once they get their site
up is, "What is CGI Scripting and how can I use it on my site?" or, "How do I create interactive forms on
my site?"
In this article, we will answer your questions about CGI scripting and show you how to create your own
scripts. You'll also learn a bit about Web servers in the process. Let's get started!

Web Servers
As described in the article How Web Servers Work, Web servers can be pretty simple. At their most
basic, Web servers simply retrieve a file off the disk and send it down the wire to the requesting browser.
Let's say you type in the URLhttp://www.bygpub.com/books/tg2rw/author.htm. The server gets a
request for the file /books/tg2rw/author.htm. If you look at the following figure, you can see how the
server resolves that request:

During setup, the Web server has been instructed to understand that c:\My Documents\www is the
server's root directory. It then looks for/books/tg2rw/author.htm off of that root. When you ask for the
URL http://www.bygpub.com/books/tg2rw/, the server understands that you are looking for the default
file for that directory. It looks for several different files names to try to find the default file: index.html,
index.htm, default.html, default.htm. Depending on the server, it may look for others as well. So the server
turns http://www.bygpub.com/books/tg2rw/ intohttp://www.bygpub.com/books/tg2rw/index.htm and
delivers that file. All other files must be specified by naming the files explicitly.

This is how all Web servers handle static files. Most Web servers also handle dynamic files -- through a
mechanism called the Common Gateway Interface, or CGI. You have seen CGI in all sorts of places on
the Web, although you may not have known it at the time. For example:

• Any guest book allows you to enter a message in an HTML form and then, the next time the
guest book is viewed, the page will contain your new entry.
• The WHOIS form at Network Solutions allows you to enter a domain name on a form, and the
page returned is different depending on the domain name entered.
• Any search engine lets you enter keywords on an HTML form, and then it dynamically creates
a page based on the keywords you enter.
All of these dynamic pages use CGI.

The CGI Mechanism

On most Web servers, the CGI mechanism has been standardized in the following way. In the normal
directory tree that the server considers to be the root, you create a subdirectory named cgi-bin. (You can
see this directory in the figure on the previous page.) The server then understands that any file requested
from the special cgi-bin directory should not simply be read and sent, but instead should be executed.
The output of the executed program is what it actually sent to the browser that requested the page. The
executable is generally either a pure executable, like the output of a C compiler, or it is a PERL script.
PERL is an extremely popular language for CGI scripting.

Imagine that you type the following URL into your browser: http://www.howstuffworks.com/cgi-
bin/search.pl. The server recognized that search.pl is in the cgi-bin directory, so it
executes search.pl (which is a PERL script) and sends the output from the execution to your browser.

You can write your own scripts and try out CGI yourself provided that:

• You know a programming language such as C or PERL.

• You have access to a Web server that handles CGI scripts. If you have paid a Web hosting
service to host your Web site, then chances are you have access to CGI scripting through your
host. Check with the hosting service for details. If not, then you can experiment by installing a
Web server on your home machine and learning to use it. The second option is a bit more
complicated, but you are guaranteed to learn a lot in the process!

Simple CGI Scripts

Assuming that you have access to a cgi-bin directory (see the previous section), and assuming that you
know either the C programming language or PERL, you can do a whole bunch of interesting experiments
with CGI to get your feet wet. Let's start by creating the simplest possible CGI script.

In the article How Web Pages Work, we examined the simplest possible HTML Web page. It looked
something like this:
<html>
<body>
<h1>Hello there!</h1>
</body>
</html>

The simplest possible CGI script would, upon execution, create this simple, static page as its output. Here
is how this CGI program would look if you wrote it in C:
#include <stdio.h>

int main()
{
printf("Content-type: text/html\n\n");
printf("<html>\n");
printf("<body>\n");
printf("<h1>Hello there!</h1>\n");
printf("</body>\n");
printf("</html>\n");
return 0;
}

On my Web server, I entered this program into the file simplest.c and then compiled it by saying:
gcc simplest.c -o simplest.cgi

(See How C Programming Works for details on compiling C programs.)

By placing simplest.cgi in the cgi-bin directory, it can be executed. You can try it out now by typing in or
clicking on this URL:http://www.howstuffworks.com/cgi-bin/simplest.cgi. As you can see, all that the script
does is generate a page that says, "Hello there!" The only part that is unexpected is the line that says:
printf("Content-type: text/html\n\n");

The line "Content-type: text/html\n\n" is special piece of text that must be the first thing sent to the
browser by any CGI script. As long as you remember to do that, everything will be fine. If you forget, the
browser will reject the output of the script.

You can do the same thing in PERL. Type this PERL code into a file named simplest.pl:
#! /usr/bin/perl
print "Content-type: text/html\n\n";
print "<html><body><h1>Hello World!";
print "</h1></body></html>\n";

Place the file into your cgi-bin directory. On a UNIX machine, it may help to also type:
chmod 755 simplest.pl

This tells UNIX that the script is executable. You can try it out now by typing in or clicking on this
URL: http://www.howstuffworks.com/cgi-bin/simplest.pl.

You have just seen the basic idea behind CGI scripting. It is really that simple! A program executes and
its output is sent to the browser that called the script. Normal output sent to stdout is what gets sent to the
browser.

The whole point of CGI scripting, however, is to create dynamic content -- each time the script executes,
the output should be different. After all, if the output is the same every time you run the script, then you
might as well use a static page. The following C program demonstrates very simple dynamic content:
#include <stdio.h>

int incrementcount()
{
FILE *f;
int i;

f=fopen("count.txt", "r+");
if (!f)
{
sleep(1);
f=fopen("count.txt", "r+");
if (!f)
return -1;
}

fscanf(f, "%d", &i);

i++;
fseek(f,0,SEEK_SET);
fprintf(f, "%d", i);
fclose(f);
return i;
}
int main()
{
printf("Content-type: text/html\n\n");
printf("<html>\n");
printf("<body>\n");
printf("<h1>The current count is: ")
printf("%d</h1>\n", incrementcount());
printf("</body>\n");
printf("</html>\n");
return 0;
}

With a text editor, type this program into a file named count.c. Compile it by typing:
gcc count.c -o count.cgi

Create another text file named count.txt and place a single zero in it. By
placing counter.cgi and count.txt in the cgi-bin directory, you can run the script. You can try it out now
by typing in or clicking on this URL: http://www.howstuffworks.com/cgi-bin/count.cgi. As you can see, all
that the script does is generate a page that says, "The current count is: X," where X increments once
each time you run the script. Try running it several times and watch the content of the page change!

The count.txt file holds the current count, and the little incrementcount() function is the function that
increments the count in the count.txt file. This function opens the count.txt file, reads the number from it,
increments the number and writes it back to the file. The function actually tries to open the file twice. It
does that just in case two people try to access the file simultaneously. It certainly is not a foolproof
technique, but for something this simple it works. If the file cannot be opened on the second attempt, -1 is
the error value returned to the caller. A more sophisticated program would recognize the -1 return value
and generate an appropriate error message.

Forms: Sending Input

We have seen that the creation of CGI scripts is pretty easy. The Web server executes any executable
placed in the cgi-bin directory, and any output that the executable sends to stdout appears in the browser
that called the script. Now what we need is a way to send input into a script. The normal way to send
input is to use an HTML form.

You see forms all over the Web. Any page where you have been able to type something in is a form. You
see them in search engines, guest books, questionnaires, etc. The home page for
HowStuffWorks.com contains at least two mini-forms, one for the "How did you get here?" sidebar and
one for the suggestions sidebar (yes, a single HTML page can contain multiple forms). You create the
form on your HTML page, and in the HTML tags for the form you specify the name of the CGI script to call
when the user clicks the Submit button on the form. The values that the user enters into the form are
packaged up and sent to the script, which can then use them in any way it likes.

You have actually been seeing this sort of thing constantly and may not have known that it was
happening. For example, go to http://www.lycos.com, type the word "test" into the "Search for:" box and
press the "Go Get It!" button. The URL of the result page will look like this:
http://www.lycos.com/cgi-bin/pursuit?matchmode=and
&cat=lycos&query=test&x=10&y=9

You can see that the Lycos home page is a form. Lycos has a script in the cgi-bin directory
named pursuit. The form sends five parameters to the script:
 1. matchmode=and
2. cat=lycos
3. query=test
4. x=10
5. y=9
The third one is the search string we entered. The other four mean something to the script as well. The
CGI script queries the Lycos database for the word "test" and then returns the results. That's the heart of
any search engine!

Let's create a simple form to try this out. Create a file named simpleform.htm and enter the following
HTML into it:
<html>
<body>
<h1>A super-simple form<h1>
<FORM METHOD=GET ACTION="http://www.howstuffworks.com/
cgi-bin/simpleform.cgi">
Enter Your Name:
<input name="Name" size=20 maxlength=50>
<P>
<INPUT TYPE=submit value="Submit">
<INPUT TYPE=reset value="Reset">
</FORM>
</body>
</html>

You can click on this URL to try it out: http://www.howstuffworks.com/simpleform.htm.

As you can see, the HTML code specifies the creation of a form that uses the GET method sent to the
CGI script at http://www.howstuffworks.com/cgi-bin/simpleform.cgi. Inside the form is a text input
area plus the standard Submit and Reset buttons.

The file http://www.howstuffworks.com/cgi-bin/simpleform.cgi referenced by the form is a C program.

It started life as this piece of C code placed in a file named simpleform.c:
#include <stdio.h>
#include <stdlib.h>

int main()
{
printf("Content-type: text/html\n\n");
printf("<html>\n");
printf("<body>\n");
printf("<h1>The value entered was: ")
printf("%s</h1>\n", getenv("QUERY_STRING"));
printf("</body>\n");
printf("</html>\n");
return 0;
}

It was compiled with the following command:

gcc simpleform.c -o simpleform.cgi

And it was placed in the cgi-bin directory. This program simply picks up the value sent by the form and
displays it. For example, you might see the following:
 The value entered was: Name=John+Smith

Name is the identifier for the text input field in the form (each input field on a form should have a unique
identifier), and John+Smith is a typical name that might be entered on the form. Note that the "+"
replaces the space character.

From this example, you can see that the basic process of setting up a form and getting data from a form
into a CGI script is fairly straightforward. Here are a couple of details to keep in mind:

• Each input field on the form should have a unique identifier.

• The form needs to use either the GET or the POST method. The GET method has the
advantage that you can see the form's values in the URL sent to the script, and that makes
debugging easier.
• There are definite limits to the number of characters that can be sent via the GET method, so
POST is preferred for large forms.
• Data that comes in via the GET method is received by looking at the QUERY_STRING
environment variable (usually read with the getenvfunction in C or the $ENV facility in PERL).
Data that comes in via the POST method is available through STDIN using gets in C or read in
PERL.
• The data that comes in is going to have all of the fields concatenated together in a single
string, and many characters will be substituted and therefore need translation. For example, all
spaces will be replaced with pluses.

The QUERY_STRING environment variable brings up the topic of environment variables in general.
There are a number of environment variables that you can examine in your CGI scripts, including:

• AUTH_TYPE
• CONTENT_LENGTH
• CONTENT_TYPE
• GATEWAY_INTERFACE
• HTTP_ACCEPT
• HTTP_USER_AGENT
• PATH_INFO
• PATH_TRANSLATED
• QUERY_STRING
• REMOTE_ADDR
• REMOTE_HOST
• REMOTE_IDENT
• REMOTE_USER
• REQUEST_METHOD
• SCRIPT_NAME
• SERVER_NAME
• SERVER_PORT
• SERVER_PROTOCOL
• SERVER_SOFTWARE

There are all sorts of interesting pieces of information buried in these environment variables, including the
length of the input string (CONTENT_LENGTH), the METHOD used (GET or POST --
REQUEST_METHOD lets you figure out whether to look in STDIN or QUERY_STRING for the input),
the IP address of the user's machine (REMOTE_ADDR), and so on. For complete descriptions of these
variables, see CGI Environment Variables.

Creating a Real Form

A real form is going to be made up of a variety of input areas, and it will require some amount of code in
the script to undo the character mappings and parse out the individual strings. Let's start by looking at the
standard input controls on a form. They include:
• Single-line text input
• Multi-line text input
• Selection lists
• Check boxes
• Radio buttons
• Specialized buttons for submitting or clearing the form
You can combine these controls with other static text and graphics as you would on any other page.

Here are several examples that demonstrate the use of the different control tags:

Single-line edit
The word "input" identifies a single line edit area. The "name" field provides an identifier for the control to
the CGI script and should be unique for each control on the form. The "size" field indicates the width, in
characters, of the input area on the form. "Maxlength" constrains the maximum number of characters in
the input area. "Value" sets an initial value.
Enter Name: <input name="Name" size=30 maxlength=50
value="Sample">

Typically, the input area is preceded by a piece of static text identifying the purpose of the input field.
Shown here is the static text "Enter name:".

You can add the value "type=int" to constrain input to integer values. By default, the type is "text" and it
accepts any characters.

Multi-line edit
A multi-line edit area is similar to a input area. You define a name for the control, and you define its size
on the form in rows and columns. Anything you put prior to the </textarea> tag will appear in the control
as a default value.
<textarea name="Company Address" cols=30
rows=4></textarea>

Check boxes
A check box is a specialized form of an input area with the type set to "checkbox".
<input type=checkbox name="Include" value=1>

The value will be returned if the checkbox is selected.

Radio buttons
Radio buttons are similar to check boxes, but they're grouped together visually:
Choose the search area:<br>
<input type=radio CHECKED name=universe value=US-STOCK>
Stocks
<input type=radio name=universe value=CA-STOCK>
Canadian Stocks
<input type=radio name=universe value=MMF>
Money Markets
<input type=radio name=universe value=MUTUAL>
Mutual Funds

Note that the default radio button can be marked with the word CHECKED. Also note that all radio buttons
in the same group have the same name.

Selection lists
A selection list offers the user a choice from a number of options. The tag for a selection list lets you
specify the number of visible rows in the "size" field, as well as the values for all of the options.
Select an Option<br>
<SELECT size=2 NAME="Option">
<OPTION> Option 1
<OPTION> Option 2
<OPTION> Option 3
<OPTION> Option 4
</SELECT>

The word MULTIPLE creates a multi-selection capability.

Specialized buttons
The following tags create two specialized buttons, one to submit the form to the server and one to reset
the form:
<INPUT TYPE=submit value="Submit">
<INPUT TYPE=reset value="Reset">

Putting It All Together

Let's say that you would like to create a simple questionnaire for one of your Web pages. For example,
you would like to ask for the reader's name, sex, age and comment, and then process it in a CGI script.
The HTML form might live in a file named http://www.howstuffworks.com/survey.htm and look like this:
<html>
<body>
<h1>HSW Survey Form<h1>
<FORM METHOD=POST ACTION="http:
//www.howstuffworks.com/cgi-bin/survey.cgi">
Enter Your Name:
<input name="Name" size=20 maxlength=50>
<P>Enter your sex:
<input type=radio CHECKED name=sex value=MALE>Male
<input type=radio name=sex value=FEMALE>Female
<P>Select your age<br>
<SELECT size=2 NAME=age>
<OPTION> 1-10
<OPTION> 11-20
<OPTION> 21-30
<OPTION> 31-40
<OPTION> 41-50
<OPTION> 51-60
<OPTION> 61 and up
</SELECT>
<P>Enter Your Comment:
<input name="Name" size=40 maxlength=100>
 <P>
<INPUT TYPE=submit value="Submit">
<INPUT TYPE=reset value="Reset">
</FORM>
</body>
</html>
The CGI script referenced by this form will receive four different pieces of data: the name, age, sex and
comment of the reader who submits the form. The script will have to parse out the four values and handle
all of the character transformations. A separate file called http://www.howstuffworks.com/survey.c was
used to create the script survey.cgi and is perhaps 100 lines long.

Summary
In this quick tour of CGI scripting, we have seen that:
• A CGI script is a program -- generally a C program or a PERL script.
• On most servers, CGI scripts live in a directory named cgi-bin. The script is executed when
the script's URL is requested by a browser.
• Anything that the script sends to STDOUT will be sent to the browser. The string "Content-
type: text/html\n\n" should be the first thing sent. After that, anything goes; but typically, valid
HTML tags for a valid HTML document are sent.
• Input is sent to the script by creating an HTML form whose ACTION specifies the script's URL.
• When a script receives the data from the form, it has to parse out the different strings and
convert all of the modified characters. We saw a simple C program that can perform these
tasks. The CGI library for PERL (see the next page) makes the conversion easy for PERL
scripts.
If you were doing this on a real Web site, you would typically store the results from each survey into a text
file or a database so that you could look at the results later. That's easy to do from either a C program or
a PERL script.

How Perl Works

Introduction to How PERL Works

Perl is a fairly straightforward, widely known and well-respected scripting language. It is used for a variety
of tasks (for example, you can use it to create the equivalent of DOS batch files or C shell scripts), but in
the context of Web development it is used to develop CGI scripts.

One of the nice things about Perl is that, because it is a scripting language, people give away source
code for their programs. This gives you the opportunity to learn Perl by example, and you can also
download and modify thousands of Perl scripts for your own use. One of the bad things about Perl is that
much of this free code is impossible to understand. Perl lends itself to an unbelievably cryptic style!

This article assumes that you already know how to program (if you know the C programming language,
this will be especially easy for you). Perl is easy to use once you know the basics. In this article, we're
going to start at the beginning and show you how to do the most common programming tasks using Perl.
By the end of this article, you will be able to write your own Perl scripts with relative ease, and read cryptic
scripts written by others with somewhat less ease, but this will be a good starting point.

Getting Started
To start with Perl you need the Perl interpreter. On any UNIX machine there is a 99.99-percent
probability that it's already there. On a Windows machine or a Mac, you need to download the latest
release of the language and install it on your machine. (See the links at the end of this article for more
information.) Perl is widely available on the Web and is free.

Next, make sure you look in the DOCS directory that comes with Perl -- there will be user-manual-type
stuff in there. At some point, it would not hurt to read through all of the documentation, or at least scan it.
Initially it will be cumbersome, but after reading this article it will make much more sense.

Hello World
Once you have Perl loaded, make sure you have your path properly set to include the Perl executable.
Then, open a text editor and create a text file. In the file, place the following line:
print "Hello World!\n";

Name the file "test1.pl". At the command prompt, type:

perl test1.pl

Perl will run and execute the code in the text file. You should see the words "Hello World!" printed to
stdout (standard out). As you can see, it is extremely easy to create and run programs in Perl. (If you are
using UNIX, you can place a comment like #! /usr/bin/perl on the first line, and then you will not have to
type the word "perl" at the command line.)

The print command prints things to stdout. The \n notation is a line feed. That would be more clear if you
modified the test program to look like this (#denotes a comment):
# Print on two lines
print "Hello\nWorld!\n";

Note that the print command understood that it should interpret the "\n" as a line feed and not as the literal
characters. The interpretation occurred not because of the print command, but because of the use of
double quotes (a practice called quoting in Perl). If you were to use single quotes instead, as in:
print 'Hello\nWorld!\n';

the \n character would not be interpreted but instead would be used literally.

There is also the backquote character: `. A pair of these imply that what is inside the quotes should be
interpreted as an operating system command, and that command should be executed with the output of
the command being printed. If you were to place inside the backquotes a command-line operation from
the operating system, it would execute. For example, on Windows NT you can say:
print `cmd /c dir`;

to run the DIR command and see a list of files from the current directory.

PERL Note
In Windows NT, you cannot say:
print `dir`;

because dir is not a separate executable -- it's part of

the command interpreter cmd. Type cmd /? at a DOS
prompt for details.

You will also see the / character used for quoting regular expressions.
The print command understands commas as separators. For example:
print 'hello', "\n", 'world!';

However, you will also see a period:

print 'hello'. "\n". 'world!';

The period is actually a string concatenation operator.

There is also a printf operator for C folks.

Variables
Variables are interesting in Perl. You do not declare them, and you always use a $ to denote them. They
come into existence at first use. For example:
$s = "Hello\nWorld\n";
$t = 'Hello\nWorld\n';
print $s, "\n", $t;

Or:
$i = 5;
$j = $i + 5;
print $i, "\t", $i + 1, "\t", $j; # \t = tab

Or:
$a = "Hello ";
$b = "World\n";
$c = $a . $b; # note use of . to concat strings
print $c;

Since . is string concatenation, .= has the expected meaning in the same way that "+=" does in C.
Therefore, you can say:
$a = "Hello ";
$b = "World\n";
$a .= $b;
print $a;

You can also create arrays:

@a = ('cat', 'dog', 'eel');
print @a, "\n";
print $#a, "\n"; # The value of the highest index, zero based
print $a[0], "\n";
print $a[0], $a[1], $a[2], "\n";

The $# notation gets the highest index in the array, equivalent to the number of elements in the array
minus 1. As in C, all arrays start indexing at zero.

You can also create hashes:

%h = ('dog', 'bark', 'cat', 'meow', 'eel', 'zap');
print "The dog says ", $h{'dog'};

Here, 'bark' is associated with the word 'dog', 'meow' with 'cat', and so on. A more expressive syntax for
the same declaration is:
 %h = (
dog => 'bark',
cat => 'meow',
eel => 'zap'
);

The => operator quotes the left string and acts as a comma.

Loops and Ifs

You can create a simple for loop like you do in C:
for ($i = 0; $i < 10; $i++)
{
print $i, "\n";
}
Perl Note
You must use the "begin" and
"end"braces -- { and } -- even for a
single line.

While statements are easy:

$i = 0;
while ( $i < 10 )
{
print $i, "\n";
$i++;
}

If statements are similarly easy:

for ($i = 0; $i < 10; $i++)
{
if ($i != 5)
{
print $i, "\n";
}
}

The boolean operators work like they do in C:

• && and
• || or
• ! not
• For numbers:
 == equal
 != not equal
 <, <=, >, >= (as expected)
• Others:
 eq
 ne
 lt
 le
 gt
  ge

If you have an array, you can loop through it easily with foreach:
@a = ('dog', 'cat', 'eel');
foreach $b (@a)
{
print $b, "\n";
}

Foreach takes each element of the array @a and places it in $b until @a is exhausted.

Functions
You create a subroutine with the word sub. All variables passed to the subroutine arrive in an array
called _. Therefore, the following code works:
show ('cat', 'dog', 'eel');

sub show
{
for ($i = 0; $i <= $#_; $i++)
{
print $_[$i], "\n";
}
}

Remember that $# returns the highest index in the array (the number of elements minus 1), so $#_ is the
number of parameters minus 1. If you like that sort of obtuseness, then you will love PERL.

You can declare local variables in a subroutine with the word local, as in:
sub xxx
{
local ($a, $b, $c)
...
}

You can also call a function using &, as in:

&show ('a', 'b', 'c');

The & symbol is required only when there is ambiguity, but some programmers use it all the time.

To return a value from a subroutine, use the keyword return.

Reading

Reading from STDIN

To read in data from the stdin (standard in), use the STDIN handle. For example:
print "Enter high number: ";
$i = <STDIN>;
for ($j = 0; $j <= $i; $j++)
{
print $j, "\n";
}
As long as you enter an integer number, this program will work as expected. <STDIN> reads a line at a
time. You can also use getc to read one character, as in:
$i = getc(STDIN);

Or use read:
read(STDIN, $i, 1);

The 1 in the third parameter to the read command is the length of the input to read.

Reading Environment Variables

PERL defines a global hash named ENV, and you can use it to retrieve the values of environment
variables. For example:
print $ENV{'PATH'};
PERL Note
The name of the environment
variable must be upper case.

Reading Command Line Arguments

PERL defines a global array ARGV, which contains any command line arguments passed to the
script. $#ARGV is the number of arguments passed minus 1,$ARGV[0] is the first argument
passed, $ARGV[1] is the second, and so on.

You should now be able to read and write simple Perl scripts.