add support for variables in match block

[yosefy]

why? if user has convention, we may declare block only once "match": { "host": "test..unit.com" } ---> "match": { "host": "$host" }

and then we can use it in application and share paths:

use case: example multiple wordpress installations in small config when wordpress hostname = directory it is in:

    "routes": [
        {
            "match": {
                "host": "$host",
                "uri": [
                    "*.php",
                    "*.php/*",
                    "/wp-admin/"
                ]
            },
            "action": {
                "pass": "applications/$host/direct"
            }
        },
        {
            "match": {
                "host": "$host""
            },
            "action": {
                "share": "/sites/$host/public$uri",
                "fallback": {
                    "pass": "applications/$host/index"
                }
            }
        }
    ],
    "applications": {
        "test.unit.com": {
            "type": "php",
            "targets": {
                "direct": {
                    "root": "/sites/$host/public/"
                },
                "index": {
                    "root": "/sites/$host/public/",
                    "script": "index.php"
                }
            }
        },

[lcrilly]

Matching "host": "$host" is redundant because it is always true. This configuration should work as you expect without the "host" match.

[yosefy]

yes sorry that is true , so another thing:

if we could teplate vars in application, then we wouldnt need to add multiple application block (having naming convention)

for example like this:

    "routes": [
        {
            "match": {
                "uri": [
                    "*.php",
                    "*.php/*",
                    "/wp-admin/"
                ]
            },
            "action": {
                "pass": "applications/wordpress/direct"
            }
        },
        {
            "action": {
                "share": "/sites/wordpress/public$uri",
                "fallback": {
                    "pass": "applications/wordpress/index"
                }
            }
        }
    ],
    "applications": {
        "wordpress": {
            "stderr": "${host}.log",
            "user": "$host",
            "type": "php",
            "targets": {
                "direct": {
                    "root": "/sites/$host/public/"
                },
                "index": {
                    "root": "/sites/$host/public/",
                    "script": "index.php"
                }
            }
        },

[lcrilly]

I can see the convenience of this approach but it would come at a cost.

Unit currently pre-creates a prototype process for each application with the configuration data for the app. It must also assign a user to own the process. The prototype is then used to fork new application processes as necessary. To do all of this dynamically, based on the variables of the current client request would have a noticeable impact on complexity and application performance.

By using JSON for Unit's configuration format, it is expected that such templating happens elsewhere to produce a configuration that is efficient at runtime.

[yosefy]

thanks it is clear