feature request: need "prefix" to provide script_name in perl about unit HOT 15 OPEN

if you were migrating an existing setup like this one which uses nginx - https://github.com/maaarghk/two-placks-one-domain - setting script_name would be required.

the same thing can be done with something simpler like starman using https://metacpan.org/pod/Plack::App::URLMap

i think the same argument as in the python discussion applies where it's totally accurate to say it's pointless to send extra bytes over the wire for every single request for something that is essentially a constant part of the app configuration. ideally if you're starting a new app from scratch you'd take that into account.

But that ship has sailed - if someone wants to migrate an existing app and make minimal changes, or host a third party app where patching the upstream codebase is not desirable, optional support for this has to be present.

https://github.com/plack/Plack/blob/853f25df3e972e28a9822aabbdca87337477deb8/lib/Plack/Middleware/Lint.pm#L36

from unit.

Hi @maaarghk

Indeed, according to the PSGI spec

The environment MUST include these keys (adopted from PEP 333, Rack and JSGI) except when they would normally be empty.

and as one such key

SCRIPT_NAME: The initial portion of the request URL's path, corresponding to the application. This tells the application its virtual "location". This may be an empty string if the application corresponds to the server's root URI.

All the other required keys seem to be there, so it looks like this just got overlooked.

I'll have a look.

from unit.

Hi @maaarghk,

In the discussions #590 and #651, real-world use cases emerged that led to issues which couldn't be resolved without these variables. As mentioned here: #590 (comment), every additional variable introduced in the context adds overhead. Therefore, please provide examples of how SCRIPT_NAME is utilized in the Perl.

from unit.

from unit.

It makes no sense to implement unused parts of the specification, especially if this leads to general degradation.

from unit.

That's a pretty vague and generalised statement. I suppose you have some facts to back that up?

Given the way Unit works, I am however struggling to see under which circumstances SCRIPT_NAME would be anything other than an empty string...

from unit.

That's a pretty vague and generalised statement. I suppose you have some facts to back that up?

PSGI variables (similar to WSGI) are generated unconditionally for each request to the Perl application, leaving no option to disable this behavior. Consequently, the module must allocate additional resources for each request when incorporating this variable. Therefore, I am inclined to believe that adding it without obtaining any real benefits, such as addressing an actual user bug, is not advisable. Specifications are not immutable; they may be duplicated, contain errors, be rewritten over time, or be created post facto. Prioritizing the resolution of genuine user issues holds greater significance for me than blindly adhering to documentation requirements.

from unit.

@maaarghk Thank you! That what I was looking for.

from unit.

from unit.

AFAICT we only need to set SCRIPT_NAME to an empty string, would need to check, but we may be able to do that once at module initialisation...

from unit.

@ac000 in https://github.com/maaarghk/two-placks-one-domain i give an example of script_name being set (via fastcgi_split_path_info) to a non-blank string, allowing an app which defines its routes as / and /about to be hosted in subdirectory of /app2

from unit.

Yes, we do something like that for PHP so you can hit /path/to/index.php/some/internal/path and get

SCRIPT_NAME = "/path/to/index.php"
PATH_INFO = "/some/internal/path"

I'm not sure that makes sense for Perl under Unit, where you don't hit a .pl file (like you might with CGI). Here SCRIPT_NAME is always the root so SCRIPT_NAME= "".

E.g with config like

{
    "listeners": {
        "[::1]:8080": {
            "pass": "routes"
        }
    },

    "routes": [
        {
            "match": {
                "uri": "/bar/baz/perl*"
            },
            "action": {
                "pass": "applications/perl"
            }
        }
    ],

    "applications": {
        "perl": {
            "type": "perl",
            "script": "/home/andrew/src/perl/1060.pl"
        }
    }
}

The Perl script is loaded at module init time.

$ curl localhost:8080/bar/baz/perl/a/b/c
REQUEST_URI => /bar/baz/perl/a/b/c
PATH_INFO   => /bar/baz/perl/a/b/c

I think those are right and match what the ruby module does for example.

AIUI the perl script here is always the root URI and any path given in the URI is then PATH_INFO

from unit.

Yeah, perl (well, Plack) does not use SCRIPT_PATH in that way though, it's more taken to mean "url prefix". In the above case if 1060.pl is a Plack app then it would have to define its routes like: /bar/baz/perl/a/b/c. but it might already exist and define its routes as /a/b/c, in which case it would expect:

REQUEST_URI => /bar/baz/perl/a/b/c
PATH_INFO => /a/b/c
SCRIPT_PATH => /bar/baz/perl

Then, the script could know, to generate a URL for its route /page2, the whole required url is /bar/baz/perl/page2.

from unit.

Hmm, OK, so I don't think we can set this automatically, looks like we will need something like a prefix option like we have in Python (not sue why we don't have such a thing in Ruby), that can default to the empty string if not set...

This also means that PATH_INFO will need to be adjusted accordingly.

from unit.

@ac000 Actually, I think it is needed in Ruby... we tried setting a SCRIPT_NAME but it never worked properly. We ended up whipping together a middleware to extract a environment variable to get around it, which is non-standard and brittle since it's not standard.

from unit.