Rewrite URI into request arguments about unit HOT 9 OPEN

Hi,
Take a look at this #732 (comment).

You might write the configuration like:

-- deleted --

{
  "match": {
    "uri": "~^(?<some_var>.*)$"
  },
  "action": {
     "set": {
        "args": "/index.php?__path__=/$some_var"
      }
  }
}

Unit now doesn't support custom variables from regexp with the rewrite option.
We will support it in the 1.33 version. On the 1.32 currently.

from unit.

You might write the configuration like:

{
  "match": {
    "uri": "~^(?<some_var>.*)$"
  },
  "action": {
    "rewrite": "/index.php?__path__=/$some_var"
  }
}

The previous request arguments are appended after a ?. In this case, there will be two ? in the rewritten URI.

Nginx handles this by appending a & instead of ? in ngx_http_script.c.

from unit.

Sorry, I used the wrong configuration.

https://unit.nginx.org/configuration/#uri-rewrite

It does not affect the query but changes the uri and $request_uri variables.

And we have an idea of how to change the query, but it's not clear yet.
It's a topic of updating variables, like:

{
  "match": {
    "uri": "~^(?<some_var>.*)$"
  },
  "action": {
     "set": {
        "args": "/index.php?__path__=/$some_var"
      }
  }
}

Anyway, we need to support custom variables with the captured regexp names.
Welcome to your suggestions on it.

from unit.

The syntax looks OK, except that I don't think ~ is needed (unless it's part of syntax to enable regex).

You will need to consider what to do with the previous request arguments (i.e. existing arguments before the rewrite). Nginx has a "putting a question mark at the end of a replacement string" way of configuring it, but it's a bit too obscure.

from unit.

Actually, in nginx, you also can set $args variables to change the request query.

You will need to consider what to do with the previous request arguments

We intend to make the usage as concise as possible, and nginx's way is more powerful with more rules.
As you showed in the source code, the rewrite in nginx is very powerful with more code lines.

from unit.

@hongzhidao as we have worked on #916 we made use of njs in the rewrite part with some great success in terms of regexs. For example

{
"action": {
				"rewrite": "`${uri.replace(/^(\\/[^\\/]+)?(\\/.*\\.php)/, '$2')}`",
				"share": "/sites/$host$uri",
				"fallback": {
					"pass": "applications/$host/index"
				}
			}
}

In this example we are using matching blocks of the regext to build a new URI. Coulnd't this help in this case?

from unit.

It looks like the case is related to how to change/rewrite the request query/arguments. And the rewrite option only affects the uri.

from unit.

Okay then scratch that. Let's think about enhancing the rewrite support and what release is a good fit for that.

from unit.

https://nginx.org/en/docs/http/ngx_http_rewrite_module.html

If a replacement string includes the new request arguments, the previous request arguments are appended after them. If this is undesired, putting a question mark at the end of a replacement string avoids having them appended, for example:

I would say the rule is complicated, It has advantages and disadvantages in terms of use and implementation cost.

from unit.