Introduction to Static-Page Servers

This section of the Pagemasters' Toolbox describes the use of the new "static-page" servers. We call them that because pages on these servers are pre-built by the pagemaster on his or her disk drive, and then uploaded to the server's disk drives, where they are immediately available when requested. They are not created by server software at the time they are requested (".CFM," ".PHP," and ".ASP" pages, on the other hand, are assembled -- "dynamically" -- when they are requested).

As you work your way through these pages, you will notice what may seem to be peculiar choices of filenames: there is a chap1.html and a chap3.html, but no chap2.html, and there is an append1.html and an append3.html, but no append2.html. That is because these pages are based closely on the pages that were originally published when the static-page server (then www.ohiou.edu) was using the VMS operating system, and pagemasters routinely had full-access accounts on that general-purpose, time-sharing system, so we documented non-web features, too.

We have now permanently retired the old server, after migrating all pages from that server to the new static-page server (ww2.ohio.edu -- "ww2," for short), which is a dedicated web server, running a different operating system. Therefore we do not need those materials, and have retired those other pages. More information is available on the transition process.

With the new static-page server, we have moved to an environment in which all Front Door pages will be seen by our audiences as coming from www.ohio.edu, rather than coming from a mixture of servers with a variety of names (e.g., www.ohio.edu, www.ohiou.edu, www.cats.ohiou.edu, cscwww.cats.ohiou.edu, etc.). In particular, this immediately includes all pages published through the CommonSpot Content Management System and all pages published on the new static-page server. As new Front Door services are brought online, using other servers, they, too, will be seen with the uniform name of www.ohio.edu.

This is achieved by placing the Front Door servers, including the new static-page server and the CommonSpot servers, behind a load balancer that steers requests based on the subsite or sub-subsite that the URL specifies.

The new static-page server is "ww2.ohio.edu" -- you will use that name to upload your files to it, and it is "www.ohio.edu" -- because that is how the pages are seen by the world.

When a browser on the campus or public internet requests a page from www.ohiou.edu (or www.cats.ohiou, or cscwww.cats.ohiou.edu), that request goes directly to a server that is configured to redirect the browser to www.ohio.edu for pages that are published from CommonSpot or the new static-page server, to redirect the browser to another appropriate location for pages that are published by other servers, and to generate a "404" error for any other requests.

When a browser on the campus or public internet requests a page from www.ohio.edu, that request comes to the load balancer, which is configured to use the path and filename part of the URL to select the server to request a response from. The following examples cover the two major alternatives:

• http://www.ohio.edu/offices/ pages come from any one of the three CommonSpot Read-Only Public Servers ("ROPS") -- the load balancer picks a different one each time; they are displayed with the uniform URL;

• http://www.ohio.edu/policy/ pages come from the new static-page production server; they are displayed with the uniform URL.

The staging server, wws2, is configured identically to the production server, ww2, except for the name and the fact that it requires OAK authentication to browse the pages; it is used two ways:

• When you are replacing an existing subsite with a new one on ww2, before your new pages are "in production": at that early stage, the load balancer does not yet steer requests for your pages to ww2; instead, it redirects the browser to ask for them from wherever they have been published. That means that you cannot tell whether you have correctly uploaded the files, to be sure that they will display properly. Instead, you first upload them to wws2. The load balancer is configured to pass requests that specify wws2 to that server, so you will be able to inspect your pages. Once you have confirmed that your uploading method is working correctly, OIT staff transfer the files directly from wws2 to ww2, and then we change the configuration so that the world sees the pages from the new server. From then on, you can just upload directly to ww2.

• If you are creating a new subsite, pages uploaded to ww2 will be immediately visible at their www.ohio.edu address. If you work on wws2, then you can assemble the full subsite, or at least enough to be proper to go public, before uploading the files to ww2. At any later time (for example, if you were preparing to introduce a radically revised version of a group of your pages; if you wanted to test out a custom search of your subsite based on the new GSA; or if you wanted to test out the new MAILER script), you can use the staging server for final experimentation and review by collaborators. Then upload the files to ww2, when you are satisfied.

The two primary reasons for requiring authentication on the staging server are:

• to prevent search engines from leading people to outdated pages -- we do not expect pagemasters to update the staging server once their new pages are in production; and

• to warn people who do look at the pages that their content is likely out-of-date.

Most browsers will object to a certificate mismatch when you first look at a page on the staging server; that is because the load balancer certificate is for www.ohio.edu, but you are looking at wws2.ohio.edu -- no problem, just tell the browser to accept the certificate.

In summary, with the old static-page server, you uploaded your files (with FTP) to "www.ohiou.edu," and your audience saw them at "http://www.ohiou.edu/" (or "http://www.cats.ohiou.edu/" or "http://cscwww.cats.ohiou.edu/"). With the new static-page server, you upload your files (with SFTP) to "ww2.ohio.edu," but your audience sees them uniformly at "http://www.ohio.edu/."

Maintaining Your Files

As a static-page server, you prepare the files ahead of time on your personal computer's disk, and then upload them. There are three approaches you can use to maintaining your HTML files:

1. You can modify the HTML directly, using a general-purpose text editor. On Windows, you can use Wordpad or Notepad; on Macintosh, you can use TextEdit.

2. You can use general-purpose word processing software that has been enhanced with the ability to "save as HTML." On Windows, you could use Word 2007; on Macintosh, you could use Word 2008.

3. You can use dedicated HTML-editing software, which uses a graphical user interface and gives you a preview display of the page ("what you see is what you get"). In this category, DreamWeaver is available for both Windows and Macintosh.

The first method requires a greater investment in learning HTML tags and their attributes, but gives you more control over the resulting code. The second method permits you to do most of your work in an environment you are already comfortable with. The third method requires that you learn a new software package, but does not require that you learn HTML.

With all three approaches, you create your files on your personal computer, preview your work without making it public, and then upload the files to the server. With all three methods, you are vulnerable to variations among browsers, and with the latter two methods you are vulnerable to the assumptions your software vendor made about the browser choices your readers will make.

This Guide includes instructions for people who use all of these approaches. It does not focus on the HTML itself, nor on the preparation of non-HTML files (GIF, JPEG, etc.).

As indicated by the Table of Contents, this Guide addresses primarily mechanical aspects, such as file name choices and file transfer methods. This guide does not address general issues of HTML use, style, or content for web publishing, except for section D of Chapter I (which presents our expectations for basic content standards); a short bibliography (URLs and books) in Appendix I; and Appendix VI (which focuses on functional design). This Guide does not address basic concepts of the web or internet.