What's the name of the alias you have set up for /www/citcgidev? You need to use that and not the physical path to the file.
Based on the httpd.conf you posted a couple of weeks ago, this directory isn't accessible to the HTTP server and shouldn't be since the sub-directories under it contain things like your httpd.conf and log files. The configuration file you posted has the document root set to /cgidev/conf/htdocs so you need put the image in that directory and remove "/www/citcgidev" from the background attribute of your body tag.
What's happening is that the server is appending "www/citcgidev/backg.gif" to the physical path you have for the document root (/cgidev/conf/hotdocs) which means it's looking for the path /cgidev/conf/hotdocs/www/citcgidev/backg.gif which doesn't actually exist which results in a 404 error. In fact, if you look in your error log, you should see this path in it.
Also, your httpd.conf appears to be needlessly complex (I don't know how much of that is related to CGIDEV2 since I don't use that tool) which happens when you are learning. The first couple of sites I set up where disasters from a configuration and maintenance point of view. I think you're at the point where you really need to get an understanding of what's going on and then come up with a strategy that will help you keep things organized. I'm technically responsible (i.e. the webmaster) for several B2B sites that are functionally the same but are broken up by market channel and I use a lot of virtual sites (both name and IP based). With that in mind, here's how I organize things:
* I have a master directory that contains subdirectories for each virtual site. Let's call it /websites. I don't store any web pages or images in the htdocs folder created by the wizard.
* Under that directory, I create another directory for each site. Let's call them retail and oem. Under those directories, I create directories for images, css files, and whatever else I need them for.
* Under the master directory, I have other directories for shared things like css files and images.
* I create libraries for my CGI programs that are grouped by very high level functionality. Let's stick with CGIBIN.
You are not doing virtual hosting at this point so lets get rid of the extra stuff you don't need. I will submit that it's a good idea to still use a similar structure since it's possible you'll end up needing to do that in the future so let's using this structure:
As a basis for redoing your httpd.conf, remove all of the directory, location, and let's build from that.
The first thing you need to do is define what the server is allowed to access. First rule is you never want it to be able to access the root folder of the IFS since that lets it access everything on your system. You do that with this:
<Directory />
order deny,allow
deny from all
</Directory>
The next thing is you need to access your static HTML pages and image so we need to add Directory directive for that and set the document root (this is an implied alias of /). Add the following:
DocumentRoot /websites/citationcorp
<Directory /websites/citationcorp>
order allow,deny
allow from all
</Directory>
By default, the web server will be able to access everything under /websites/citationcorp. Also, by convention, DocumentRoot is typically in httpd.conf before any other file related directives but it doesn't have to be. Also, we don't want people to have to type in the name of the default web page so let's add a directive to set in to index.html (it can be called anything and you can define multiples by specifying a space separated list):
DirectoryIndex index.html
To allow your CGI programs, you'll need to add a directory for them and also tell the web server that things in that directory can be executed. Here are examples of doing that:
<Directory /qsys.lib/cgibin.lib>
order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /qsys.lib/cgibin.lib/
You can also set options in the directory (having it at the global level like you have is bad from a security standpoint) but to me, it's easier to understand using ScriptAlias.
With this set up, the web server will only allow access to things in /websites/citationcorp (static stuff) and /qsys.lib/cgibin.lib (cgi programs). If you have a CGI program called HELLOCGI in library CGIBIN, you'd use this URI (URI is the URL less the protocol and host name): /cgi-bin/hellocgi.pgm. Images would be /images/mypic.gif and the default document would be /.
Once you have this working, you can add all of the stuff CGIDEV2 needs back in. You can combine a lot of the rules that you have using rewrite rules. You should also be away that storing HTML in members performs poorly and for real applications, you should stay away from them. Also, any items in the IFS that the CGI programs access internally (such as CGIDEV2's templates) do not need to be defined to the web server. You only need to define things that can be directly accessed by a browser.
Matt
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Terry Anderson
Sent: Wednesday, November 28, 2007 12:49 PM
To: WEB400@xxxxxxxxxxxx
Subject: [WEB400] URI in request is not valid
Greetings List,
I am getting the following error when trying to display an image on my web page using CGIDEV2:
URI in request GET /www/citcgidev/backg.gif HTTP/1.1 is not valid. I am guessing that the error means that the image can't be found.
However, when I run the command: wrklnk '/www/citcgidev/backg.gif' from the command line, I go right to the file on the IFS.
According to the HTML book I have, this should work. Can someone tell me what I am doing wrong? Do I need to add something to the config file that tells CGIDEV2 where images are stored?
Thanks,
Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
