Example 15-2. PP4E\Internet\Web\tutor0.html

A First HTML Page

Hello, HTML World!

I promised that I wouldn’t
teach much HTML in this book, but you need to know
enough to make sense of examples. In short, HTML is a descriptive
markup language, based on
tags
— items enclosed in
<>
pairs. Some tags stand
alone (e.g.,

For instance, to specify the text of a level-one header line, we
write HTML code of the form


text


It’s important to keep in mind that HTML is used only to
describe pages: your web browser reads it and translates its
description to a web page with headers, paragraphs, links, and the
like. Notably absent are both
layout
information
—the browser is responsible for arranging
components on the page—and syntax for
programming
logic
—
there are no
if
statements, loops, and so on.
Also, Python code is nowhere to be found in
Example 15-2
; raw HTML is strictly
for defining pages, not for coding programs or specifying all user
interface details.

HTML’s lack of user interface control and programmability is
both a strength and a weakness. It’s well suited to describing pages
and simple user interfaces at a high level. The browser, not you,
handles physically laying out the page on your screen. On the other
hand, HTML by itself does not directly support full-blown GUIs and
requires us to introduce CGI scripts (or other technologies such as
RIAs) to websites in order to add dynamic programmability to otherwise
static HTML.

Once you write an
HTML file, you need to put it somewhere a web browser
can reference it. If you are using the locally running Python web
server described earlier, this becomes trivial: use a URL of the form
http://localhost/file.html
to access web pages,
and
http://localhost/cgi-bin/file.py
to name CGI
scripts. This is implied by the fact that the web server script by
default serves pages and scripts from the directory in which it is
run.

On other servers, URLs may be more complex. Like all HTML files,
tutor0.html
must be stored in a directory on the
server machine, from which the resident web server program allows
browsers to fetch pages. For example, on the server used for the
second edition of this book, the page’s file must be stored in or
below the
public_html
directory of my personal
home directory—that is, somewhere in the directory tree rooted at
/home/lutz/public_html
. The
complete Unix pathname of this file on the server is:

/home/lutz/public_html/tutor0.html

This path is different from its
PP4E\Internet\Web
location in the book’s examples
distribution, as given in the example file listing’s title. When
referencing this file on the client, though, you must specify its
Internet address, sometimes called a URL, instead of a directory path
name. The following URL was used to load the remote page from the
server:

http://starship.python.net/~lutz/tutor0.html

The remote server maps this URL to the Unix pathname
automatically, in much the same way that the
http://localhost
resolves to the examples
directory containing the web server script for our locally-running
server. In general, URL strings like the one just listed are composed
as the concatenation of multiple parts:

To make sure we have a handle on URL syntax, let’s pick apart
another example that we will be using later in this chapter. In the
following HTTP protocol URL:

http://localhost:80/cgi-bin/languages.py?language=All

the components uniquely identify a server script to be run as
follows:

Although this covers most URLs you’re likely to encounter in the
wild, the full format of URLs is slightly richer:

protocol://networklocation/path;parameters?querystring#fragment

For instance, the
fragment
part may name a section within a page (e.g.,
#part1
). Moreover, each part can have
formats of its own, and some are not used in all protocols. The
;parameters
part is omitted for
HTTP, for instance (it gives an explicit file type for FTP), and the
networklocation
part may also
specify optional user login parameters for some protocol schemes (its
full format is
user:[email protected]:port
for FTP and Telnet,
but just
host:port
for HTTP). We
used a complex FTP URL in
Chapter 13
,
for example, which included a username and password, as well as a
binary file type (the server may guess if no type is given):

ftp://lutz:[email protected]/filename;type=i

We’ll ignore additional URL formatting rules here. If you’re
interested in more details, you might start by reading the
urllib.parse
module’s entry in Python’s library manual, as well as
its source code in the Python standard library. You may also notice
that a URL you type to access a page looks a bit different after the
page is fetched (spaces become
+
characters,
%
characters are added,
and so on). This is simply because browsers must also generally follow
URL escaping (i.e., translation) conventions, which we’ll explore
later in this
chapter.

Because
browsers remember the prior page’s Internet address,
URLs embedded in HTML files can often omit the protocol and server
names, as well as the file’s directory path. If missing, the browser
simply uses these components’ values from the last page’s address.
This minimal syntax works for URLs embedded in hyperlinks and for form
actions (we’ll meet forms later in this tutorial). For example, within
a page that was fetched from the directory
dirpath
on the server
http://www.server.com
, minimal hyperlinks and form
actions such as:

are treated exactly as if we had specified a complete URL with
explicit server and path components, like the following:

The first minimal URL refers to the file
more.html
on the same server and in the same
directory from which the page containing this hyperlink was fetched;
it is expanded to a complete URL within the browser. URLs can also
employ Unix-style relative path syntax in the file path component. A
hyperlink tag like
HREF="../spam.gif">
, for instance, names a GIF file on
the server machine and parent directory of the file that contains this
link’s URL.

Why all the fuss about shorter URLs? Besides extending the life
of your keyboard and eyesight, the main advantage of such minimal URLs
is that they don’t need to be changed if you ever move your pages to a
new directory or server—the server and path are inferred when the page
is used; they are not hardcoded into its HTML. The flipside of this
can be fairly painful: examples that do include explicit site names
and pathnames in URLs embedded within HTML code cannot be copied to
other servers without source code changes. Scripts and special HTML
tags can help here, but editing source code can be error-prone.

The downside of minimal URLs is that they don’t trigger
automatic Internet connections when followed offline. This becomes
apparent only when you load pages from local files on your computer.
For example, we can generally open HTML pages without connecting to
the Internet at all by pointing a web browser to a page’s file that
lives on the local machine (e.g., by clicking on its file icon). When
browsing a page locally like this, following a fully specified URL
makes the browser automatically connect to the Internet to fetch the
referenced page or script. Minimal URLs, though, are opened on the
local machine again; usually, the browser simply displays the
referenced page or script’s source code.

The net effect is that minimal URLs are more portable, but they
tend to work better when running all pages live on the Internet (or
served up by a locally running web server). To make them easier to
work with, the examples in this book will often omit the server and
path components in URLs they contain. In this book, to derive a page
or script’s true URL from a minimal URL, imagine that the
string:

http://localhost/

appears before the filename given by the URL. Your browser will,
even if you don’t.