In nxt_unit_create() we could leak a mutex created in
nxt_unit_ctx_init().
This could happen if nxt_unit_ctx_init() succeeded but later on we
bailed out of nxt_unit_create(), we would destroy the mutex created in
nxt_unit_create() but not the one created in nxt_unit_ctx_init().
Reorder things so that we do the call to nxt_unit_create() after all the
other checks so if it fails we don't leak the mutex it created.
Co-developed-by: Andrew Clayton <a.clayton@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@f5.com>
Signed-off-by: Alex Colomar <a.colomar@f5.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
The previous commit added/fixed support for abstract Unix domain sockets
on Linux with a leading '@' or '\0'. To be consistent in all platforms,
treat those prefixes as markers for abstract sockets in all platforms,
and fail if abstract sockets are not supported by the platform.
That will avoid mistakes when copying a config file from a Linux system
and using it in non-Linux, which would surprisingly create a normal socket.
Unix domain sockets are normally backed by files in the
filesystem. This has historically been problematic when closing
and opening again such sockets, since SO_REUSEADDR is ignored for
Unix sockets (POSIX left the behavior of SO_REUSEADDR as
implementation-defined, and most --if not all-- implementations
decided to just ignore this flag).
Many solutions are available for this problem, but all of them
have important caveats:
- unlink(2) the file when it's not needed anymore.
This is not easy, because the process that controls the fd may
not be the same process that created the file, and may not have
file permissions to remove it.
Further solutions can be applied to that caveat:
- unlink(2) the file right after creation.
This will remove the pathname from the filesystem without
closing the socket (it will continue to live until the last fd
is closed). This is not useful for us, since we need the
pathname of the socket as its interface.
- chown(2) or chmod(2) the directory that contains the socket.
For removing a file from the filesystem, a process needs
write permissions in the containing directory. We could
put sockets in dummy directories that can be chown(2)ed to
nobody. This could be dangerous, though, as we don't control
the socket names. It is our users who configure the socket
name in their configuration, and so it's easy that they don't
understand the many implications of not chosing an appropriate
socket pathname. A user could unknowingly put the socket in a
directory that is not supposed to be owned by user nobody, and
if we blindly chown(2) or chmod(2) the directory, we could be
creating a big security hole.
- Ask the main process to remove the socket.
This would require a very complex communication mechanism with
the main process, which is not impossible, but let's avoid it
if there are simpler solutions.
- Give the child process the CAP_DAC_OVERRIDE capability.
That is one of the most powerful capabilities. A process with
that capability can be considered root for most practical
aspects. Even if the capability is disabled for most of the
lifetime of the process, there's a slight chance that a
malicious actor could activate it and then easily do serious
damage to the system.
- unlink(2) the file right before calling bind(2).
This is dangerous because another process (for example, another
running instance of unitd(8)), could be using the socket, and
removing the pathname from the filesystem would be problematic.
To do this correctly, a lot of checks should be added before the
actual unlink(2), which is error-prone, and difficult to do
correctly, and atomically.
- Use abstract-namespace Unix domain sockets.
This is the simplest solution, as it only requires accepting a
slightly different syntax (basically a @ prefix) for the socket
name, to transform it into a string starting with a null byte
('\0') that the kernel can understand. The patch is minimal.
Since abstract sockets live in an abstract namespace, they don't
create files in the filesystem, so there's no need to remove
them later. The kernel removes the name when the last fd to it
has been closed.
One caveat is that only Linux currently supports this kind of
Unix sockets. Of course, a solution to that could be to ask
other kernels to implement such a feature.
Another caveat is that filesystem permissions can't be used to
control access to the socket file (since, of course, there's no
file). Anyone knowing the socket name can access to it. The
only method to control access to it is by using
network_namespaces(7). Since in unitd(8) we're using 0666 file
sockets, abstract sockets should be no more insecure than that
(anyone can already read/write to the listener sockets).
- Ask the kernel to implement a simpler way to unlink(2) socket
files when they are not needed anymore. I've suggested that to
the <linux-fsdevel@vger.kernel.org> mailing list, in:
<lore.kernel.org/linux-fsdevel/0bc5f919-bcfd-8fd0-a16b-9f060088158a@gmail.com/T>
In this commit, I decided to go for the easiest/simplest solution,
which is abstract sockets. In fact, we already had partial
support. This commit only fixes some small bug in the existing
code so that abstract Unix sockets work:
- Don't chmod(2) the socket if it's an abstract one.
This fixes the creation of abstract sockets, but doesn't make them
usable, since we produce them with a trailing '\0' in their name.
That will be fixed in the following commit.
This closes#669 issue on GitHub.
Registering an isolated PID in the global PID hash is wrong
because it can be duplicated. Isolated processes are stored only
in the children list until the response for the WHOAMI message is
processed and the global PID is discovered.
To remove isolated siblings, a pointer to the children list is
introduced in the nxt_process_init_t struct.
This closes#633 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
0032543fa6
'Ruby: added the Rack environment parameter "SCRIPT_NAME".'.
Allow $dollar (or ${dollar}) to translate to a literal $ to allow
support for sub-delimiters in URIs.
It is possible to have URLs like
https://example.com/path/15$1588/9925$2976.html
and thus it would be useful to be able to specify them in various bits
of the unit config such as the location setting.
However this hadn't been possible due to $ being used to denote
variables for substitution. E.g $host.
As was noted in the below GitHub issue it was suggested by @VBart to
use $sign to represent a literal $, however I feel $dollar is more
appropriate so we have a variable named after the thing it represents,
also @tippexs found[0] that &dollar is used in HTML to represent a $, so
there is some somewhat related precedent.
(The other idea to use $$ was rejected in my original pull-request[1]
for this issue.)
This means the above URL could be specified as
https://example.com/path/15${dollar}1588/9925${dollar}2976.html
in the unit config.
This is done by adding a variable called 'dollar' which is loaded into
the variables hash table which translates into a literal $.
This is then handled in nxt_var_next_part() where variables are parsed
for lookup and $dollar is set for substitution by a literal '$'. Actual
variable substitution happens in nxt_var_query_finish().
[0]: https://github.com/nginx/unit/pull/693#issuecomment-1130412323
[1]: https://github.com/nginx/unit/pull/693
Closes: https://github.com/nginx/unit/issues/675
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>
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}
............
Description:
............
Before this commit, the encoded URI could be calculated at
configuration time. Now, since variables can only be resolved at
request time, we have different situations:
- "location" contains no variables:
In this case, we still encode the URI in the conf structure, at
configuration time, and then we just copy the resulting string
to the ctx structure at request time.
- "location" contains variables:
In this case, we compile the var string at configure time, then
when we resolve it at request time, and then we encode the
string.
In both cases, as was being done before, if the string is empty,
either before or after resolving variables, we skip the encoding.
...........
Usefulness:
...........
An example of why this feature may be useful is redirecting HTTP
to HTTPS with something like:
"action": {
"return": 301,
"location": "https://${host}${uri}"
}
.....
Bugs:
.....
This feature conflicts with the relevant RFCs in the following:
'$' is used for Unit variables, but '$' is a reserved character in
a URI, to be used as a sub-delimiter. However, it's almost never
used as that, and in fact, other parts of Unit already conflict
with '$' being a reserved character for use as a sub-delimiter, so
this is at least consistent in that sense. VBart suggested an
easy workaround if we ever need it: adding a variable '$sign'
which resolves to a literal '$'.
......
Notes:
......
An empty string is handled as if "location" wasn't specified at
all, so no Location header is sent.
This is incorrect, and the code is slightly misleading.
The Location header consists of a URI-reference[1], which might be
a relative one, which itself might consist of an empty string[2].
[1]: <https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2>
[2]: <https://stackoverflow.com/a/43338457>
Now that we have variables, it's more likely that an empty
Location header will be requested, and we should handle it
correctly.
I think in a future commit we should modify the code to allow
differentiating between an unset "location" and an empty one,
which should be treated as any other "location" string.
.................
Testing (manual):
.................
{
"listeners": {
"*:80": {
"pass": "routes/str"
},
"*:81": {
"pass": "routes/empty"
},
"*:82": {
"pass": "routes/var"
},
"*:83": {
"pass": "routes/enc-str"
},
"*:84": {
"pass": "routes/enc-var"
}
},
"routes": {
"str": [
{
"action": {
"return": 301,
"location": "foo"
}
}
],
"empty": [
{
"action": {
"return": 301,
"location": ""
}
}
],
"var": [
{
"action": {
"return": 301,
"location": "$host"
}
}
],
"enc-str": [
{
"action": {
"return": 301,
"location": "f%23o#o"
}
}
],
"enc-var": [
{
"action": {
"return": 301,
"location": "f%23o${host}#o"
}
}
]
}
}
$ curl --dump-header - localhost:80
HTTP/1.1 301 Moved Permanently
Location: foo
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:06 GMT
Content-Length: 0
$ curl --dump-header - localhost:81
HTTP/1.1 301 Moved Permanently
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:08 GMT
Content-Length: 0
$ curl --dump-header - localhost:82
HTTP/1.1 301 Moved Permanently
Location: localhost
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:15 GMT
Content-Length: 0
$ curl --dump-header - -H "Host: bar" localhost:82
HTTP/1.1 301 Moved Permanently
Location: bar
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:23 GMT
Content-Length: 0
$ curl --dump-header - -H "Host: " localhost:82
HTTP/1.1 301 Moved Permanently
Server: Unit/1.27.0
Date: Thu, 07 Apr 2022 23:30:29 GMT
Content-Length: 0
$ curl --dump-header - localhost:83
HTTP/1.1 301 Moved Permanently
Location: f%23o#o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:22:23 GMT
Content-Length: 0
$ curl --dump-header - -H "Host: " localhost:84
HTTP/1.1 301 Moved Permanently
Location: f%23o#o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:22:44 GMT
Content-Length: 0
$ curl --dump-header - -H "Host: alx" localhost:84
HTTP/1.1 301 Moved Permanently
Location: f%23oalx#o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:22:52 GMT
Content-Length: 0
$ curl --dump-header - -H "Host: a#l%23x" localhost:84
HTTP/1.1 301 Moved Permanently
Location: f%2523oa#l%2523x%23o
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:23:09 GMT
Content-Length: 0
$ curl --dump-header - -H "Host: b##ar" localhost:82
HTTP/1.1 301 Moved Permanently
Location: b#%23ar
Server: Unit/1.27.0
Date: Sat, 09 Apr 2022 11:25:01 GMT
Content-Length: 0
The __call__ method can be native and not be a PyFunction type. A type check
is thus required before accessing op_code and other fields.
Reproduced on Ubuntu 21.04, Python 3.9.4 and Falcon framework: here, the
App.__call__ method is compiled with Cython, so accessing op_code->co_flags is
invalid; accidentally, the COROUTINE bit is set which forces the Python module
into the ASGI mode.
The workaround is explicit protocol specification.
Note: it is impossible to specify the legacy mode for ASGI.
- Ignoring Tomcat WebSocket container initialization.
- Renaming application class loader to UnitClassLoader to avoid
development environment enablement in Spring Boot.
This closes#609 issue on GitHub.
Application handler can do anything with a stream object (including close it).
Once the stream is closed, Unit creates a new stream.
This closes#616 issue on GitHub.
DragonFly BSD supports SCM_CREDS and SCM_RIGHTS, but only the first control
message is passed correctly while the second one isn't processed by the kernel.
This closes#599 issue on GitHub.
DragonFly BSD supports SCM_CREDS and SCM_RIGHTS, but only the first control
message is passed correctly while the second one isn't processed by the kernel.
This closes#599 issue on GitHub.
A prototype stores linked application processes structures. When an
application process terminates, it's removed from the list. To avoid double
removal, the pointer to the next element should be set to NULL.
The issue was introduced in c8790d2a89bb.
A prototype stores linked application processes structures. When an
application process terminates, it's removed from the list. To avoid double
removal, the pointer to the next element should be set to NULL.
The issue was introduced in c8790d2a89bb.
In PHP, custom fastcgi_finish_request() and overloaded chdir() functions can be
invoked by an OPcache preloading script (it runs when php_module_startup() is
called in the app process setup handler). In this case, there was no runtime
context set so trying to access it caused a segmentation fault.
This closes#602 issue on GitHub.
In PHP, custom fastcgi_finish_request() and overloaded chdir() functions can be
invoked by an OPcache preloading script (it runs when php_module_startup() is
called in the app process setup handler). In this case, there was no runtime
context set so trying to access it caused a segmentation fault.
This closes#602 issue on GitHub.
The reference to the access_log structure is stored in the current
nxt_router_conf_t and the global nxt_router_t. When the reference is copied,
the reference counter should be adjusted accordingly.
This closes#593 issue on GitHub.
The reference to the access_log structure is stored in the current
nxt_router_conf_t and the global nxt_router_t. When the reference is copied,
the reference counter should be adjusted accordingly.
This closes#593 issue on GitHub.
This commit supports variable in the "share" option, the finding path to
file serve is the value from "share". An example:
{
"share": "/www/data/static$uri"
}
Because the configuration values were read from the listener's configuration,
an established WebSocket connection was unable to work properly (i. e. stuck)
if the listener was removed. The correct source of configuration values is the
request config joint.
This is related to issue #581 on GitHub.
This commit introduces the replacement of the client address based on the value
of a specified HTTP header. This is intended for use when Unit is placed
behind a reverse proxy like nginx or a CDN.
You must specify the source addresses of the trusted proxies. This can be
accomplished with any valid IP pattern supported by Unit's match block:
["10.0.0.1", "10.4.0.0/16", "!192.168.1.1"]
The feature is configured per listener.
The client address replacement functionality only operates when there is a
source IP match and the specified header is present. Typically this would be
an 'X-Forwarded-For' header.
{
"listeners": {
"127.0.0.1:8080": {
"client_ip": {
"header": "X-Forwarded-For",
"source": [
"10.0.0.0/8"
]
},
"pass": "applications/my_app"
},
}
}
If a request occurs and Unit receives a header like below:
"X-Forwarded-For: 84.123.23.23"
By default, Unit trusts the last rightmost IP in the header, so REMOTE_ADDR
will be set to 84.123.23.23 if the connection originated from 10.0.0.0/8.
If Unit runs behind consecutive reverse proxies and receives a header similar
to the following:
"X-Forwarded-For: 84.123.23.23, 10.0.0.254"
You will need to enable "recursive" checking, which walks the header from
last address to first and chooses the first non-trusted address it finds.
{
"listeners": {
"127.0.0.1:8080": {
"client_ip": {
"header": "X-Forwarded-For",
"source": [
"10.0.0.0/8"
]
"recursive": true,
},
"pass": "applications/my_app"
},
}
}
If a connection from 10.0.0.0/8 occurs, the chain is walked. Here, 10.0.0.254
is also a trusted address so the client address will be replaced with
84.123.23.23.
If all IP addresses in the header are trusted, the client address is set to
the first address in the header:
If 10.0.0.0/8 is trusted and "X-Forwarded-For: 10.0.0.3, 10.0.0.2, 10.0.0.1",
the client address will be replaced with 10.0.0.3.
A crash would occur when the router tried to match an
against an empty address pattern array.
The following configuration was used to reproduce the
issue:
{
"listeners": {
"127.0.0.1:8082": {
"pass": "routes"
}
},
"routes": [
{
"match": {
"source": []
},
"action": {
"return": 200
}
}
]
}
When processing a restart request, the router sends a QUIT message to all
existing processes of the application. Then, a new shared application port is
created to ensure that new requests won't be handled by the old processes of
the application.
When a client sends no SNI is a common situation. But currently the server
processes it as an error and returns SSL_TLSEXT_ERR_ALERT_FATAL causing
termination of a current TLS session. The problem occurs if configuration has
more than one certificate bundle in a listener.
This fix changes the return code to SSL_TLSEXT_ERR_OK and the log level of a
message.
To support TLS sessions, Unit uses the OpenSSL built-in session cache; the
cache_size option defines the number sessions to store. To disable the feather,
the option must be zero.
The receive() call never blocks for a GET request and always returns the same
empty body message. The Starlette framework creates a separate task when
receive() is called in a loop until an 'http.disconnect' message is received.
The 'http.disconnect' message was previously issued after the response header
had been sent. However, the correct behavior is to respond with
'http.disconnect' after sending the response is complete.
This closes#564 issue on GitHub.
A new application thread port message can be processed in the router after the
application is removed from the router. Assertion for this case is replaced by
a condition to store the new thread port until receiving the stop notification
from the application process.
This feature allows one to specify blocks of code that are called when certain
lifecycle events occur. A user configures a "hooks" property on the app
configuration that points to a script. This script will be evaluated on boot
and should contain blocks of code that will be called on specific events.
An example of configuration:
{
"type": "ruby",
"processes": 2,
"threads": 2,
"user": "vagrant",
"group": "vagrant",
"script": "config.ru",
"hooks": "hooks.rb",
"working_directory": "/home/vagrant/unit/rbhooks",
"environment": {
"GEM_HOME": "/home/vagrant/.ruby"
}
}
An example of a valid "hooks.rb" file follows:
File.write("./hooks.#{Process.pid}", "hooks evaluated")
on_worker_boot do
File.write("./worker_boot.#{Process.pid}", "worker booted")
end
on_thread_boot do
File.write("./thread_boot.#{Process.pid}.#{Thread.current.object_id}",
"thread booted")
end
on_thread_shutdown do
File.write("./thread_shutdown.#{Process.pid}.#{Thread.current.object_id}",
"thread shutdown")
end
on_worker_shutdown do
File.write("./worker_shutdown.#{Process.pid}", "worker shutdown")
end
This closes issue #535 on GitHub.
When the textual representation of an IPv6 nxt_sockaddr_t was being
generated, a crash would occur if the address had a full IPv6 form:
f607:7403:1e4b:6c66:33b2:843f:2517:da27
This was caused by a variable that tracks the location of a
collapsed group ("::") that was not set to a sane default. When
the address was generated, a group would be inserted when
it was not necessary, thus causing an overflow.
This closes#481 issue on GitHub.
In rare cases, when the destination process had finished running but no
notification of this was received yet, send could fail with an error, and the
send message structure with file descriptors could leak.
The leakage was periodically reproduced by respawn tests on FreeBSD 12.
Because of the incorrect 'last' field assignment, multiple listeners with
a TLS certificate did not initialize properly, which caused a router crash
while establishing a connection.
Test with multiple TLS listeners added.
The issue was introduced in the c548e46fe516 commit.
This closes#561 issue on GitHub.
To perform various configuration operations on SSL_CTX, OpenSSL provides
SSL_CONF_cmd(). Specifically, to configure ciphers for a listener,
"CipherString" and "Ciphersuites" file commands are used:
https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
This feature can be configured in the "tls/conf_commands" section.
A crash was caused by an incorrect timer handler nxt_h1p_idle_timeout() if
SSL_shutdown() returned SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE.
The flag SSL_RECEIVED_SHUTDOWN is used to avoid getting SSL_ERROR_WANT_READ, so
the server won't wait for a close notification from a client.
For SSL_ERROR_WANT_WRITE, a correct timer handler is set up.
Ruby 3.0 deprecated rb_cData with the intention to remove it in release 3.1.
This commit changes references of rb_cData to rb_cObject. This was done so we
can support distributions that package Ruby 3.0, such as Fedora 34.
We also need to call rb_undef_alloc_func because we're no longer deriving from
rb_cData. This prevents unnecessary allocations.
See:
https://docs.ruby-lang.org/en/3.0.0/doc/extension_rdoc.html
"It is recommended that klass derives from a special class called Data
(rb_cData) but not from Object or other ordinal classes. If it doesn't,
you have to call rb_undef_alloc_func(klass)."
Also added stubs for Server.address()
This was done to prevent crashes in some popular frameworks like express
Supports both CommonJS and the new ES Modules system syntax e.g:
app.js:
const http = require('http')
app.mjs:
import http from "http"
Usage on Node 14.16.x and higher:
{
"type": "external",
"processes": {"spare": 0},
"working_directory": '/project',
"executable": "/usr/bin/env",
"arguments": [
"node",
"--loader",
"unit-http/require_shim.mjs"
"--require",
"unit-http/require_shim",
"app.js"
]
}
Usage on Node 14.15.x and lower:
{
"type": "external",
"processes": {"spare": 0},
"working_directory": '/project',
"executable": "/usr/bin/env",
"arguments": [
"node",
"--require",
"unit-http/require_shim",
"app.js"
]
}
The "auto_globals_jit" PHP option postponed the initialization of the $_SERVER
global variable until the script using it had been loaded (e. g. via the
"include" expression). As a result, nxt_php_register_variables() could be
called after fastcgi_finish_request() had finished the request and nulled
ctx->req, which thus caused a segmentation fault.
