SWS 1-3-1 - vs. 2.1-1

[Willem Grooters]

Now for something completely different ;-)

We have our web-application running on diferrent machines running SWS (apache) 1.3-1, and part of this is creating dynamic output by URL http:////GATEWAY//?
The paths has been defined in HTTPD.CONF:

DocumentRoot "/apache$common/ot"
Scriptalias path "/apache$common/ot/path"

and that works fine.

Now on another machine, I installed the web-application and SWS 2.1, and set up the server accoring the first mentioned machine:

DocumentRoot "/apache$common/ot"
Scriptalias path "/apache$common/ot/path"

So you would expect that URL URL http:////GATEWAY//? would work - but is doesn't: Page not found. However, Adding .COM makes a difference: URL http:////GATEWAY.COM//? does actually work. To my surprise: URL http:///cgi-bin/Test_cgi-vms has no problems.

A second issue: both the static and dymanic content use a stylesheet:
.
SWS 1.3-1 has no problem with that, but 2.1-1 fails to recognize this. Again, the specification on the paths is equal between SWS 1.3-1 and 2.1-1. (I know that SWS 2.1 works fine as well here - from my own server)

Just two differences:
* on the SWS 1.3-1 machine, all files are owned by APACHE$WWW, and the root of the web application is fully within APCHE$COMMON.
* On the SWS 2.1-1 machine, all files are owned by another user but protection is W:RE on all files. Second, the webappliaction is stored separate, from the server, but the root-directory is alaised in APACHE$COMMON (SET FILE root.dir /ENTER=APACHE$COMMON:[000000]root.dir).

As far as I know, these two environments are now logically equal.

Both issues are quite annoying; we need to get this solved before we can test the whole application against VMS 8.2

[Jiri_5]

hi,

did you run after instalation apache$config.com? We upgrade from v 1.3 to v 2.1 and owner of files is apache$www.


PRC040> @sys$startup:APACHE$CONFIG.COM;

HP Secure Web Server for OpenVMS Alpha
[based on Apache]

This procedure helps you define the operating environment required to run the Secure Web Server on this system.

To operate successfully, the server processes must have read access to the installed files and read-write access to certain other files and directories. HP recommends that you use this procedure to set the owner UIC on the CSWS files and directories to match the server. You should do this each time the product is installed, but it only has to be done once for each installation on a cluster.

Set owner UIC on CSWS files? [YES]


Jirza

[Willem Grooters]

Jiri,

On other machines, we still use 1.3 or 1.3-1 and of course we ran the installtion script following all settings.
In this case however, we cannot do that since we run OSU and WASD as well (concurently) for testing purposes. So settting ownership to APACHE$WWW (or any server-specific user) is out of the question. Setting basic protection to W:RE would do, and proved to be sufficient. Since it's a closed LAN, we don't bother about server-specific ACE protection which would be preferrable.

[Willem Grooters]

Forgot to mention: this is a fresh installation and I've done all the required post-update tasks, before ading the application directory to APACHE$COMMON. Ownership and protection of these files is correct since the other webservers work fine with the current settings. SWS accepts them too so that is no problem.

[Willem Grooters]

CGI-issue solved....Cut&Paste error, so easily overlooked.....
.conf reads:

ScriptAlias /ot-cgi/bps "apache$root/ot/bps/cgi-bin/bps"
and should have been:
ScriptAlias /ot-cgi/bps/ "apache$common/ot/bps/cgi-bin/bps/"

and the directory should hold the same change.

Now it works - even without ".COM"

Remains the stylesheet problem...

[Willem Grooters]

When I opeend the stylesheet directly in the URL, (http:////, both OSU and WASD deliver the whole file, where SWS gave me the part until the first empty line.
Solution is simple: remove the blank lines in the stylesheet. But this is just a work-around. I have asked a collegue that is more aquainted to the web standards and he confimed this behaviour is NON-STANDARD and so I would consider it a bug in SWS 2.1-1.