The Perl, PHP, Python, Ruby & Java language modules all hard code
SERVER_PORT to "80".

Adjust them to bring them in line with the wasm language module which
uses r->local_port (I.e. the port unit accepted the connection on).

Closes: https://github.com/nginx/unit/issues/761
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

GCC 15 enabled "-Wzero-as-null-pointer-constant" for C, which checks for
places where '0' has been used as a null pointer constant.

This showed a few places in Unit where we were using '0' instead of the
more correct NULL macro. E.g.

  $ make -j4 EXTRA_CFLAGS=-Wzero-as-null-pointer-constant
  ...
  src/nxt_buf.c: In function ‘nxt_buf_mmap_alloc’:
  src/nxt_buf.h:192:21: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant]
    192 |         (bm)->start = 0;                                                      \
        |                     ^
  src/nxt_buf.c:135:9: note: in expansion of macro ‘nxt_buf_mem_set_size’
    135 |         nxt_buf_mem_set_size(&b->mem, size);
        |         ^~~~~~~~~~~~~~~~~~~~

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

Ruby 3.4 started to actually mark some deprecated functions as
*deprecated* now resulting in compiler warnings (which due to -Werror we
treat as errors and thus the build fails).

The *new* functions were actually introduced back in Ruby 1.9.2, so have
been around for quite some time. We claim support for Ruby 2.0 onwards
so this is more than fine.

The new API replaces the old 'mark' and 'free' parameters with a struct
that allows for more fine tuning/configuration. We never made use of
either of those parameters and so the only members of this struct we
*need* to set is the structure wrapper name and the dsize function
pointer which is passed a pointer to the underlying wrapped structure to
calculate its memory usage. While this is *not* required the
documentation *recommends* setting it (though it doesn't say how it's
used).

Ruby pytests still pass after this change...

Closes: https://github.com/nginx/unit/issues/1525
Link: <https://bugs.ruby-lang.org/issues/19998>
Link: <https://docs.ruby-lang.org/en/3.4/extension_rdoc.html#label-C+struct+to+Ruby+object>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

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.