I realize that when I change from embedded server to, for instance, CGI, some things must be adjusted. For example, I use TRequest.ScriptName to get the base path of my web. This seems OK for CGI but not for embedded server, because it's not set there. I even got almost totally different environment variables set!

CGI:
HTTP_HOST=localhost
HTTP_HOST=localhost
HTTP_CONNECTION=keep-alive
HTTP_REFERER=http://localhost/foj/foj.cgi/problem/browse HTTP_CACHE_CONTROL=max-age=0
HTTP_USER_AGENT=Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.91 Safari/534.30
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_ENCODING=gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8
HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.3 PATH=... // cut down for brevity
SystemRoot=C:\WINDOWS
COMSPEC=C:\WINDOWS\system32\cmd.exe
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH WINDIR=C:\WINDOWS
SERVER_SIGNATURE=
SERVER_SOFTWARE=Apache
SERVER_NAME=localhost
SERVER_ADDR=127.0.0.1
SERVER_PORT=80
REMOTE_ADDR=127.0.0.1
DOCUMENT_ROOT=C:/UniServer/www
SERVER_ADMIN=admin at localhost
SCRIPT_FILENAME=C:/UniServer/www/foj/foj.cgi
REMOTE_PORT=2373
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
REQUEST_METHOD=GET
QUERY_STRING=
REQUEST_URI=/foj/foj.cgi/index/home
SCRIPT_NAME=/foj/foj.cgi
PATH_INFO=/index/home

Embedded server:
=::=::\
=::=::\
=C:=C:\UniServer\www\foj
=D:=D:\
ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\Lele Dumbo\Application Data CLASSPATH=.
CLIENTNAME=Console
COLUMNS=80
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=LELEDOWS
ComSpec=C:\WINDOWS\system32\cmd.exe
CPLUS_INCLUDE_PATH=C:\gtk+\include;C:\Python26\include;C:\lua\include C_INCLUDE_PATH=C:\gtk+\include;C:\Python26\include;C:\lua\include;C:\perl\include EDITOR=C:\SciTE++\SciTE.exe
FP_NO_HOST_CHECK=NO
GOBO=C:\gobo
GRAPHVIZ_DOT=C:\graphviz\bin\dot.exe
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\Lele Dumbo
INCLUDE=C:\FASM\INCLUDE
JAVA_HOME=C:\Java
LC_MESSAGES=C
LIBRARY_PATH=C:\gtk+\lib;C:\Python26\libs;C:\lua\lib;C:\perl\lib LINES=24
LOGONSERVER=\\LELEDOWS
MOSMLLIB=C:\mosml\lib
MOZ_PLUGIN_PATH=C:\Program Files\SumatraPDF\
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
Path=... // cut down for brevity
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 6 Stepping 5, GenuineIntel PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0605
ProgramFiles=C:\Program Files
QTDIR=C:\qt
RUBYOPT=-rubygems
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\DOCUME~1\LELEDU~1\LOCALS~1\Temp
TMP=C:\DOCUME~1\LELEDU~1\LOCALS~1\Temp
USERDOMAIN=LELEDOWS
USERNAME=Lele Dumbo
USERPROFILE=C:\Documents and Settings\Lele Dumbo
windir=C:\WINDOWS

The one from embedded server looks like my computer environment, while the CGI one seems to be set by the underlying web server (Apache in this case).

So, how can I get the base web path (like localhost:12000/executable-name) in embedded server? I need to do this because links to other parts of the website must be relative to it.

This is normal, because you don't need the environment in the embedded server. You don't need the environment at all in a CGI app as well. The whole point of fpweb is to abstract away the source of the information of the request.

[snip]

The Application.ApplicationURL is set to this.
In a webmodule, the module's URL is available in BaseURL.

Michael.

Thanks for answering, however the problem is not yet solved.

The whole point of fpweb is to abstract away the source of the information of the request.

I know, but as I said something that works across the webapp type (like the base url) should exist.

The Application.ApplicationURL is set to this. In a webmodule, the module's URL is available in BaseURL.

Doesn't work. Application.ApplicationURL is empty in both embedded server and CGI (I put it in a unit because of the ifdef in used units). The BaseURL of the module works, but without the preceding URL (hostname and port) it's kinda useless for URL generation.

It's not always possible to get the Application-URL. That's a problem with other server-side weblanguages too. It's not only the host, but the path to your application can also differ. My applications only use relative URL's, to solve this problem. When the URL is really needed (for example when you send an email to reset a assword) I read the URL from a xml-file.

Joost.

It's not always possible to get the Application-URL. That's a problem with other server-side weblanguages too.

Maybe... the PHP framework I use require me to specify the base URL (relative from the host:port) like /myproj/ for
http://localhost:8080/myproj/ assuming the webserver is listening at localhost on port 8080. But only up to that point, the other parts are determined from the environment variables (I guess).

Back to the problem, using relative URL is not a solution as well. When I do http://localhost/proj/proj.cgi/module/action then if somewhere I put public/style/style.css then the link becomes:
http://localhost/proj/proj.cgi/module/public/style/style.css, regardless of the webapp type (at least on Chrome, don't know about other browsers). Isn't there really a way somehow?

Well, the webcontroller class has some functionality build-in to fix this. You can look into that. I don't know f this functionality works without a TWebPage, though. (See the webdesign package)

Isn't there really a way somehow?

Set it in some constant? When the webmodule still wasn't working good enough, I used defines with a constant.

Because you need
/public/style/style.css
indicating that it is a static file from the virtual path starting from document root.
public/style/style.css
is relative from the current virtual path, which can be anything physically in the file system, depending on the OS or weather you use CGI or Apache module, etc.
Also, if your CGI program opens files, it will need full physical paths, we can not use relative paths with it either, because it can be the main root dir on Linux or the Apache main dir (not the document root) on Windows. Usually not the physical path the CGI program resides in.

AB

Set it in some constant? When the webmodule still wasn't working good enough, I used defines with a constant.

I use an .ini file, but the same idea. There can be a lot of things that a web app needs as a constant.
static paths, email server settings, template paths, url generation parameters (https or http, ports for development computer, etc.), db connection settings, etc.
This way it is the easiest to move from a development environment to a live system. All you need is to remove the .ini file (or constants by defines), or change its values.

AB

Using some kind of configuration file sounds like a good solution.

@Joost:
I'll try to look at inside of TWebPage, maybe I can steal something from there... >:)