Previously, all requests that contained in header field names characters other
than alphanumeric, or "-", or "_" were rejected with a 400 "Bad Request" error
response.
Now, the parser allows the same set of characters as specified in RFC 7230,
including: "!", "#", "$", "%", "&", "'", "*", "+", ".", "^", "`", "|", and "~".
Header field names that contain only these characters are considered valid.
Also, there's a new option introduced: "discard_unsafe_fields". It accepts
boolean value and it is set to "true" by default.
When this option is "true", all header field names that contain characters
in valid range, but other than alphanumeric or "-" are skipped during parsing.
When the option is "false", these header fields aren't skipped.
Requests with non-valid characters in header field names according to
RFC 7230 are rejected regardless of "discard_unsafe_fields" setting.
This closes#422 issue on GitHub.
The php_request_shutdown() function calls sapi_deactivate() that tries to read
request body into a dummy buffer. In our case it's just waste of CPU cycles.
This change is also required for the following implementation of the
fastcgi_finish_request() function, where the request context can be
cleared by the time of finalization.
This variant will be more interoperable across various systems
and it's already used in Ruby module.
Otherwise, configure tests fail on NetBSD with:
gcc: Missing argument for -Wl,-rpath
PyUnicode_GET_SIZE() in deprecated since 3.3 and will be removed in 3.12.
In version 3.9 it was explicitly marked by deprecation warning causing
compilation error with Unit.
PyUnicode_GET_LENGTH() must be used instead.
AVIF is a modern image format based on the AV1 video codec. It generally has
better compression than other widely used formats (WebP, JPEG, PNG, and GIF)
and is designed to supersede them. Support was already added to the latest
version of Chrome.
APNG extends PNG to permit animated images that work similarly to animated GIF.
It's supported by most modern browsers.
Also removed duplicated ".svg" entry.
It's not used since cbcd76704c90.
This option is a leftover from previous IPC between router and applications
processes. It was never documented, though.
Thanks to 洪志道 (Hong Zhi Dao).
An attempt to build a Ruby module for a custom Ruby installation that has the
same major version as the system Ruby may unexpectedly cause the use of the
system Ruby library.
This closes#449 issue on GitHub.
The invocation parameters should be logged as well, notably the path of the file
that is failed to be created.
Also, log level changed to ALERT as it's quite critical error.
Earlier, if nxt_mp_create() failed to allocate memory while accepting a new
connection, the resulting NULL was subsequently passed to nxt_mp_destroy(),
crashing the process.
More, if nxt_mp_create() was successful but nxt_sockaddr_cache_alloc() failed,
the connection object wasn't destroyed properly, leaving the connection counter
in an inconsistent state. Repeated, this condition lowered the connection
capacity of the process and could eventually prevent it from accepting
connections altogether.
Previously, the log message callback used a generic log function, that relied on the process time cache.
Since there were no time update calls in the application processes, all log lines were printed with the
same time, usually correlated with the process start.
Now, a non-cached logging function from libunit is used.
This makes log format used in libunit consistent with the daemon, where milliseconds are printed only in the
debug log level.
Currently a compile time switch is used, since there's no support for runtime changing of a log level for now.
But in the future this should be a runtime condition, similar to nxt_log_time_handler().
According to the C standard, pointer arguments passed to memcpy() calls shall
still have valid values. NULL is considered as invalid.
Found with GCC Static Analyzer.
This is useful to escape "/" in path fragments. For example, in order
to reference the application named "foo/bar":
{
"pass": "applications/foo%2Fbar"
}
One of the ways to detect Unit's startup and subsequent readiness to accept
commands relies on waiting for the control socket file to be created.
Earlier, it was unreliable due to a race condition between the client's
connect() and the daemon's listen() calls after the socket's bind() call.
Now, unix domain listening sockets are created with a nxt_listen_socket_create()
call as follows:
s = socket();
unlink("path/to/socket.tmp")
bind(s, "path/to/socket.tmp");
listen(s);
rename("path/to/socket.tmp", "path/to/socket");
This eliminates a time-lapse when the socket file is already created but nobody
is listening on it yet, which therefore prevents the condition described above.
Also, it allows reliably detecting whether the socket is being used or simply
wasn't cleaned after the daemon stopped abruptly. A successful connection to
the socket file means the daemon has been started; otherwise, the file can be
overwritten.
The "return" action can be used to immediately generate a simple HTTP response
with an arbitrary status:
{
"action": {
"return": 404
}
}
This is especially useful for denying access to specific resources.
It allows proceeding to another action if a file isn't available.
An example:
{
"share": "/data/www/",
"fallback": {
"pass": "applications/php"
}
}
In the example above, an attempt is made first to serve a request with
a file from the "/data/www/" directory. If there's no such file, the
request is passed to the "php" application.
Fallback actions may be nested:
{
"share": "/data/www/",
"fallback": {
"share": "/data/cache/",
"fallback": {
"proxy": "http://127.0.0.1:9000"
}
}
}
A check for the ".php" extension is added to prevent execution of files
with arbitrary extensions in cases where "index" and "script" options
aren't used.
A quote from the Python 3 documentation:
| When interactive, stdout and stderr streams are line-buffered.
| Otherwise, they are block-buffered like regular text files.
As a result, if an exception occurred and PyErr_Print() was called, its output
could be buffered but not printed to the log for a while (ultimately, until
the interpreter finalization). If the application process crashed shortly,
the backtrace was completely lost.
Buffering can be disabled by redefining the sys.stderr stream object.
However, interference with standard environment objects was deemed undesirable.
Instead, sys.stderr.flush() is called every time after printing exceptions.
A potential advantage here is that lines from backtraces won't be mixed
with other lines in the log.
PyObject_HasAttrString() is just a wrapper over PyObject_GetAttrString(),
while PyObject_CallMethod() calls it as the first step. As a result,
PyObject_GetAttrString() was called twice if close() was present.
To get rid of PyObject_HasAttrString() while keeping the same behaviour,
the PyObject_CallMethod() call has been decomposed into separate calls of
PyObject_GetAttrString() and PyObject_CallFunction().
On success, PyObject_CallMethod() returns a new reference to
the result of the call, which previously got lost.
Also, error logging on failure was added.
The issue was introduced by b0148ec28c4d.
Valentin Bartenev