[GH-ISSUE #54] [BUG] Firefox search bar just redirects me to the Whoogle homepage #32

Closed
opened 2026-02-25 20:34:44 +03:00 by kerem · 15 comments
Owner

Originally created by @edmael on GitHub (May 15, 2020).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/54

Describe the bug
When I search on my self-hosted Whoogle using Firefox bar the results is the homepage of my Whoogle instance rather than actual result page.

To Reproduce
Steps to reproduce the behavior:

  1. Add Whoogle to your search engine by clicking on the three dots in Firefox address bar
  2. Search something with the new added engine
  3. See error

Expected behavior
I expect to see the actual results of my query, not the Whoogle homepage.

Desktop (please complete the following information):

  • OS: Windows 10
  • Browser Firefox (both stable, nightly and beta)

Additional context
On my mobile phone everything works as expected: it seems the destkop version forgets the %s.

Originally created by @edmael on GitHub (May 15, 2020). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/54 **Describe the bug** When I search on my self-hosted Whoogle using Firefox bar the results is the homepage of my Whoogle instance rather than actual result page. **To Reproduce** Steps to reproduce the behavior: 1. Add Whoogle to your search engine by clicking on the three dots in Firefox address bar 2. Search something with the new added engine 3. See error **Expected behavior** I expect to see the actual results of my query, not the Whoogle homepage. **Desktop (please complete the following information):** - OS: Windows 10 - Browser Firefox (both stable, nightly and beta) **Additional context** On my mobile phone everything works as expected: it seems the destkop version forgets the %s.
kerem 2026-02-25 20:34:44 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@benbusby commented on GitHub (May 16, 2020):

How is your instance deployed (ie Heroku, reverse proxy, etc)? On desktop, search is generally done via POST request, so there shouldn’t be the %s url query parsing.

Can you try switching your config to “GET requests only” and see if that fixes it? You’ll likely need to remove the search template from Firefox on your desktop and re-add it after changing the config.

<!-- gh-comment-id:629557719 --> @benbusby commented on GitHub (May 16, 2020): How is your instance deployed (ie Heroku, reverse proxy, etc)? On desktop, search is generally done via POST request, so there shouldn’t be the %s url query parsing. Can you try switching your config to “GET requests only” and see if that fixes it? You’ll likely need to remove the search template from Firefox on your desktop and re-add it after changing the config.
Author
Owner

@benbusby commented on GitHub (May 16, 2020):

For added clarification, are you using the latest version of the master branch? I'm a bit confused, as I use Firefox for my desktop as well and am running the app fine. There are also tests in place to ensure this functionality works properly, unless there's something wrong with the opensearch template...which also seems unlikely, as I just went through and verified them on my end.

<!-- gh-comment-id:629561033 --> @benbusby commented on GitHub (May 16, 2020): For added clarification, are you using the latest version of the master branch? I'm a bit confused, as I use Firefox for my desktop as well and am running the app fine. There are also tests in place to ensure this functionality works properly, unless there's something wrong with the opensearch template...which also seems unlikely, as I just went through and verified them on my end.
Author
Owner

@edmael commented on GitHub (May 16, 2020):

Ok, setting "GET request only" fixed the problem for me even on the destkop, guess it was just that.
Running with docker-compose using the standard options and nothing else, the only thing that MAYBE can cause some problem is that I avoid exposing directly the docker port but I use a "master" nginx reverse proxy that expose all my services.

My whoogle.subdomain.conf is like this:

server {
listen 443 ssl;
listen [::]:443 ssl;
server_name search.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_app whoogle-search;
set $upstream_port 5000;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}

<!-- gh-comment-id:629612959 --> @edmael commented on GitHub (May 16, 2020): Ok, setting "GET request only" fixed the problem for me even on the destkop, guess it was just that. Running with docker-compose using the standard options and nothing else, the only thing that MAYBE can cause some problem is that I avoid exposing directly the docker port but I use a "master" nginx reverse proxy that expose all my services. My whoogle.subdomain.conf is like this: `server {` ` listen 443 ssl;` ` listen [::]:443 ssl;` ` server_name search.*;` ` include /config/nginx/ssl.conf;` ` client_max_body_size 0;` ` location / {` ` include /config/nginx/proxy.conf;` ` resolver 127.0.0.11 valid=30s;` ` set $upstream_app whoogle-search;` ` set $upstream_port 5000;` ` set $upstream_proto http;` ` proxy_pass $upstream_proto://$upstream_app:$upstream_port;` ` }` `}`
Author
Owner

@benbusby commented on GitHub (May 16, 2020):

So I looked into this a bit more, and discovered some language regarding 301 code redirects to HTTPS that I wasn't aware of before, namely that in the method description it states:

GET methods unchanged.
Others may or may not be changed to GET.

So it looks like it's just a matter of using 308 redirects instead, and explains why the POST search requests are working for some and not others. Should be easy enough, I'll push a fix soon.

<!-- gh-comment-id:629663214 --> @benbusby commented on GitHub (May 16, 2020): So I looked into this a bit more, and discovered some language regarding `301` code redirects to HTTPS that I wasn't aware of before, namely that in the [method description](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections) it states: > GET methods unchanged. Others may or may not be changed to GET. So it looks like it's just a matter of using `308` redirects instead, and explains why the POST search requests are working for some and not others. Should be easy enough, I'll push a fix soon.
Author
Owner

@benbusby commented on GitHub (May 16, 2020):

Ok, fixed in latest master now. If you're not letting Flask handle protocol redirects for you though, then it might be an issue with wherever you're setting redirects in your nginx config. If you have a 301 redirect in place somewhere else (i.e. return 301 https://$host$request_uri;) then that will need to be upgraded to use 308 as well in order to keep POST requests from changing to GET requests.

<!-- gh-comment-id:629664087 --> @benbusby commented on GitHub (May 16, 2020): Ok, fixed in latest master now. If you're not letting Flask handle protocol redirects for you though, then it might be an issue with wherever you're setting redirects in your nginx config. If you have a `301` redirect in place somewhere else (i.e. `return 301 https://$host$request_uri;`) then that will need to be upgraded to use `308` as well in order to keep POST requests from changing to GET requests.
Author
Owner

@alex-phillips commented on GitHub (Jun 20, 2020):

I'm getting this same issue. Using latest docker image, same compose file as in the repo, behind an reverse nginx proxy using HTTPS. One added on Firefox desktop, all search bar requests just take me to the home page.

As I said, running in docker. Using Firefox desktop on Ubuntu 20.04.

<!-- gh-comment-id:647041880 --> @alex-phillips commented on GitHub (Jun 20, 2020): I'm getting this same issue. Using latest docker image, same compose file as in the repo, behind an reverse nginx proxy using HTTPS. One added on Firefox desktop, all search bar requests just take me to the home page. As I said, running in docker. Using Firefox desktop on Ubuntu 20.04.
Author
Owner

@LivingWithHippos commented on GitHub (Jun 24, 2020):

I also have this issue. I think firefox is the problem since I can correctly use POST and GET from the page. The search bar plugin is provided by https://github.com/benbusby/whoogle-search/blob/develop/app/templates/opensearch.xml

The culprit is this line

  <Url type="text/html" method="{{ request_type }}" template="{{ main_url }}/search">
    <Param name="q" value="{searchTerms}"/>
  </Url>

that I changed to

<Url type="text/html" method="get" template="{{ main_url }}/search?q={searchTerms}"/>

as a temporary fix. All the searches from the bar will be with a GET method, but if you directly go to your website it will still be POST (or whatever you selected).
I didn't check autocomplete since I don' t use it but it should be similar.
I didn' t make a PR since I don' t think this is the best way.

If you like me want to test this in your existing docker container you can run bash on it
docker exec -it your_whoogle_container /bin/bash and edit (I installed nano with apt-get install nano) the file opensearch.xml under app/templates, then restart the container with 'docker restart your_whoogle_container'. You can check if it got loaded by going to whoogle-domain.whatever/opensearch.xml.
Remember to remove and re-add the whoogle search from Firefox settings or you'll keep the old one.

<!-- gh-comment-id:648846872 --> @LivingWithHippos commented on GitHub (Jun 24, 2020): I also have this issue. I think firefox is the problem since I can correctly use POST and GET from the page. The search bar plugin is provided by https://github.com/benbusby/whoogle-search/blob/develop/app/templates/opensearch.xml The culprit is this line ``` <Url type="text/html" method="{{ request_type }}" template="{{ main_url }}/search"> <Param name="q" value="{searchTerms}"/> </Url> ``` that I changed to `<Url type="text/html" method="get" template="{{ main_url }}/search?q={searchTerms}"/>` as a temporary fix. All the searches from the bar will be with a GET method, but if you directly go to your website it will still be POST (or whatever you selected). I didn't check autocomplete since I don' t use it but it should be similar. I didn' t make a PR since I don' t think this is the best way. If you like me want to test this in your existing docker container you can run bash on it `docker exec -it your_whoogle_container /bin/bash` and edit (I installed nano with `apt-get install nano`) the file opensearch.xml under app/templates, then restart the container with 'docker restart your_whoogle_container'. You can check if it got loaded by going to `whoogle-domain.whatever/opensearch.xml`. Remember to remove and re-add the whoogle search from Firefox settings or you'll keep the old one.
Author
Owner

@benbusby commented on GitHub (Jun 24, 2020):

I'm curious, are either of you using an older or beta version of Firefox? The majority of Firefox users I've spoken recently with haven't encountered this issue, and neither have I, but I'm running 77.0.1 without any opensearch issues. The fix mentioned above is how Firefox's internal parsing of the opensearch template should be functioning from their end -- the nested Param tag should get parsed to /search?q={searchTerms}" if using a GET method, otherwise the search term is POSTed to the server.

I'd be curious to see a server log capture from when the search bar is redirecting to the home page, and see if it's a 302 redirect or just a 200 (which would indicate that Firefox likely isn't sending the actual search term to the /search route).

<!-- gh-comment-id:648905142 --> @benbusby commented on GitHub (Jun 24, 2020): I'm curious, are either of you using an older or beta version of Firefox? The majority of Firefox users I've spoken recently with haven't encountered this issue, and neither have I, but I'm running `77.0.1` without any opensearch issues. The fix mentioned above is how Firefox's internal parsing of the opensearch template *should* be functioning from their end -- the nested `Param` tag should get parsed to `/search?q={searchTerms}"` if using a GET method, otherwise the search term is POSTed to the server. I'd be curious to see a server log capture from when the search bar is redirecting to the home page, and see if it's a `302` redirect or just a `200` (which would indicate that Firefox likely isn't sending the actual search term to the `/search` route).
Author
Owner

@LivingWithHippos commented on GitHub (Jun 24, 2020):

No, I' m on latest too. Also didn' t work on android.
NGIX access.log

original opensearch

my-ip - - [24/Jun/2020:10:10:18 +0100] "POST /search HTTP/1.1" 301 169 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:10:18 +0100] "GET /search HTTP/2.0" 302 209 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:10:18 +0100] "GET / HTTP/2.0" 200 5197 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:10:19 +0100] "GET /config HTTP/2.0" 200 133 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:10:21 +0100] "GET /opensearch.xml HTTP/2.0" 200 857 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:11:36 +0100] "POST /search HTTP/1.1" 301 169 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:11:37 +0100] "GET /search HTTP/2.0" 302 209 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:11:37 +0100] "GET / HTTP/2.0" 200 5197 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:10:11:37 +0100] "GET /config HTTP/2.0" 200 133 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"

