rtc_webserver on non standard port

[lionheart]

Greeting Danijel,

From the source codes of rtc_webserver (FileProvider module to be exact), the server is getting docroot from the hostlist which read from the rtcWebserver.ini [Hosts] section with only an entry that is *=.\. I have my webpages in a subfolder called "html" hence i change the entry to *=.\html\. Everything works fine if the server is listening on port 80. However when i change the listening port to 8090 I get inconsistent result sometimes only displaying the html text, sometimes with the background image etc. Please do advise on how to make this works.

Another question, On using port 80 (std port) http://localhost will trigger the FileProvider.CheckRequest event which called RepairFileName to append the valid default index page(list from rtcwebserver.ini) to display the page. However, this does not happen on non standard port (esp 8090), in fact when i try to put http://localhost:8090 (without the /index.html) the FileProvider.CheckRequest is not triggered at all. Just wondering if this is standard behaviour of webserver?

Thanks in advance

[D.Tkalcec (RTC)]

1) For the RTC SDK, it is irrelevant which port the Server is running on. The code being executed is the same, regardless of the Port number. The Browser is responsible for parsing the URL and separating the Server Address and Port from the rest of the URL. The only difference is on the Client / Browser side. If you are getting incomplete files when using a different Port, even though everything else is the same in your code, it can only be attributed to problems with your Web Browser / Client. From my experience, some Browsers have problems with "http://localhost:xxx" as Server address. Try using the IP address of your machine or "127.0.0.1" instead of "localhost" and see if it makes any difference.

2) The default path in the "rtcWebServer.ini" file uses relative paths because I had to make it work "out-of-the-box" without knowing where it will be installed. But when running on a production machine, I always recommend using absolute paths. Especially when you have a Web Server running as a Service, the relative path seems to be quite unreliable. Or, you could try changing the "RepairFileName" function to check if the path is relative and prepend the absolute path to the "AppFileName" global variable.

Best Regards,
Danijel Tkalcec

[lionheart]

Thanks Danijel.

It works with 127.0.0.1 for both (1) and (2). On (2) you have "FileExpandName" the relative path to absolute path in AddHost procedure and the absolute path is then assigned to Docroot thru GetDocRoot function. Though you store the Request.Info.asText['fname'] as relative path, however on FileProviderSendBody event you check the file access with "Docroot + Request.Info.asText['fname']". Sorry for my ignorance, doesn't this means you have absolute path already implemented in the demo? just can't see why the need to change Repairfilename..

[D.Tkalcec (RTC)]

Was your problem solved by using http://127.0.0.1:8090 instead of http://localhost:8090 in the Browser?

Best Regards,
Danijel Tkalcec

[lionheart]

The problem is solved by using http://127.0.0.1:8090. http://localhost:8090 still the same issue. FYI, my browser is Firefox 7.01.
Danijel, I am happy with it, anyway it's just for testing on local machine, for deployment in LAN i will ask the user to access the server ip, whilst on internet it will be an internet domain name which won't have the issues.

Thanks a lot. Honestly, nowadays I can't write any application without rtcSdk

[D.Tkalcec (RTC)]

Thank you for your feedback. I'm glad to hear the problem is solved.

PS. When working inside LAN, you could also use the name of your Server PC instead of its IP address, but using the IP address will be faster and is more reliable if your Server has a static IP, since it does not require resolving the name.

Best Regards,
Danijel Tkalce

[lionheart]

Noted. +1 for the super fast reply, another reason why i like rtcsdk.