This fixes the following CMake warning:
CMake Warning (dev) at src/gui/curses/normal/CMakeLists.txt:73 (add_custom_command):
Exactly one of PRE_BUILD, PRE_LINK, or POST_BUILD must be given. Assuming
POST_BUILD to preserve backward compatibility.
Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
This fixes a crash which would happen if you scrolled the script buffer
and then did a search which got fewer search results than the index of
the selected line before the search. E.g. press page down to go to the
second page and then search for `test`.
It turns out that Debian has reverted the commit in Perl that broke the
locale in their 5.38 branch, so it did not have the issue. However, the
workaround we added to fix the locale apparently makes the version
Debian/Ubuntu has crash on perl_destruct. I'm not sure why it makes it
crash, but since it doesn't crash on newer Perl versions, I'm assuming
that it's another bug with the locale handling in that Perl version.
To avoid the crash, make sure to only set the locale if we detect that
it has been broken by Perl. We do this by checking if the value returned
by wcwidth (160) (the first non-ascii printable character) has changed.
If this value is not the same after the call to perl_construct, the
locale has been broken.
I moved the call to Perl_setlocale to right after perl_construct, as the
call to perl_construct is what breaks the locale.
Apparently the issue with the locale being reset with Perl 5.38 can
cause a crash when unloading the scripts on some systems (at least
Ubuntu 24.04). There was a workaround added in commit f4b9cad72, but it
doesn't work to avoid the crash. However if we set LC_ALL instead of
LC_CTYPE the crash doesn't occur.
Fixes#2187
If a request repeats the same header name multiple times, merge the
header values into a comma separated string. Previously, only the last
header specified would be used.
For header fields that are defined as a comma-separated list, a client
may choose to send it as multiple headers instead of one header with
comma-separated values. The specification says that these are
equivalent, so we can therefore join the headers into a comma-separated
string.
This is specified at https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2
which says:
A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
Sébastien Helleu