Forum

PATH INFO wo/ extension + fcgi

Peter
19 April 2010, 16:51
I'm have a similar configuration as http://www.hiawatha-webserver.org/forum/topic/269 with a application built around http://wiki.strongswan.org/wiki/1/Libfast. It is dependent on the PATH_INFO environment being set and according to the manual using "EnablePathInfo = yes" exposes this behavior except for the fact that it needs a file.path/dir setup. Is there a configuration option to work around this?

Hiawatha version: 7.1
Operating System: ucLinux
Hugo Leisink
19 April 2010, 23:42
... it needs a file.path/dir setup.

I don't understand what you mean with that.
Peter
20 April 2010, 22:21
Sorry, similar to the example used in the manual "/index.php/controller/action/..." PATH_INFO = "/controller/action".

Snippet of my Configuration:

FastCGIserver {
FastCGIid = FCGIS
ConnectTo = /tmp/app.sock
SessionTimeout = 30
}

UrlToolkit {
ToolkitID = URLTK
RequestURI isfile Return
Match .* UseFastCGI FCGIS
}

VirtualHost {
Hostname = localhost
WebsiteRoot = /var/www/app
AccessLogfile = /var/log/app/access.log
ErrorLogfile = /var/log/app/error.log
EnablePathInfo = yes
TimeForCGI = 5
UseToolkit = URLTK
}

Using "http://localhost/controller/action/..." doesn't set the PATH_INFO
Hugo Leisink
20 April 2010, 22:35
That can be true, because PATH_INFO is only set when Hiawatha finds a CGI file as part of the URL. Which is not the case for http://localhost/controller/action/...
Peter
21 April 2010, 00:28
That can be true, because PATH_INFO is only set when Hiawatha finds a CGI file as part of the URL. Which is not the case for http://localhost/controller/action/...


Thanks for the clarification. Does the CGI file need to exist on disk? Thinking I could use a rewrite rule to non-existent CGI file to satisfy the PATH_INFO criteria.

UrlToolkit {
ToolkitID = URLTK
RequestURI isfile Return
Match (.*) Rewrite /nonexistent.fcgi$1
Match .* UseFastCGI FCGIS
}


And I'm under the assumption that nonexistent.fcgi would be passed as SCRIPT_NAME?

I'll have a peek into the source code to try to answer my own questions while I await your response and thanks again.
Hugo Leisink
21 April 2010, 09:04
When using the UseFastCGI URL toolkit option, the requested CGI does not need to be present on disk. All requests are send to the FastCGI server no matter what.

SCRIPT_NAME will contain the file part of the URL. What it is depends on the request URL and rewrites that have been done.
Peter
22 April 2010, 21:46
When using the UseFastCGI URL toolkit option, the requested CGI does not need to be present on disk. All requests are send to the FastCGI server no matter what.


Indeed the requests are sent but when the CGI doesn't exist the PATH_INFO is not set. After looking through the code (hiawatha.c) when calling is_directory > opendir it returns ENOENT and get_path_info is never called. For now I just created an empty nonexistent.fcgi in the web root so that ENOTDIR is returned but I will attempt to patch the code so a script file shouldn't be necessary, ie. http://localhost/controller/action/... would set SCRIPT_NAME = "" and PATH_INFO = "controller/action/...". This is for my particular problem and I'm not exactly sure it's correct behavior to do so but will suffice.
Hugo Leisink
22 April 2010, 22:18
Why do you want to use PATH_INFO so badly? Filling it the way you want is not standard compliant, so it's not something I'm going to support.
Peter
23 April 2010, 17:21
I'm aware it isn't a standard approach but I don't want to duplicate functionality on my embedded system. It's very limited (8mb flash / 16mb ram / 190mhz) and only supports static linking. Hiawatha already contains the code to parse out the URI so I'd like to avoid duplication and the possibility of creating bugs on the FCGI server. Like I said this is for my particular setup and Hiawatha code base is stable, feature rich, secure, and portable. Its modularity doesn't depend on dynamic linking, fork/exit segments are vfork/_exit compatible, etc. I'm very satisfied with everything you have created and I will continue to use the empty file approach to work with the standard.
This topic has been closed.