nginx path_info without index.cfm

[Brian FitzGerald]

Hey guys,

I'm going batty here as I can't get cgi.path_info to show up as expected. My app uses pretty urls, so I need: http://dev.myapp.com/how-it-works to load as http://dev.myapp.com/index.cfm/how-it-works.

I have stripped my application down to nothing. My Application.cfc now looks like this:

component {
 writeOutput('cgi "path info"<br>');
 writeDump(cgi.path_info);
 abort;
}

When running on Apache, this is what I get (good):

When running on Nginx, this is what I get (bad):

Please bare in mind I am awful when it comes to Apache/Nginx config, mod_rewrites, url rewrites, etc. I have tried many, many combinations with the help of Google, etc. but the above is the closest I have gotten. The good news is that index.cfm does load as expected, the bad news it that the path info is not coming through for me. I have seen Paul Klikenberg's post on the matter, and I feel like I'm close, but the wrinkle (I guess) is that in my case the index.cfm needs to be added into the equation for the pretty urls. Anyway, here's my nginx config. Don't stare at it directly or you may turn to stone... I find that if you look at it out of your peripheral vision and glance away quickly, your chances are great improved.

server {


    listen 80 default_server;
    server_name  _;
    index  index.cfm index.html index.htm;
    root   /var/www;
    server_name_in_redirect off;


    set $path_info "";


    #test url: http://192.168.99.100/how-it-works




    #attempt1 -> server 404 not found
    #if (!-e $request_filename){
        #rewrite ^(.*)$ /index.cfm/$1 break;
    #}


    #attempt2 -> loads index.cfm file, CGI path_info is blank
    #location / {
        #try_files $uri /index.cfm$1;
    #}


    #attempt3 (server 500 error)
    #try_files $uri /index.cfm/$args;


    #attempt4
    #if (!-e $request_filename){
       #try_files $uri /index.cfm$args;
       #set $path_info $args;
    #}


    #attempt5 > 404 not found
    #rewrite ^(.*)$ /index.cfm$1;
    #set $path_info $1;


    #attempt6 > 404 not found
    #rewrite ^(.*)$ /index.cfm$1 break;
    #set $path_info $1;


    #attempt7 > loading index.cfm file but not passing $path_info
    #if ($uri ~ "^(.+.cfm)(/.+)") {
        #set $path_info $2;
    #}


    #try_files $uri /index.cfm$args;




    try_files $uri /index.cfm$args;


    # if the extension .cfm or .cfc is found, followed by a slash and optional extra
    if ($uri ~ "^(.+?\.cf[mc])(/.*)") {
        # remember the filepath without path_info
        set $script $1;
        set $path_info $2;
        # rewrite the url to match the filepath wthout path_info
        # rewrite ^.+$ $script break;
    }
    # set the custom path_info header
    proxy_set_header XAJP-PATH-INFO $path_info;






    location ~* \.(cfm|cfc|cfr)$ {
        proxy_pass http://127.0.0.1:8888;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 600;
        proxy_send_timeout 600;
        proxy_read_timeout 600;
        send_timeout 600;
    }


}

[Nando Breiter]

Brian,

Igal pointed out to me that to get certain cgi vars to resolve properly, in my case it was the ip address, tomcat also needed some additional configuration. Check the top of his example here https://gist.github.com/igal-getrailo/6981111 where it says:

if connecting to Tomcat, use Tomcat's RemoteIpValve to resolve CGI.REMOTE_ADDR, CGI.SERVER_NAME, and CGI.SERVER_PORT_SECURE
<Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="X-Forwarded-Proto" remoteIpHeader="X-Forwarded-For" protocolHeaderHttpsValue="https" />

A stab in the dark on my part, but perhaps there may be a tomcat valve you need to set for cgi.path_info.

Aria Media Sagl

+41 (0)76 303 4477 cell
skype: ariamedia

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/891fc7df-8c27-496c-8a20-77a9239e5706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Igal @ Lucee.org]

I think that the problem is elsewhere here.  Are you sure that you want CGI.PATH_INFO?  I personally think (without knowing anything about your application) that you want CGI.SCRIPT_NAME, which is not the same.

Also, your url-rewriting should probably be done with the rewrite directive:
http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D-o96qO9UChc7t1PXR_G3RHwY9fAK_9XhEKQa-Ez7sDLA%40mail.gmail.com.

[Jon Clausen]

Brian,

