feature request: need "prefix" to provide script_name in perl

[maaarghk]

for all the same reasons as detailed in #590 for python and #651 for ruby - the ability to set a value in script_name is required.

i also think it should be possible to set this to a blank string, which is allowed by the psgi spec

[ac000]

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.

[andrey-zelenkov]

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.

[ac000]

On Sat, 13 Jan 2024 03:28:01 -0800 andrey-zelenkov ***@***.***> wrote: 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.

Regardless of the above, it is _required_ by the spec...

[andrey-zelenkov]

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

[ac000]

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...

[andrey-zelenkov]

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.

[maaarghk]

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

[andrey-zelenkov]

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

[ac000]

On Mon, 15 Jan 2024 06:00:03 -0800 andrey-zelenkov ***@***.***> wrote: > 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,

Well, yes, but that's all pretty vague and could be said about anything. I doubt setting 1 variable would have noticeable consequences, but of course it can be measured to verify that...

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.

I believe this is a strawman argument...

[ac000]

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...

[maaarghk]

@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

[ac000]

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

[maaarghk]

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.