Environment variable PATH_INFO not defined by lighttpd using uwsgi module

Question

I have lighttpd version 1.4.73 running on Alpine Linux. I enabled mod_scgi and added this to my configuration file:

scgi.protocol = "uwsgi"
scgi.server = (
 "/tp2/" => ( "tp2-app" => (
 "host" => "127.0.0.1",
 "port" => 8080,
 "check-local" => "disable",
 "fix-root-scriptname" => "enable",
 "fix_root_path_name" => "enable"
 )
 ),
)

My Bottle.py crashes because it can't find PATH_INFO. I reduced the problem to this minuscle pure Python wsgi application that displays the request's environment variables:

def application(environ, start_response):
 start_response('200 OK', [('Content-Type', 'text/plain;charset=utf-8')])
 page = [f'@Hello World!\n'.encode("utf-8")]
 for key, value in environ.items():
 page.append(f"{key} = {value}\n".encode("utf-8"))
 return sorted(page)

I run this app with:

uwsgi --uwsgi-socket 127.0.0.1:8080 --plugin python3 -w hello_world_app

And indeed, PATH_INFO is not set by lighttpd:

HTTP/1.1 200 OK
Content-Type: text/plain;charset=utf-8
Accept-Ranges: bytes
Content-Length: 943
Date: 2024年3月24日 18:22:09 GMT
Server: lighttpd/1.4.73
@Hello World!
CONTENT_LENGTH = 0
DOCUMENT_ROOT = /var/www/localhost/htdocs
GATEWAY_INTERFACE = CGI/1.1
HTTP_ACCEPT = */*
HTTP_HOST = tp2.test
HTTP_USER_AGENT = curl/8.5.0
QUERY_STRING = date=2024年03月24日T14:22:10-04:00
REDIRECT_STATUS = 200
REMOTE_ADDR = 192.168.3.10
REMOTE_PORT = 35690
REQUEST_METHOD = GET
REQUEST_SCHEME = http
REQUEST_URI = /tp2/hello?date=2024年03月24日T14:22:10-04:00
SCRIPT_FILENAME = /var/www/localhost/htdocs/tp2/hello
SCRIPT_NAME = /tp2/hello
SERVER_ADDR = 192.168.3.30
SERVER_NAME = tp2.test
SERVER_PORT = 80
SERVER_PROTOCOL = HTTP/1.1
SERVER_SOFTWARE = lighttpd/1.4.73
uwsgi.node = b'tp2.test'
uwsgi.version = b'2.0.23'

How can I forward everything under the path /tp2/ to my application and have PATH_INFO available for Bottle?

Answer 1

lighttpd gateway server host options

If "check-local" => "disable", then lighttpd does not check the URL against the filesystem under the document-root and does not generate PATH_INFO, as PATH_INFO is the part of the url-path after the script name, and lighttpd has been told not to check the local filesystem, and instead to treat the entire url-path in the request as SCRIPT_NAME.

PATH_INFO: https://www.rfc-editor.org/rfc/rfc3875.html#section-4.1.5

If you are using "check-local" => "disable" then your script should be looking at the request that was made, not PATH_INFO. e.g. SCRIPT_NAME and QUERY_STRING, or the non-standard REQUEST_URI provided by lighttpd, which contains SCRIPT_NAME, optional PATH_INFO, and QUERY_STRING.

Practical answer: if you remove "check-local" => "disable" from your configuration and you touch an otherwise empty file named tp2 under your server.document-root, then PATH_INFO might be generated in the way you want.

(Alternatively, fix your uwscgi app to not rely on PATH_INFO and you can keep "check-local" => "disable")

---

"fix-root-scriptname" => "enable" is for when the scgi.server is handling "/" (root of the path), which does not apply to "/tp2/" so this does not appear to have any effect in your configuration.

---

What is "fix_root_path_name" => "enable"? Where did you find that or cut-n-paste that? (Hint: it is not valid)

• gstrauss: Another option: You might try setting environ['PATH_INFO'] = environ['SCRIPT_NAME'] before invoking the bottle app.
• gstrauss: Curious: will the app work if you specify setenv.set-environment = ("PATH_INFO" => "") in your lighttpd.conf? That should get you past the bottle crash, but will the app work? (Should bottle.py handle if the PATH_INFO variable is not set, rather than an empty value?)
• ixe013: Thanks for the suggestions, but they don't work. With check-local enabled I never reach my server. PATH_INFO is not use in that many places, but a quick hardcode of /tp2/ or SCRIPT_NAME here and there produced different errors. I think I'll open an issue in the project.
• ixe013: As for fix_root_path_name, I gave it a try after it came up as I was searching the source with grep -r fix.root lighttpd1.4.
• gstrauss: Which of the above suggestions did you try and what were the results?