Coverity picked up a potential issue with the previous commit d9f5f1fb7
("Ruby: Handle response field arrays") in that a size_t could wrap
around to SIZE_MAX - 1.

This would happen if we were given an empty array of header values.

Fixes: d9f5f1fb7 ("Ruby: Handle response field arrays")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

@xeron on GitHub reported an issue whereby with a Rails 7.1 application
they were getting the following error

  2023/10/22 20:57:28 [error] 56#56 [unit] #8: Ruby: Wrong header entry 'value' from application
  2023/10/22 20:57:28 [error] 56#56 [unit] #8: Ruby: Failed to run ruby script

After some back and forth debugging it turns out rack was trying to send
back a header comprised of an array of values. E.g

  app = Proc.new do |env|
      ["200", {
          "Content-Type" => "text/plain",
          "X-Array-Header" => ["Item-1", "Item-2"],
      }, ["Hello World\n"]]
  end

  run app

It seems this became a possibility in rack v3.0[0]

So along with a header value type of T_STRING we need to also allow
T_ARRAY.

If we get a T_ARRAY we need to build up the header field using the given
values.

E.g

  "X-Array-Header" => ["Item-1", "", "Item-3", "Item-4"],

becomes

  X-Array-Header: Item-1; ; Item-3; Item-4

[0]: <https://github.com/rack/rack/blob/main/UPGRADE-GUIDE.md?plain=1#L26>

Reported-by: Ivan Larionov <xeron.oskom@gmail.com>
Closes: <https://github.com/nginx/unit/issues/974>
Link: <https://github.com/nginx/unit/pull/998>
Tested-by: Timo Stark <t.stark@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

For consistency use nxt_ruby_exception_log() rather than nxt_alert() in
nxt_ruby_rack_init().

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Ruby applications would fail to start if they were using rack v3

  2022/09/28 15:48:46 [alert] 0#80912 [unit] Ruby: Failed to parse rack script
  2022/09/28 15:48:46 [notice] 80911#80911 app process 80912 exited with code 1

This was due to a change in the rack API

Rack V2

  def self.load_file(path, opts = Server::Options.new)
    ...
    cfgfile.sub!(/^__END__\n.*\Z/m, '')
    app = new_from_string cfgfile, path

    return app, options
  end

Rack V3

  def self.load_file(path)
    ...

    return new_from_string(config, path)
  end

This patch handles _both_ the above APIs by correctly handling the cases
where we do and don't get an array returned from
nxt_ruby_rack_parse_script().

Closes: <https://github.com/nginx/unit/issues/755>
Tested-by: Andrew Clayton <a.clayton@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Andrew: Patch by Zhidao, commit message by me with input from Zhidao ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This is a preparatory patch that renames the 'local' and 'local_length'
members of the nxt_unit_request_t structure to 'local_addr' and
'local_addr_length' in preparation for the adding of 'local_port' and
'local_port_length' members.

Suggested-by: Zhidao HONG <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

As was reported[0] by @travisbell on GitHub, if running unit from the
terminal in the foreground when hitting ^C to exit it, the ruby
application processes would segfault if they were using threads.

It's not 100% clear where the actual problem lies, but it _looks_ like
it may be in ruby.

The simplest way to deal with this for now is to just ignore SIGINT in
the ruby application processes. Unit will still receive and handle it,
cleanly shutting everything down.

For people who want to handle SIGINT in their ruby application running
under unit they can still trap SIGINT and it will override the ignore.

[0]: https://github.com/nginx/unit/issues/562#issuecomment-1223229585

Closes: https://github.com/nginx/unit/issues/562

This closes #562 issue on GitHub.

Having the basename of the script pathname was incorrect.  While
we don't have something more accurate, the best thing to do is to
have it empty (which should be the right thing most of the time).

This closes #715 issue on GitHub.

The bug was introduced in git commit
0032543fa65f454c471c968998190b027c1ff270
'Ruby: added the Rack environment parameter "SCRIPT_NAME".'.

This closes #654 issue on Github.