With my modification

my-ip - - [24/Jun/2020:18:44:04 +0100] "GET /search?q=apply+docker+voklume+edits HTTP/1.1" 301 169 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /search?q=apply+docker+voklume+edits HTTP/2.0" 200 11000 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/js/autocomplete.js HTTP/2.0" 200 3860 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/css/search.css HTTP/2.0" 200 640 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/css/header.css HTTP/2.0" 200 1061 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/img/favicon.ico HTTP/2.0" 200 1150 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0"
<!-- gh-comment-id:648972236 --> @LivingWithHippos commented on GitHub (Jun 24, 2020): No, I' m on latest too. Also didn' t work on android. NGIX access.log original opensearch ``` my-ip - - [24/Jun/2020:10:10:18 +0100] "POST /search HTTP/1.1" 301 169 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:10:18 +0100] "GET /search HTTP/2.0" 302 209 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:10:18 +0100] "GET / HTTP/2.0" 200 5197 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:10:19 +0100] "GET /config HTTP/2.0" 200 133 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:10:21 +0100] "GET /opensearch.xml HTTP/2.0" 200 857 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:11:36 +0100] "POST /search HTTP/1.1" 301 169 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:11:37 +0100] "GET /search HTTP/2.0" 302 209 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:11:37 +0100] "GET / HTTP/2.0" 200 5197 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:10:11:37 +0100] "GET /config HTTP/2.0" 200 133 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" ``` With my modification ``` my-ip - - [24/Jun/2020:18:44:04 +0100] "GET /search?q=apply+docker+voklume+edits HTTP/1.1" 301 169 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /search?q=apply+docker+voklume+edits HTTP/2.0" 200 11000 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/js/autocomplete.js HTTP/2.0" 200 3860 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/css/search.css HTTP/2.0" 200 640 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/css/header.css HTTP/2.0" 200 1061 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" my-ip - - [24/Jun/2020:18:44:05 +0100] "GET /static/img/favicon.ico HTTP/2.0" 200 1150 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0" ```
Author
Owner

