HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

S-HTTP is not widely supported and in particular is not supported by Netscape Navigator or Microsoft Internet Explorer.

Security Enhanced Transactions—SET

Financial transactions over the Web require additional levels of encryption and authentication, to allow users to send credit information—or even digital money—over the network safely and reliably. Visa and MasterCard, in association with Microsoft, Netscape, and others, are developing a secure transaction technology called SET. This scheme will allow for secure use of credit cards on the Net, with automatic validation of the card information and debiting of the transaction from the user’s account—Using SET, users will never need to give their actual credit card number to the merchant from whom they are buying a product or service. Other efforts are underway to develop digital cash—the ability to send real money, in digital format, over a computer network. These technologies are in the development and testing stages and are likely to be deployed sometime over the next two years. The references section at the end of this chapter provides links to additional readings on these subjects.

Proxy Servers and Server Caching

Proxy servers are often used by local area networks (LANs) who want to protect their network from unauthorized entry via the Internet. Such protection can be accomplished by installing firewall software on the gateway machine that links the local network to the outside world. A firewall keeps TCP/IP packets from entering the local network from outside and thereby protects the LAN from intruders.

Unfortunately, a firewall means that users inside the LAN cannot access WWW resources outside the LAN, since incoming data are blocked at the firewall. The solution is to install a proxy server on the firewall, and to configure the users’ Web browsers to refer all outgoing requests to the proxy server instead of to the real servers outside the LAN. A proxy server has access to both the inside and outside worlds and can safely pass information back and forth across the firewall. When a browser wants to request information from outside the firewall, it instead sends the request to the proxy server on the firewall. The proxy server then proxies the request—that is, it makes the request on the user’s behalf and returns the proxied results.

This two-stage process can be slow. To speed up service, proxy servers can cache retrieved files. Thus, the first time a user requests a document, the server goes to the outside world and fetches it. But, the server then keeps a copy of the file on its own local disk. If a user then makes a subsequent request for the same file, the proxy server returns the locally cached copy and does not need to access the original server to re-fetch it. This saves time and can also significantly reduce the load on the network connection.

This can be a problem, however, if the file changes with time. This is the case for pages containing periodically updated data, or for documents created dynamically by CGI programs: Obviously, such files either should not be cached or should be removed from the cache after some fixed time. With HTTP 1.0, these problems are mitigated somewhat by using Expires and pragma server response header fields. Expires contains an expiry time and date (in one of the standard time/date formats described at the end of this chapter), which tells a proxy server (or a browser) how long it can keep a cached copy of a document before it expires and should be discarded or replaced. An even stronger statement is made by the Pragma field, which takes the form:

Pragma: no-cache

When a client (or a proxy server) sends a request header containing this field to a server, the targeted server must always access a new copy of the requested URL and can never use a cached version. This ensures that the requesting client always gets the most up-to-date version, regardless of which proxy server(s) the requests pass through.

Finally, most servers do not send a last-modified header for documents that should not be cached. A browser that retrieves a document that does not contain a last-modified header field will assume that the document is not cacheable and will not save a local copy. For example, dynamic, rapidly changing documents generated by CGI programs are often sent to a browser without a last-modified header field, so that the browser will always contact the server for a fresh copy of the document.

For a variety of reasons, HTTP 1.0 is very poor at handling proxy transactions and the proper maintenance of cached files. Indeed, HTTP 1.1 contains a number of protocol enhancements designed to make proxy-server caching more effective, efficient, and reliable. You are referred to the references at the end of the chapter for additional information on this subject.

HTTP Proxy Servers

There are two ways of implementing proxy support. The first is to use an HTTP server that has proxying and caching capabilities. Several commercial HTTP servers from Netscape, Microsoft, and others support proxying and caching, as does the freeware Apache server. A second alternative is to use the Squid cache, which is a caching proxy server that can handle HTTP, FTP, and NNTP transactions. URLs referencing these different packages are provided at the end of the chapter, should you be interested in further investigating these options.

SOCKS Proxy Support

An alternative is to employ a general-purpose Internet proxying package. Many such packages are available commercially, from various firewall and software security vendors. A useful, freeware alternative is the package known as SOCKS. SOCKS does not have caching capabilities and ignores all the HTTP header messages relevant to proxy HTTP servers. However, SOCKS is a useful choice if you do not need an HTTP server, and is significantly easier to implement and maintain than a full caching, proxy server. A further advantage for a secure environment is that SOCKS can proxy all standard Internet protocols, including FTP, NNTP, Telnet, and others. Additional information about SOCKS is found at:

ftp://ftp.nec.com/pub/socks/

A proxy server is of course useful only if a browser can be configured to use it. Today, almost all browsers have this capability.

Format Negotiation

The last topic for this chapter is format negotiation. As mentioned in the discussion of accept request headers, a client can send information to a server explaining the types of data it prefers and the order of preference. The example request headers given were

Accept: image/*
Accept: image/jpeg; q=0.7; mxb=50000
Accept: image/gif; q=0.5

which indicates a preference for image/jpeg files, provided they are smaller than 50 KB; followed by GIFs (if the JPEGs are too big), followed by any format of image if the first two are unavailable. However, the HTTP requests described in this chapter were directed at specific files and not a collection. So, how can a server be configured to return alternative format-versions of the same resource?