Forum

Hi,

I have installed Hiawatha 6.9. My application runs perfectly with defualt port (80). When I change the port number the application fails to run...:(

Can someone help me out on this? I badly neeed to make it run on some port other than 80......Please reply ASAP

You say it runs fine on port 80, which proofs that Hiawatha works fine. It seems that it's something in your webapplication. I need more information about the webapplication you are running. So, please give all the information about it you can.

Hi Hugo,

I appreciate your quick reply...:)..Thanks a lot..

I'm sorry I can't dosclose the details about the web application!!!Give me time to get confirmation from my officials if I can do so..

Till then, please lemme know regarding
1. The configurations settings to be done to change the port number. Is httpd.conf, the only file to be changed?

2. Using default port number, I'm executing an exe file (placed at C:/wwwroot/cgi-bin/123.exe), URL does not load the webpage unless .exe is specified (i.e) Web page gets loaded with http://localhost/cgi-bin/123.exe and not http://localhost/cgi-bin/123.
Can this be handled somewhere in the conf files?

If I run my application on 80 or other port number, the other webservers (Apache, Abyss, Web/2, Key Focus) respond, then why not Hiawatha...will get back to you again with further details if possible..:?

Hi again...

I'm allowed to only give the brief architecture overview of the application...

We have 3 components:
1. Component 1 is a Daemon Process - daemon.exe

daemon.exe - installed as a service that scans the file system.
This has its own conf file called daemon.conf, that holds two parameters File System Path to scan and Daemon Port Number(can be any value)

2. Components 2 and 3 are two cgi components - a1.exe and a2.exe

a1.exe and a2.exe - These require a conf file called a.conf. And the three (a1.exe , a2.exe and a.conf) need to placed in server cgi-bin directory.

a.conf ---- This holds the 3 parameters HttpdHost(IP address of the machine),
HttpdPort(as in server conf file) and Daemon PortNumber (as in daemon.conf)

The two cgi components send request to daemon process via web server, and then the corresponding pages from the file system are loaded.

So we take any web server change the port number in server conf file; specify the same in HttpdPort of a.conf, say 1234. Then give the URL: http:/localhost:1234/cgi-bin/a1 or http:/localhost:1234/cgi-bin/a1.exe and start using the application.
[We always/mostly prefer not to specify the .exe in the URL, can we get this behaviour in Hiawatha?]

I have provided almost all the information. Waiting for your reply...

Yes. If you want to run the webserver on, for example port 90, all you have to do is:

Binding {
    Port = 90
}

It isn't that weird the pages without .exe don't load because the file you request doesn't exist. You can solve this issue via URL rewriting.

VirtualHost {
    ...
    UseToolkit = loadexe
}

UrlToolkit {
    ToolkitID = loadexe
    RequestURI exists Return
    Match \. Return
    Match (.*) Rewrite $1.exe
}

About the rewrite: it can be made specific for your application:

UrlToolkit {
    ToolkitID = loadexe
    Match ^/cgi-bin/(a[12])(.*) Rewrite /cgi-bin/$1.exe$2
}

(note: I haven't been able to test this config, so if it's not working, let me know)


The daemon.exe is not the issue I think. If I understand your post correctly, it doesn't communicate with Hiawatha directly. Only a1.exe and a2.exe do via CGI. Can you tell me what you see in your browser when you request those CGI programs?

Hi Hugo,

Check the behaviour in different scenarios:

GENERIC:
UrlToolkit {
ToolkitID = loadexe
RequestURI exists Return
Match \. Return
Match (.*) Rewrite $1.exe
}
URL: http://localhost/cgi-bin/a1: loads the page
URL: http://localhost/cgi-bin/a1.exe: loads the page

Scenario1:
UrlToolkit {
ToolkitID = loadexe
Match ^/cgi-bin/(a[12])(.*) Rewrite /cgi-bin/$1.exe$2
}
URL: http://localhost/cgi-bin/a1: webpage not found error
URL: http://localhost/cgi-bin/a1.exe: loads the page

Scenario2:
UrlToolkit {
ToolkitID = loadexe
Match ^/cgi-bin/(.*) Rewrite /cgi-bin/$1.exe$2
}
URL: http://localhost/cgi-bin/a1: Error messages specific to my application.
URL: http://localhost/cgi-bin/a1.exe: webpage cannot be found

Scenario3:
UrlToolkit {
ToolkitID = loadexe
RequestURI exists Return
Match \. Return
Match ^/cgi-bin/(a[12])(.*) Rewrite /cgi-bin/$1.exe$2
}
URL: http://localhost/cgi-bin/a1: webpage not found error
URL: http://localhost/cgi-bin/a1.exe: loads the page

Scenario4:
UrlToolkit {
ToolkitID = loadexe
RequestURI exists Return
Match \. Return
Match ^/cgi-bin/(.*) Rewrite /cgi-bin/$1.exe$2
}
URL: http://localhost/cgi-bin/a1: loads the page
URL: http://localhost/cgi-bin/a1.exe: loads the page

Generic or Scenario4 behaviour will suffice for me, but again can we have a refinement:
In either of the scenarios(generic or scenario4) the homepage gets loaded but URLS in the homepage are getting modified(i.e)if we have a hyperlink in homepage as http://localhost/cgi-bin/a1?ac=index, it now looks like http://localhost/cgi-bin/a1.exe?ac=index...

What I'm looking for is http://localhost/cgi-bin/a1 should load the homepage (using URL redirection)and the hyperlinks/URLs in the homepage (if any) should not get affected.

