The code for finding the extension made a few assumptions that are
no longer true.  It didn't account for pathnames that didn't
contain '/', including the empty string, or the NULL string.  That
code was used with "share", which always had a '/', but now it's
also used with "index", which should not have a '/' in it.

This fix works by limiting the search to the beginning of the
string, so that if no '/' is found in it, it doesn't continue
searching before the beginning of the string.

This also happens to work for NULL.  It is technically Undefined
Behavior, as we rely on `NULL + 0 == NULL` and `NULL - NULL == 0`.
But that is the only sane behavior for an implementation, and all
existing POSIX implementations will Just Work for this code.

Relying on this UB is useful, because we don't need to add an
explicit check for NULL, and therefore we have faster code.
Although the current code can't have a NULL, I expect that when we
add support for variables in the index, it will be NULL in some
cases.

Link: <https://stackoverflow.com/q/67291052/6872717>

The same code seems to be defined behavior in C++, which normally
will share implementation in the compiler for these cases, and
therefore it is really unlikely to be in trouble.

Link: <https://stackoverflow.com/q/59409034/6872717>

Before Node.js v16.14.0 the "format" value in defaultResolve
was ignored so error was hidden.  For more information see:
https://github.com/nodejs/node/pull/40980

This supports a new variable $request_uri that contains the path
and the query (See RFC 3986, section 3).  Its contents are percent
encoded.  This is useful for example to redirect HTTP to HTTPS:

{
    "return": "301",
    "location": "https://$host$request_uri"
}

When <http://example.com/foo%23bar?baz> is requested, the server
redirects to <https://example.com/foo%23bar?baz>.

===

Testing:

//diff --git a/src/nxt_http_return.c b/src/nxt_http_return.c
//index 82c9156..adeb3a1 100644
//--- a/src/nxt_http_return.c
//+++ b/src/nxt_http_return.c
//@@ -196,6 +196,7 @@ nxt_http_return_send_ready(nxt_task_t *task,
    void *obj, void *data)
//         field->value = ctx->encoded.start;
//         field->value_length = ctx->encoded.length;
//     }
//+    fprintf(stderr, "ALX: target[%1$i]: <%2$.*1$s>\n",
    (int)r->target.length, r->target.start);
//
//     r->state = &nxt_http_return_send_state;
//

{
	"listeners": {
		"*:81": {
			"pass": "routes/ru"
		}
	},

	"routes": {
		"ru": [{
			"action": {
				"return": 301,
				"location": "$request_uri"
			}
		}]
	}
}

$ curl -i http://localhost:81/*foo%2Abar?baz#arg
HTTP/1.1 301 Moved Permanently
Location: /*foo%2Abar?baz
Server: Unit/1.27.0
Date: Mon, 30 May 2022 16:04:30 GMT
Content-Length: 0

$ sudo cat /usr/local/unit.log | grep ALX
ALX: target[15]: </*foo%2Abar?baz>

This supports a new option "index" that configures a custom index
file name to be served when a directory is requested.  This
initial support only allows a single fixed string.  An example:

{
	"share": "/www/data/static/$uri",
	"index": "lookatthis.htm"
}

When <example.com/foo/bar/> is requested,
</www/data/static/foo/bar/lookatthis.html> is served.

Default is "index.html".

===

nxt_conf_validator.c:

Accept "index" as a member of "share", and make sure it's a string.

===

I tried this feature in my own computer, where I tried the
following:

- Setting "index" to "lookatthis.htm", and check that the correct
  file is being served (check both a different name and a
  different extension).
- Not setting "index", and check that <index.html> is being
  served.
- Settind "index" to an array of strings, and check that the
  configuration fails:

{
	"error": "Invalid configuration.",
	"detail": "The \"index\" value must be a string, but not an array."
}

An empty string in Location was being handled specially by not sending a
Location header.  This may occur after variable resolution, so we need to
consider this scenario.

The obsolete RFC 2616 defined the Location header as consisting of an absolute
URI <https://www.rfc-editor.org/rfc/rfc2616#section-14.30>, which cannot be an
empty string.  However, the current RFC 7231 allows the Location to be a
relative URI <https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2>, and a
relative URI may be an empty string <https://stackoverflow.com/a/43338457>.

Due to these considerations, this patch allows sending an empty Location header
without handling this case specially.  This behavior will probably be more
straightforward to users, too.  It also simplifies the code, which is now more
readable, fast, and conformant to the current RFC.  We're skipping an
allocation at request time in a common case such as "action": {"return": 404}