Question

On Windows Server 2008 I created

reboltutorial.com [
    root-dir %/www/
    default [%index.html %index.rsp %index.php]
]   

It returns 404 error page not found. Cheyenne only works with IP address ( http://88.191.118.45:2011/ ok http://reboltutorial.com ok also but on ISS 7).
How to fix this ?

Update: error log

 Error in [conf-parser] : Can't access file www/ws-apps/ws-test-app.r 
 Error in [conf-parser] : Can't access file www/ws-apps/chat.r !

Answer 1

First of all, HTTP 1.1 sends the full URL over the TCP session (including the domain-name typed on the Location: line). That’s how one IP can serve multiple domains (Apache calls this VirtualHosts), so browsing by IP will be sending a different URL to whatever web server gets the request.

Thus it’s not a great technical mystery for your machine to be set up in a way that it serves a different page for an IP address vs. a domain. But since you put “reboltutorial.com” in your Cheyenne config it seems that–if anything–that would be working while the IP address version would be failing.

I don’t run Cheyenne, and you haven’t offered up more details about your configuration. But since no one has answered I looked at the source tree to offer some advice on what you might try.

We know Cheyenne is getting the request and making the decision to hand back the 404, because of the format of the error. The Apache one looks different:

http://reboltutorial.com/show-me-apache-404/

http://88.191.118.45:2011/show-me-cheyenne-404/

So Cheyenne is getting the request. That much we know. The decision to serve up a 404 is made in send-response in the HTTPd.r file. It’s a pretty simple test:

if all [file? out/content not exists? out/content][
    log/error ["File not found: " mold out/content]
    out/code: 404
    out/content: none
]

If that’s the place your 404 is being generated, then there should be a “File not found:” in your log and a mention of what file that is. If not, something strange is going on. You can throw something in there (even a quit if you’re suspicious of the printed output) just to make sure it’s getting to the line.

(FYI: In the future when you’re looking at other Cheyenne problems, there is a is a setting called “verbosity” which affects the output and you can see in on-received in the HTTPd.r file that for verbosity > 0 it will log when it receives a request:

if verbose > 0 [
    log/info ["================== NEW REQUEST =================="]
    log/info ["Request Line=>" trim/tail to-string data]
]

If you bump up the verbosity level you might find an indication of the problem pretty quickly. If not, the code is fairly readable and you can put in your own trace points.)