One more issue:
URL http://localhost/cgi-bin/a1 loads homepage, on this page we also have list of hyperlinks http://localhost/cgi-bin/a2?id=1, http://localhost/cgi-bin/a2?id=2, so on...when clicked load pages 1, 2 so on from filesytem location, in a new window; where a2 refers to a2.exe.Problem is..

I'm getting "webpage not found" error and when I modify the URL to http://localhost/cgi-bin/a2.exe?id=1 the correspoding page 1 is getting loaded.

Again the same issue of URL rewriting, I suppose, can we make Hiawatha handle this?

Cant we define the Match rule for each cgi-component? that is.. a1 or a2 wherever in the URL should get redirected to a1.exe and a2.exe.

Putting forth my problem in short:
http://localhost/cgi-bin/a1 should work similar to http://localhost/cgi-bin/a1.exe
and load the homepage, which can be achieved by URL rewriting as mentioned by you but creates two problems stated below:

1. http://localhost/cgi-bin/a1?ac=index should remain as it is, where presently it is getting changed to http://localhost/cgi-bin/a1.exe?ac=index
2. http://localhost/cgi-bin/a2?id=1, when clicked should open a new window with same URL in the address bar but a2 internally referring to a2.exe; presently it opens the new window with same URL in address bar but a2 is not getting redirected to a2.exe and as a result "webpage not found error" is shown.(i.e)CGI components in the URLs either in homepage or in the address bar of new window should not have .exe

The following rewrite should work for you (tested it myself):

UrlToolkit {
    ToolkitID = a1a2
    RequestURI exists Return
    Match ^/cgi-bin/(a[12])(.*) Rewrite /cgi-bin/$1.exe$2
}

The fact that in the webpages a1 is changed to a1.exe and a2 to is changed to a2.exe is something the application does. It's not Hiawatha's fault, so I'm afraid I can't help you with that. You should change your applications (a1.exe and a2.exe) to fix that problem.

Hi Hugo,

Thank you so much for your reply....
The URL rewrite you suggested did not work for me!!!!

But my problems got solved by this piece of URL rewriting code, just wanted to share it with you; here it goes......

UseToolkit = a1

UrlToolkit {
ToolkitID = a1
Call a2
RequestURI exists Return
Match \. Return
Match /a1(.*) Rewrite /a1.exe$1
}

UrlToolkit {
ToolkitID = a2
RequestURI exists Return
Match \. Return
Match /a2(.*) Rewrite /a2.exe$1
}

Hi again,

Want to trouble you a bit further...a small request, hope you will not ignore it ...

Can you please change the heading of this topic from "port number" to "URL Rewrite Rules"?? Is that possible???

You can combine those two rules to a single one:

UrlToolkit {
    ToolkitID = a12
    RequestURI exists Return
    Match \. Return
    Match /a1(.*) Rewrite /a1.exe$1
    Match /a2(.*) Rewrite /a2.exe$1
}

Are all your problems solved now? Is the port change working?

I'm starting a new topic on port number, hope you don't mind...It will be easy for me to track...:)

Nope...it does'n't work, Hugo....

If I combine the rules as said above, it is not able to load the pages having links with a2 in it.....

ow, wait. Aren't we forgetting the cgi-bin part in the URLs?

Not actually....I think we can go without 'cgi-bin' in the rules, because requirement is basically just to convert a1 to a1.exe and a2 to a2.exe, irrespective of the location it is stored in!!!I created cgi-bin folder and put my cgi scripts in that, just for clarity...
Do you have anything else on mind reg. this?

No, sorry. I find it weird that my URL rewrites don't work for you. I tested them myself on my computer and they worked fine for me... But you made one which worked for you, so I guess that solves the problem.

Even I'm confused on that part...having said it was tested by you, I'm not sure why they don't work for me, and moreover the rewrites are straightforward, with zero probablility for me to change even...

Anyways, the rewrite which I posted here, is also technically correct I suppose, so we can get over with this.

There seems to be a minor problem again?There are some URL?s in my application which have character ?dot? (.) in them. Such URL?s are not getting modified. I tested the same URL?s using tool wigwam. See the result below:

url: /cgi-bin/R11A/a2?db=demo.html
Bad URL: Missing leading slash
old: /cgi-bin/R11A/a2?db= demo.html


New URL is not shown at all?(I guess, probably URL rewriting process must have terminated midway and it could not construct the New URL, am I correct??)

Can we make Hiawatha handle this?

It would be just GREAT if this can be done, because with this all my issues get solved and we will be good to go with Hiawatha officially!!!

Try this configuration: (removed the "Match \. Return" lines)

UrlToolkit {
    ToolkitID = a1
    Call a2
    RequestURI exists Return
    Match /a1(.*) Rewrite /a1.exe$1
}

UrlToolkit {
    ToolkitID = a2
    RequestURI exists Return
    Match /a2(.*) Rewrite /a2.exe$1
}

If that doesn't work, try changing "Match \. Return" to "Match \.exe Return"

I have removed that line, it works fine?JJJJJ. I did not try the other solution you proposed as the first one works for me?

Thank you so much?Now Hiawatha is ready for my application?. JJ

I have also sent an email to you at hugo.leisink@net; mentioned at http://www.hiawatha-webserver.org/manpages.html#lbAT.

Is that email id operational and did you receive my email??

I haven't received any email. But it's not hugo dot leisink at net, but hugo at leisink dot net.

Oh?no!!! It was a typo from my side?.I id send email to hugo at leisink dot net ONLY?.but wrote the other way in the post here?

I sent two more test emails to the same id (i.e.) hugo at leisink dot net, yesterday from Yahoo; I?m afraid you must have not received them either???

What and where is the problem??

I got your e-mail. I also replied that I received them.

Oh?Thank you?I din check yet?