@alex-phillips commented on GitHub (Jun 25, 2020):

Same. Using 77.0.1 with the latest whoogle docker container. It's worth noting that this was working for me at one point.

<!-- gh-comment-id:649599117 --> @alex-phillips commented on GitHub (Jun 25, 2020): Same. Using 77.0.1 with the latest whoogle docker container. It's worth noting that this _was_ working for me at one point.
Author
Owner

@alex-phillips commented on GitHub (Jul 2, 2020):

@benbusby Upgraded to FF 78 and still have this issue.

<!-- gh-comment-id:653012741 --> @alex-phillips commented on GitHub (Jul 2, 2020): @benbusby Upgraded to FF 78 and still have this issue.
Author
Owner

@clarkdave commented on GitHub (Aug 6, 2020):

Same issue here.

  • Firefox 79
  • Latest Whoogle docker with standard settings
  • Running behind nginx via https

After adding Whoogle as a Firefox search provider, any search result just goes to the Whoogle homepage. Here's my nginx log:

86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "POST /search HTTP/1.1" 301 170 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0"
86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "GET /search HTTP/1.1" 302 209 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0"
86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "GET / HTTP/1.1" 200 5245 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0"
86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "GET /config HTTP/1.1" 200 148 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0"

Manually editing the opensearch.xml as suggesed by LivingWithHippos does fix it.