See this post for how to correct the PATH_INFO issue with NGINX/Lucee:

http://www.lucee.nl/post.cfm/enable-path-info-on-nginx-with-lucee-and-railo

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/56C8A94B.1070502%40lucee.org.

[Igal @ Lucee.org]

@Jon -- judging by the snippet that Brian posted I'd say that the link you provided is where he got his code from in the first place.

@Brian -- if that is to work then I would expect the header to be X-AJP-PATH-INFO instead of XAJP-PATH-INFO -- perhaps @Paul can chine in and tell us whether that was a typo there or not.

I still think that you want CGI.SCRIPT_NAME and not CGI.PATH_INFO though.

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.56c8ab83.6964d63a.b3a1%40jonclausen-mbp.local.

[Brian FitzGerald]

Thank you so much for the responses guys. As a result of your help, I am much closer now. With this configuration (considerably easier on the eyes) my app is ALMOST running perfectly:

server {

    listen 80 default_server;

    server_name  _;

    index  index.cfm index.html index.htm;

    root   /var/www;

    server_name_in_redirect off;

    set $path_info $request_uri;

    try_files $uri /index.cfm$args;

    location ~* \.(cfm|cfc|cfr)$ {

        proxy_pass http://127.0.0.1:8888;

        proxy_redirect off;

        proxy_set_header Host $host;

        proxy_set_header X-Forwarded-Host $host;

        proxy_set_header X-Forwarded-Server $host;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header XAJP-PATH-INFO $path_info;

        proxy_connect_timeout 600;

        proxy_send_timeout 600;

        proxy_read_timeout 600;

        send_timeout 600;

    }

}

To answer your question, Igal, cgi.path_info is indeed the variable I was interested in simply because that is the variable Sean uses "under the hood" in fw/1 during the processing of "pretty routes." The two main problems my old config had were:

1. the proxy_set_header statement for XAJP-PATH-INFO had to go inside the location block (I had it outside before), and
2. I needed to discover and use the $request_uri nginx variable, as it is the only one I could find that would actually provide the desired value for the path_info

So now, requesting http://dev.mysite.com or http://dev.mysite.com/some-cool-url both correctly route their requests through the index.cfm file. This is great! I can navigate through most of the entire app without difficulty.

However, my "final" problem is that when I explicitly make a request to index.cfm, rather than returning the expected html, it pops up a prompt to download/save the file index.cfm file (as if nginx didn't know it should be handed off to lucee at all). Weird, huh? I think this same misconfiguration is what is many some of my ajax requests as well.

By looking at that (shorter) nginx config, anything nasty jump out that would cause the server to prompt a direct download of index.cfm when it is explicitly requested?

I really appreciate your help guys; I'll stop bugging you soon.

Brian

...

[Brian FitzGerald]

Cancel this. After rebuilding the docker container, this last issue stopped happening. Everything is now working as expected (as far as I can tell).

I am really pleased to be migrating this application to Lucee (on Docker) and running it in Amazon AWS (EC2 Container Engine), or Google Container Engine, or Digital Ocean. You guys are really great and I'm amped for the great future I know Lucee holds.

Thank you Geoff Bowers, Igal, Nando, Paul Klinkenberg, Sean and Jon for your patient help.

Brian

...

[Brian FitzGerald]

In other news, I did discover these unicorns on the lucee.nl site. All in a weekends work, gentlemen.

...

[Paul Klinkenberg]

Hey, glad I could be of assistence, while not even being here ;-)

Next time, feel free to contact me via email or a blog comment if you have issues like this. But I see you already rcvd great help from the Lucee list!

Kind regards,

Paul Klinkenberg

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2501d481-4afa-4fb7-9695-d1b7178985c1%40googlegroups.com.

[Geoff Bowers]

On Monday, 22 February 2016 05:38:44 UTC+11, Brian FitzGerald wrote:

I am really pleased to be migrating this application to Lucee (on Docker) and running it in Amazon AWS (EC2 Container Engine), or Google Container Engine, or Digital Ocean. You guys are really great and I'm amped for the great future I know Lucee holds.

 We've been having considerable success with DockerCloud (https://cloud.docker.com/) using AWS as a provider. DockerCloud also supports DigitalOcean and others.

I found it too hard to orchestrate a lot of little apps through to ECS via Beanstalk and haven't looked back since we hooked up DockerCloud (nee Tutum Cloud).

GB