Add PATH_INFO support to CGI scripts

[jamesaoverton]

I would like to support URLs like this https://droid.ontodev.com/curatron/branches/main/views/src/run.py/table?limit=1 where:

• we have a CGI script src/run.py that we allowed in our Workflow with ./src/run.py
• we provide additional path information /table?limit=1

I'm not clear on how much work this will be. I think:

1. The current exec-view code in make.clj matches the full string following views/: src/run.py. I think we would need to handle two cases: (1) src/run.py and (2) src/run.py/(.*).
2. In case (2), the portion of the path after src/run.py would be passed to the CGI script as PATH_INFO (I think).
3. The PATH_INFO is distinct from the QUERY_STRING, which we currently support.

[lmcmicu]

It's not clear to me that the description above is correctly distinguishing PATH_INFO from QUERY_STRING. See: https://en.wikipedia.org/wiki/Common_Gateway_Interface

In a URL like: http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string, PATH_INFO is /with/additional/path and the QUERY STRING comes after the ?.

Can you clarify that this is your understanding as well, or do you consider all of /with/additional/path?and=a&query=string to be PATH_INFO?

[lmcmicu]

Further to that, after some investigation I am reasonably confident in saying that this will be straightforward to implement provided that:

1. PATH_INFO is interpreted in the way that I described in my previous comment. If, on the other hand, in a URL like http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string, PATH_INFO includes all of /with/additional/path?and=a&query=string then I'm not sure how to proceed. One problem is that it becomes ambiguous in any given case whether we should interpret ?and=a&query=string as part of PATH_INFO or as part of the QUERY_STRING. Another problem (which I'm less sure about and would need to investigate a little more) is that we might run into some conflicts with implicit query parameter parsing that is done at the level of ring.
2. We need to come up with some convention for distinguishing path information in the Makefile. For example, suppose we have: ./build/balrog-script.py/with/additional/path. Currently DROID will interpret this as pointing to an executable called path in the subdirectory build/balrog-script.py/with/additional/. If we want DROID to be smart enough to interpret /with/additional/path as PATH_INFO then we need to give it some help. Off the top of my head I can think of two ways of doing this (there may be others).
   a. When a path begins in ./ it should be understood to end when it finds an extension like .py, .sh, etc., and anything after such an extension should be interpreted as path info. I don't like this solution that much since I feel that we shouldn't force people to refrain from putting . in their filenames if they wish.
   b. We could explicitly distinguish path information in the Makefile with a special character. For example, ./build/balrog-script.py:with/additional/path. Of course it needn't be : but could be any character we like. I like this better and I've already tested to make sure it will work.

[jamesaoverton]

1. I agree that PATH_INFO and QUERY_STRING are distinct and non-overlapping. Sorry if I muddled thy above.

2. In the Makefile I only want to specify the path to the CGI file, e.g. ./build/balrog-script.py. Any PATH_INFO will only be come from the URL, not the Makefile.