Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expected PATH_INFO is not set #3

Closed
wmark opened this issue Feb 10, 2011 · 9 comments

Comments

@wmark
Copy link
Contributor

commented Feb 10, 2011

Given the request to http://127.0.0.1/cgit/xyz/ and the relevant resulting request headers as follows::
DOCUMENT_ROOT=/var/www/localhost/htdocs/cgit/
SCRIPT_FILENAME=/var/www/localhost/htdocs/cgit/tst
REQUEST_URI=/cgit/xyz/
SCRIPT_NAME=tst
... no PATH_INFO is set.

Expected is PATH_INFO /xyz/ or similar.

You can easily test that by this CGI script::
#!/bin/sh
echo Content-type: text/plain
echo Expires: 0
echo ""
/bin/env
/bin/date

@wmark

This comment has been minimized.

Copy link
Contributor Author

commented Feb 10, 2011

Removing SCRIPT_FILENAME and leaving the other two as they are doesn't fix that issue - as well as using the first variable alone.

The bug does not exist in version 1.0.1 and occurs since 1.0.2 (including).

@gnosek

This comment has been minimized.

Copy link
Owner

commented Mar 1, 2011

First of all, apologies for taking so long to respond.

I'm not sure I understand the logic which you would like to use to compute PATH_INFO from SCRIPT_FILENAME an REQUEST_URI. Why exactly /cgit should be chopped off the URL? I expected SCRIPT_FILENAME to be used in conjunction with PATH_INFO passed from web server to override fcgiwrap's heuristics.

As for your second comment, I find it hard to believe looking at the code. How exactly do you remove the variable? Can you post a complete server {} section for me to reproduce the problem?

@xrogaan

This comment has been minimized.

Copy link

commented Sep 24, 2011

I believe the main issue is the absence of PATH_INFO. I have troubles to use mailman with nginx using fcgiwrap because of that.

Here is some information about the issue: http://mail.python.org/pipermail/mailman-users/2010-September/070278.html
That message being the last, but most important. I have exactly the same issue and I'am unable to fix it. I belive fcgiwrap unset that variable for some reason.

Well, it may not be a bug but just a misunderstanding. So please, could you explain how to successfully pass PATH_INFO from the webserver to the script ?

@gnosek

This comment has been minimized.

Copy link
Owner

commented Sep 27, 2011

W dniu 24.09.2011 12:06, Ludovic Bellière pisze:

I believe the main issue is the absence of PATH_INFO. I have troubles to use mailman with nginx using fcgiwrap because of that.

Here is some information about the issue: http://mail.python.org/pipermail/mailman-users/2010-September/070278.html
That message being the last, but most important. I have exactly the same issue and I'am unable to fix it. I belive fcgiwrap unset that variable for some reason.

Well, it may not be a bug but just a misunderstanding. So please, could you explain how to successfully pass PATH_INFO from the webserver to the script ?

It's not a bug, rather a (mis)feature stemming from my private nginx
config I had when I wrote fcgiwrap. PATH_INFO passed from the web server
is ignored and instead is parsed out of SCRIPT_FILENAME (or
DOCUMENT_ROOT + SCRIPT_NAME).

I needed to support CGI with PATH_INFO long before the
fastcgi_split_path_info nginx feature so I built it into fcgiwrap.

Try adding:

fastcgi_param SCRIPT_NAME $uri;

or:

fastcgi_param SCRIPT_FILENAME $request_filename;

to your nginx config.

Best regards,
Grzegorz Nosek

@xrogaan

This comment has been minimized.

Copy link

commented Sep 27, 2011

Ah thanks !

Maybe a little line about this (mis)feature in the documentation will be usefull for other people. At least, if you don't plan to change it's behavior :)

@gnosek

This comment has been minimized.

Copy link
Owner

commented Sep 27, 2011

W dniu 27.09.2011 21:29, Ludovic Bellière pisze:

Ah thanks !

Maybe a little line about this (mis)feature in the documentation will be usefull for other people. At least, if you don't plan to change it's behavior :)

Yeah, I keep telling myself I'll clean it up (accept PATH_INFO properly)
someday.

Best regards,
Grzegorz Nosek

@kaufholdr

This comment has been minimized.

Copy link

commented Jan 5, 2013

I think it would be much better if you could leave the PATH_INFO untouched if it was already set by the web server. Or do you have any security related concerns why you are removing it?

@gnosek

This comment has been minimized.

Copy link
Owner

commented Feb 3, 2013

Since 1.0.2 if you pass SCRIPT_FILENAME over FastCGI to fcgiwrap, it will simply execute it without touching any other environment variables. E.g., given:

    # nginx config
    location ~ \.cgi {
        fastcgi_split_path_info ((?U).+\.cgi)(/?.+)$;
        fastcgi_pass   unix:/tmp/fcgiwrap.sock;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param  PATH_INFO $fastcgi_path_info;
        include        fastcgi_params;
    }

requests to /path/to/script.cgi/path_info result in /document/root/path/to/script.cgi being executed with PATH_INFO=/path_info in the environment (untouched by fcgiwrap).

All the mangling done is purely optional (happens when SCRIPT_FILENAME is not defined) and should be considered legacy. Closing the ticket now, feel free to reopen in case of related problems.

@gnosek gnosek closed this Feb 3, 2013

@kaufholdr

This comment has been minimized.

Copy link

commented Feb 3, 2013

Thank you. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.