Your message dated Fri, 10 Dec 2021 20:22:17 +0100
with message-id <163916413736.385125.5899947248433429691@localhost>
and subject line Re: Bug#983679: searx: Extraneous /searx/ added to URL
has caused the Debian Bug report #983679,
regarding searx: Extraneous /searx/ added to URL
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
983679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983679
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: searx
Version: 0.18.0+dfsg1-1
Severity: normal
Dear Maintainer,
It appears that Searx is adding an extra /searx/ to its own URLs.
My setup is:
- Apache hosting my domain example.org and proxying Searx to example.org/searx/
- uwsgi hosting Searx.
Accessing example.org/searx, I see logs of 404s in the UWSGI log file:
[pid: 1844588|app: 0|req: 59/139] ::1 () {50 vars in 1319 bytes} [Sun Feb 28
10:45:14 2021] GET /searx/ => generated 11037 bytes in 5 msecs (HTTP/1.1 200) 3
headers in 114 bytes (1 switches on core 0)
[pid: 1844588|app: 0|req: 60/140] ::1 () {48 vars in 1357 bytes} [Sun Feb 28
10:45:14 2021] GET /searx/searx/static/js/jquery-1.11.1.min.js => generated
3673 bytes in 7 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core
0)
[pid: 1844590|app: 0|req: 23/141] ::1 () {48 vars in 1356 bytes} [Sun Feb 28
10:45:14 2021] GET /searx/searx/static/css/leaflet.min.css => generated 3673
bytes in 7 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core 0)
[pid: 1844589|app: 0|req: 37/142] ::1 () {48 vars in 1341 bytes} [Sun Feb 28
10:45:14 2021] GET /searx/searx/static/js/bootstrap.min.js => generated 3673
bytes in 4 msecs (HTTP/1.1 404) 3 headers in 120 bytes (2 switches on core 0)
[pid: 1844591|app: 0|req: 23/143] ::1 () {48 vars in 1416 bytes} [Sun Feb 28
10:45:14 2021] GET /searx/searx/static/themes/oscar/css/logicodev.min.css =>
generated 3673 bytes in 4 msecs (HTTP/1.1 404) 3 headers in 120 bytes (2
switches on core 0)
[pid: 1844589|app: 0|req: 38/144] ::1 () {48 vars in 1364 bytes} [Sun Feb 28
10:45:14 2021] GET /searx/searx/static/css/bootstrap.min.css => generated 3673
bytes in 8 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core 0)
Obviously this leads to a rather odd looking results page as all the extra
elements cannot be loaded.
I have found a workaround: change
base_url : "https://example.org/searx";
to
base_url : "https://example.org/";
This seems intuitively wrong to me but it works!
I think this issue began after upgrading to 0.18. I am not 100% certain here as
I have not used Searx for a while because it has been choking on Google
results. I try it every now and then to see if it's started working again.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1),
LANGUAGE=en_GB:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages searx depends on:
ii python3 3.9.1-1
ii python3-searx 0.18.0+dfsg1-1
searx recommends no packages.
Versions of packages searx suggests:
pn nginx <none>
ii uwsgi 2.0.19.1-6
ii uwsgi-plugin-python3 2.0.19.1-6
-- no debconf information
--- End Message ---
--- Begin Message ---
Quoting Alex DEKKER (2021-12-10 10:52:22)
> On 10/12/2021 07:44, Johannes Schauer Marin Rodrigues wrote:
> >
> > I don't understand what you think is a bug. It sounds like everything works
> > just as expected. And False is also the default in settings.yml.
> The "bug" is that it worked before an update, and after the update it didn't
> work until I amended the configuration. If you don't think it's actionable,
> then close it.
ah yes, indeed I also always reset my searx config on every upgrade. That's
also why the package doesn't install a config itself but requires manual
intervention: searx developers broke the configuration several times in the
past already, so every major upgrade needs another manual editing of the
configuration file, sadly.
Thank you anyways for filing the bug! I am running searx 1.0.0 on my own server
right now and can confirm that google works fine there.
Thanks!
cheers, josch
signature.asc
Description: signature
--- End Message ---
