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.
The API for connecting to WebSockets in browsers unfortunately doesn't
support setting any Authorization header. This means that before this
commit it was impossible to connect to the API relay from a web browser.
The only thing that can be set apart from the URL is the
Sec-WebSocket-Protocol header. Therefore this allows you to send the
auth token in this header.
This is a weird way to send auth, but it seems to be the best one that
makes it possible for browsers to connect. Kubernetes also does it this
way: https://github.com/kubernetes/kubernetes/pull/47740
Here is a post describing the different ways to make it possible for a
browser to authenticate against a websocket connection, and it also
recommends doing it this way:
https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api/77060459#77060459
Note that when this header is used to pass auth, the client also needs
to specify the `api.weechat` sub protocol. This is because the client
and server have to agree on a sub protocol when this header is
specified, and in order to not send the fake protocol used for auth back
to the client, we require specifying the protocol `api.weechat`, which
the server then returns to the client. This is only necessary when the
Sec-WebSocket-Protocol header is used. If the Authorization header is
used for auth as before, nothing changes.
Detail of changes:
- the save of upgrade files in plugins is now done as soon as the "upgrade"
signal is received, and not when the plugin is unloaded (it was too late to
detect any problem and prevent the upgrade to happen)
- if the write of an upgrade file fails, the signal callback in plugin now
returns WEECHAT_RC_ERROR and WeeChat checks this code to stop the upgrade as
soon as this return code is received
- a new flag is added in plugin structure: unload_with_upgrade, it is set to 1
before unloading all plugins when upgrade will happen (all *.upgrade files
are then already successfully written).
For now the only supported flag is:
- "stop_on_error": stop execution of callbacks immediately after an
error (ie return code of callback is WEECHAT_RC_ERROR) and return this code
(by default execute all callbacks and return the last return code, or return
WEECHAT_RC_EAT immediately if a callback returns this)
Example:
hook_signal_send("[flags:stop_on_error]my_signal", WEECHAT_HOOK_SIGNAL_STRING, "test");
Sébastien Helleu