#### "Linux Gazette...making Linux just a little more fun!"

# The Answer Guy

#### By James T. Dennis, linux-questions-only@ssc.com
Starshine Technical Services, http://www.starshine.org/

### Executing "Normal HTML" Files with Apache

From ajrlly on 26 Sep 1998

is there a way to configure apache so that when someone requests a particular page (ie http://www.whatever.com/~user/index.html) that a cgi script is automatically invoked, transparent to the requestor. The goal is to have a diff page served depending on the ip address.

thnx

> I think you could use the "x-bit hack" feature --- mark the index.html page as a Unix/Linux "executable" and use SSI (server-side include) directives to accomplish this.

> There are also various modules for Apache to support XSSI (extended server-side includes) ePerl and EmbPerl (embedded perl interpreters which execute code your documents), and other forms of dynamic output.

> For real details you should probably read the FAQ --- try http://www.apache.org for access to that.

> In addition that FAQ recommends the comp.infosystems.www.servers.unix newsgroup for general support. There are also a couple of companies that offer commercial support for the system.

> You can read about new developments in Apache by regularly visiting the Apache Week web site (http://www.apacheweek.com) Which should probably be right next to "Linux Weekly News" http://www.lwn.net, on your lists of weekly sites to visit.

> Unfortunately they don't seem to have an "answer guy" over at Apache Week --- so we can't forward your question off to him.

> Personally I don't like the idea of publishing different "apparently static" web pages based on the IP address of the requestor. First it seems deceitful. Also IP addresses and DNS domains (reverse or otherwise) are very poor ways of identifying users or readership. In addition these sorts of "dynamic" pages put extra load on the server and add additional latency to the request. This is a particularly bad idea for index.html pages --- which are the most often accessed.

> I think it is best to identify what you really want the world to see (a process of writing, composition and publication) and put that into your main static web pages. If you need timely or periodic updates (web counters, whatever) use a cron job to periodically re "make" to static pages from their "sources" (templates) using the text processing tool of your choice (m4 and the C preprocessor, cpp seem to be particularly popular for this, although many specialized tools exist for the task).

> Part of this also depends on what you really trying to do. For example if you want "internal" users to see one set of pages and "external" users to see another --- you best bet is to configure your server with two interfaces (or at least IP aliases) and use the Apache "Bind" directive to bind one copy of the Apache server to one IP address/interface and a different one (with different configuration, document root, etc) on the other).

> Naturally each of your virtual hosts ("soft" using HTTP 1.1 features, or "hard" requiring separate IP addresses) can have completely different document roots and many other configuration differences. All of that falls under the category of "virtual hosting" and is covered pretty extensively in the Apache documentation (which is all avialable at the aforementioned web sites).

> If you're trying to provide information in a different language or format based on the source of the request you should read about "Content Negotiation" at:

Apache Week: 26th July 1996
  http://www.apacheweek.com/issues/96-07-26

> If you're attempting to do this based on "security" or "cookies" there extensive methods for doing this supported by Apache -- and most of them are most easily accomplished by performing "redirection" as the connection is established.

> For real security --- to provide web pages to your "extranet" partners (strategic customers, vendors, etc) and your mobile employees --- I wouldn't suggest anything less then "client side certificates" over SSL (secure sockets layer --- a set of encryption protocols, proposed by Netscape and implemented by many browsers and in several other packages. The dominant "free" SSL code base is SSLeay --- by Eric A. Young of Australia).

> These sorts of certificates are issued to users on and individual basis (they can be from a recognized third party CA --- certifying authority --- or you can create your own "in-house" CA and accept those, exclusively or otherwise.

> There are a large number of modules available for Apache, some to things like block access based on the "Referrer" value (to prevent other web sites from using your pictures and bandwidth by "reference", for example), or to fix UpperVSLOWER/CasING/ problems in the requeste URL's, and a couple of different ones to perform rewriting of request URL's --- like the mod_rewrite module which supports full regex re-writes and some weird conditional and variable assignment features.

> It appears that the "official" place to learn about Apache modules seems to be the "Module Registry" at http://www.zyzzyva.com

[ It moved to http://modules.apache.org/ which is much easier to remember too. Update your bookmarks, everybody -- Heather ]

##### Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 34 November 1998

| apache | current | digi | ether | goodtimes | intlX | largedisk
maybe | numlock | quota | recovery | script | serial | session
sound | tape | testsuite | w95ie | w95ras | w95virus | xdm