update: actually, this is my error. My webserver was caching the opensearch.xml file, which initally defaulted to the http:// URL. So, even after I edited the config to set the correct base url, Firefox adding Whoogle using http:// which was resulting a redirect (as mentioned in comments above).

So, if you're also having this issue it's worth checking that you're not inadvertently caching the opensearch.xml file with the wrong configuration.

<!-- gh-comment-id:669924926 --> @clarkdave commented on GitHub (Aug 6, 2020): Same issue here. - Firefox 79 - Latest Whoogle docker with standard settings - Running behind nginx via https After adding Whoogle as a Firefox search provider, any search result just goes to the Whoogle homepage. Here's my nginx log: ``` 86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "POST /search HTTP/1.1" 301 170 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0" 86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "GET /search HTTP/1.1" 302 209 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0" 86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "GET / HTTP/1.1" 200 5245 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0" 86.26.240.135 - - [06/Aug/2020:13:02:27 +0000] "GET /config HTTP/1.1" 200 148 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0" ``` Manually editing the opensearch.xml as suggesed by LivingWithHippos does fix it. ---- **update:** actually, this is my error. My webserver was caching the `opensearch.xml` file, which initally defaulted to the `http://` URL. So, even after I edited the config to set the correct base url, Firefox adding Whoogle using `http://` which was resulting a redirect (as mentioned in comments above). So, if you're also having this issue it's worth checking that you're not inadvertently caching the `opensearch.xml` file with the wrong configuration.
Author
Owner

@Medformatik commented on GitHub (Mar 25, 2022):

Hello, have you found a solution to this problem? I have the same problem with Firefox 98.0.2 and a fresh Whoogle installation behind a Nginx proxy. I'm very enthusiastic about Whoogle, but if it doesn't work as a default search engine, then it's hard to use.

<!-- gh-comment-id:1079066832 --> @Medformatik commented on GitHub (Mar 25, 2022): Hello, have you found a solution to this problem? I have the same problem with Firefox 98.0.2 and a fresh Whoogle installation behind a Nginx proxy. I'm very enthusiastic about Whoogle, but if it doesn't work as a default search engine, then it's hard to use.
Author
Owner

@ludoctl commented on GitHub (Mar 28, 2022):

+1 here as I've just met the issue on FF 98.0.2 (64-bit) on Ubuntu. My setup works fine as default on my Android's Firefox Focus...

<!-- gh-comment-id:1080628457 --> @ludoctl commented on GitHub (Mar 28, 2022): +1 here as I've just met the issue on FF 98.0.2 (64-bit) on Ubuntu. My setup works fine as default on my Android's Firefox Focus...
Author
Owner

@gabviv73 commented on GitHub (Dec 21, 2022):

Same problem here: docker behind an apache reverse proxy with https and http to https redirect.
How to solve ?

<!-- gh-comment-id:1361753939 --> @gabviv73 commented on GitHub (Dec 21, 2022): Same problem here: docker behind an apache reverse proxy with https and http to https redirect. How to solve ?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/whoogle-search#32
No description provided.