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.
According to the documentation, PyObject_GetIter():
| Raises TypeError and returns NULL if the object cannot be iterated.
Previously, this exception wasn't printed or cleared and remained unhandled.
According to the documentation, PyIter_Next():
| If there are no remaining values, returns NULL with no exception set.
| If an error occurs while retrieving the item, returns NULL and passes
| along the exception.
Previously, this exception wasn't properly handled and the response was
finalized as successful.
This issue was introduced in b0148ec28c4d.
A check for PyErr_Occurred() located in the code below might print this
traceback or occasionally catch an exception from one of the two response
close() calls.
Albeit that exceptions from the close() calls also need to be catched,
it's clear that this particular check wasn't supposed to do so. This is
another issue and it will be fixed later.
This field was intended for MIME type lookup by file extension when serving
static files, but this use case is too narrow; only a fraction of requests
targets static content, and the URI presumably isn't rewritten. Moreover,
current implementation uses the entire filename for MIME type lookup if the
file has no extension.
Instead of extracting filenames and extensions when parsing requests, it's
easier to obtain them right before serving static content; this behavior is
already implemented. Thus, we can drop excessive logic from parser.
Earlier, the paths were normalized only if there was a "/" at the end, which
is wrong according to section 5.2.4 of RFC 3986 and hypothetically may allow
to the directory above the document root.
In theory, all space characters in request target must be encoded; however,
some clients may violate the specification. For the sake of interoperability,
Unit supports unencoded space characters.
Previously, if there was a space character before the extension or arguments
parts, those parts weren't recognized. Also, quoted symbols and complex
target weren't detected after a space character.
Some Perl compile options affects ABI and not using them while compiling
our module resulted in non-working build.
Notably on 32-bit Debian 10, Perl is built with -D_FILE_OFFSET_BITS=64
and our module after being compiled without this option caused segmentation
faults in unexpected places.
It's surplus option because the perl executable returns the proper path.
Also the Perl module configure script was cleaned up a bit.
Note that NXT_PERL_LDOPTS already contains the library path.
There's no reason to parse "http_status_line"; the PHP interpreter already
does this. If the line contains a valid status code, it's assigned to
"http_response_code".
This also fixes invalid status line handling, where the nxt_int_parse()
function returned -1; it was cast to unsigned, yielding response code 65535.
Now index is always initialized for create operations.
The changes in nxt_conf_op_compile() simplify adding upcoming support of
operations with arrays.
No functional changes.
According to CGI/1.1 RFC 3875:
The server MUST set this variable; if the Script-URI does not include a
query component, the QUERY_STRING MUST be defined as an empty string ("").
Python's PEP 333(3) allows omitting it in WSGI interface; PHP docs force no
requirements; PSGI and Rack specifications require it even if empty.
When nginx proxies requests over FastCGI, it always provides QUERY_STRING.
and some PHP apps have been observed to fail if it is missing (see issue
#201 on GitHub).
A drawback of this change (besides a small overhead) is that there will be
no easy way to tell a missing query string from an empty one (i.e. requests
with or without the "?" character); yet, it's negligible compared to the
possible benefits of wider application compatibility.
This closes#226 issue on GitHub.
While it looks nicer without zero 3-rd version number, this should
improve interoperability. Version string can be parsed or used for
sorting. And it is easier to handle and less confusing when there
is constant number of version parts.
Moreover, NPM also expects version format with 3 parts.
So ".0" has already been used in Node.js module version.
Previously, the nxt_router_prepare_msg() function expected server host among
other headers unmodified. It's not true anymore since normalization of the
Host header has been introduced in 77aad2c142a0.
The nxt_unit_split_host() function was removed. It didn't work correctly with
IPv6 literals. Anyway, after 77aad2c142a0 the port splitting is done in router
while Host header processing.
In order to reduce number of operations over rb-tree and process them in
batches simultaneously, all the timers changes are temporary stored in array.
While processing of these changes, the same memory is also used for storing
pointers to postpone timers adding.
As the same block of memory has been referenced by two different types of
pointers (nxt_timer_change_t * and nxt_timer_t **), some compilers may reorder
operations with these pointers and produce broken code. See ticket #221 on
GitHub for a particular case.
Now the same "nxt_timer_change_t" structure is used in both cases.
Also, reverted the -fno-strict-aliasing flag, which has been introduced in
ef76227ec159 as a workaround for this issue.
It doesn't do anything useful, among creating a JSON message and logging it
to debug log. Besides that it causes segmentation fault if the RPC handler
is triggered with an empty buffer due to exiting of the main process.
Valentin Bartenev