[GH-ISSUE #346] [BUG] Whoogle returns Internal Server error after 0.5.2. Update #230

Closed
opened 2026-02-25 20:35:13 +03:00 by kerem · 12 comments
Owner

Originally created by @timespacedecay on GitHub (Jun 3, 2021).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/346

Describe the bug
Whoogle returns 500 Internal Server error after 0.5.2. Update. Docker log shows the following:

ERROR:app:Exception on /search [POST]
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2446, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1951, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1820, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise
raise value
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1949, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1935, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/whoogle/app/routes.py", line 39, in decorated
return f(*args, **kwargs)
File "/whoogle/app/routes.py", line 223, in search
response = search_util.generate_response()
File "/whoogle/app/utils/search.py", line 131, in generate_response
get_body = g.user_request.send(query=full_query,
File "/whoogle/app/request.py", line 256, in send
response = requests.get(
File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 76, in get
return request('get', url, params=params, **kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 542, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 655, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
resp = conn.urlopen(
File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 696, in urlopen
self._prepare_proxy(conn)
File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 964, in _prepare_proxy
conn.connect()
File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 359, in connect
conn = self._connect_tls_proxy(hostname, conn)
File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 500, in _connect_tls_proxy
return ssl_wrap_socket(
File "/usr/local/lib/python3.8/site-packages/urllib3/util/ssl_.py", line 453, in ssl_wrap_socket
ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls)
File "/usr/local/lib/python3.8/site-packages/urllib3/util/ssl_.py", line 495, in _ssl_wrap_socket_impl
return ssl_context.wrap_socket(sock)
File "/usr/local/lib/python3.8/ssl.py", line 500, in wrap_socket
return self.sslsocket_class._create(
File "/usr/local/lib/python3.8/ssl.py", line 997, in _create
raise ValueError("check_hostname requires server_hostname")
ValueError: check_hostname requires server_hostname

To Reproduce
Steps to reproduce the behavior:

  1. Upgrade Docker version to 0.5.2 from 0.5.1
  2. Search
  3. Get error in browser
  4. Check Docker log

Deployment Method

  • Heroku (one-click deploy)
  • Docker
  • run executable
  • pip/pipx
  • Other: [describe setup]

Version of Whoogle Search

  • Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc)
  • Version 0.5.2
  • Not sure

Desktop (please complete the following information):

  • OS: [e.g. iOS] Windows 10
  • Browser [e.g. chrome, safari] Firefox
  • Version [e.g. 22] Latest

Additional context
Confirmed an issue specifically with 0.5.2; downgrading to 0.5.1 using the :0.5.1 tag results in the expected search behavior and no errors.

Originally created by @timespacedecay on GitHub (Jun 3, 2021). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/346 **Describe the bug** Whoogle returns 500 Internal Server error after 0.5.2. Update. Docker log shows the following: ``` ERROR:app:Exception on /search [POST] Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2446, in wsgi_app response = self.full_dispatch_request() File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1951, in full_dispatch_request rv = self.handle_user_exception(e) File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1820, in handle_user_exception reraise(exc_type, exc_value, tb) File "/usr/local/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise raise value File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1949, in full_dispatch_request rv = self.dispatch_request() File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1935, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/whoogle/app/routes.py", line 39, in decorated return f(*args, **kwargs) File "/whoogle/app/routes.py", line 223, in search response = search_util.generate_response() File "/whoogle/app/utils/search.py", line 131, in generate_response get_body = g.user_request.send(query=full_query, File "/whoogle/app/request.py", line 256, in send response = requests.get( File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 76, in get return request('get', url, params=params, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 61, in request return session.request(method=method, url=url, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 542, in request resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 655, in send r = adapter.send(request, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send resp = conn.urlopen( File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 696, in urlopen self._prepare_proxy(conn) File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 964, in _prepare_proxy conn.connect() File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 359, in connect conn = self._connect_tls_proxy(hostname, conn) File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 500, in _connect_tls_proxy return ssl_wrap_socket( File "/usr/local/lib/python3.8/site-packages/urllib3/util/ssl_.py", line 453, in ssl_wrap_socket ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls) File "/usr/local/lib/python3.8/site-packages/urllib3/util/ssl_.py", line 495, in _ssl_wrap_socket_impl return ssl_context.wrap_socket(sock) File "/usr/local/lib/python3.8/ssl.py", line 500, in wrap_socket return self.sslsocket_class._create( File "/usr/local/lib/python3.8/ssl.py", line 997, in _create raise ValueError("check_hostname requires server_hostname") ValueError: check_hostname requires server_hostname ``` **To Reproduce** Steps to reproduce the behavior: 1. Upgrade Docker version to 0.5.2 from 0.5.1 2. Search 3. Get error in browser 4. Check Docker log **Deployment Method** - [ ] Heroku (one-click deploy) - [x] Docker - [ ] `run` executable - [ ] pip/pipx - [ ] Other: [describe setup] **Version of Whoogle Search** - [ ] Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc) - [x] Version 0.5.2 - [ ] Not sure **Desktop (please complete the following information):** - OS: [e.g. iOS] Windows 10 - Browser [e.g. chrome, safari] Firefox - Version [e.g. 22] Latest **Additional context** Confirmed an issue specifically with 0.5.2; downgrading to 0.5.1 using the :0.5.1 tag results in the expected search behavior and no errors.
kerem 2026-02-25 20:35:13 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@benbusby commented on GitHub (Jun 3, 2021):

Looks like this might be related to the recent upgrade of the urllib dependency. Pulling 0.5.2 from scratch works fine for me, and the CI build passed for that tag, so maybe the Python dependencies were erroneously cached for your upgrade. Can you try repulling with --no-cache to see if that fixes it for you?

<!-- gh-comment-id:854015059 --> @benbusby commented on GitHub (Jun 3, 2021): Looks like this might be related to the recent upgrade of the `urllib` dependency. Pulling `0.5.2` from scratch works fine for me, and the CI build passed for that tag, so maybe the Python dependencies were erroneously cached for your upgrade. Can you try repulling with `--no-cache` to see if that fixes it for you?
Author
Owner

@timespacedecay commented on GitHub (Jun 4, 2021):

Unfortunately I don't know how to do that - I'm just a pleb on Unraid.

I removed the whoogle-docker and deleted the image. Added it back and it re-downloaded the image. Same issue, with an additional line at the end of the log now:
WARNING:app:404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.

<!-- gh-comment-id:854290811 --> @timespacedecay commented on GitHub (Jun 4, 2021): Unfortunately I don't know how to do that - I'm just a pleb on Unraid. I removed the whoogle-docker and deleted the image. Added it back and it re-downloaded the image. Same issue, with an additional line at the end of the log now: `WARNING:app:404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.`
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

Ah okay, this is actually my mistake. The 0.5.2 release does not actually include the update to urllib after all. Apologies!

I'll get a new release out today with the update and let you know once it's available.

<!-- gh-comment-id:854799398 --> @benbusby commented on GitHub (Jun 4, 2021): Ah okay, this is actually my mistake. The 0.5.2 release does not actually include the update to urllib after all. Apologies! I'll get a new release out today with the update and let you know once it's available.
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

This should now be fixed with tag 0.5.3. Please reopen if you're still having issues!

<!-- gh-comment-id:854841795 --> @benbusby commented on GitHub (Jun 4, 2021): This should now be fixed with tag `0.5.3`. Please reopen if you're still having issues!
Author
Owner

@timespacedecay commented on GitHub (Jun 4, 2021):

Still happening. I tried :latest, no dice, so I forced :0.5.3, still get the same errors in the logs and Internal Server error after pressing search.

I am using the WHOOGLE_PROXY options if that matters, to route traffic through the VPN of another container. Worked fine on 0.5.1.

<!-- gh-comment-id:854905054 --> @timespacedecay commented on GitHub (Jun 4, 2021): Still happening. I tried :latest, no dice, so I forced :0.5.3, still get the same errors in the logs and Internal Server error after pressing search. I am using the WHOOGLE_PROXY options if that matters, to route traffic through the VPN of another container. Worked fine on 0.5.1.
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

Ah. The WHOOGLE_PROXY info is very helpful. It looks like this is a known issue with the latest changes to the library I mentioned earlier (https://stackoverflow.com/a/67000726).

I'll push another update soon.

<!-- gh-comment-id:854910182 --> @benbusby commented on GitHub (Jun 4, 2021): Ah. The `WHOOGLE_PROXY` info is very helpful. It looks like this is a known issue with the latest changes to the library I mentioned earlier (https://stackoverflow.com/a/67000726). I'll push another update soon.
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

Actually are you able to give me some more info on the proxy info you're passing? No private details, but protocol would be helpful at least. From this comment it looks like it could be a user proxy configuration issue, where the user changed the proxy type from https to http and it began working since their proxy was only configured to accept regular HTTP traffic on port 443.

<!-- gh-comment-id:854913018 --> @benbusby commented on GitHub (Jun 4, 2021): Actually are you able to give me some more info on the proxy info you're passing? No private details, but protocol would be helpful at least. From [this comment](https://github.com/urllib3/urllib3/issues/2075#issuecomment-730765490) it looks like it could be a user proxy configuration issue, where the user changed the proxy type from `https` to `http` and it began working since their proxy was only configured to accept regular HTTP traffic on port 443.
Author
Owner

@timespacedecay commented on GitHub (Jun 4, 2021):

Actually are you able to give me some more info on the proxy info you're passing? No private details, but protocol would be helpful at least. From this comment it looks like it could be a user proxy configuration issue, where the user changed the proxy type from https to http and it began working since their proxy was only configured to accept regular HTTP traffic on port 443.

WHOOGLE_PROXY_TYPE: http
WHOOGLE_PROXY_LOC: 192.168.1.12:8118

Should I try https?

Note - I haven't changed anything with the VPN or these proxy settings. I just rolled back to 0.5.1 and it works as expected.

<!-- gh-comment-id:854919721 --> @timespacedecay commented on GitHub (Jun 4, 2021): > > > Actually are you able to give me some more info on the proxy info you're passing? No private details, but protocol would be helpful at least. From [this comment](https://github.com/urllib3/urllib3/issues/2075#issuecomment-730765490) it looks like it could be a user proxy configuration issue, where the user changed the proxy type from `https` to `http` and it began working since their proxy was only configured to accept regular HTTP traffic on port 443. `WHOOGLE_PROXY_TYPE:` `http` `WHOOGLE_PROXY_LOC:` `192.168.1.12:8118` Should I try https? Note - I haven't changed anything with the VPN or these proxy settings. I just rolled back to 0.5.1 and it works as expected.
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

Note - I haven't changed anything with the VPN or these proxy settings. I just rolled back to 0.5.1 and it works as expected.

Yes, the issue here is that an update to one of the project's dependencies (which was rolled out after 0.5.1) seems to have made proxy connection details more strict. On 0.5.1, the dependency is set to a prior version where this wasn't an issue. I'd offer to roll back the library to the version that worked for you (the one being used on 0.5.1), but the library was updated because of a security vulnerability.

<!-- gh-comment-id:854926437 --> @benbusby commented on GitHub (Jun 4, 2021): > Note - I haven't changed anything with the VPN or these proxy settings. I just rolled back to 0.5.1 and it works as expected. Yes, the issue here is that an update to one of the project's dependencies (which was rolled out after 0.5.1) seems to have made proxy connection details more strict. On 0.5.1, the dependency is set to a prior version where this wasn't an issue. I'd offer to roll back the library to the version that worked for you (the one being used on 0.5.1), but the library was updated because of a security vulnerability.
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

Actually, after looking into it a bit more, it might be something that Whoogle itself can fix after all. I'm going to look into it a bit more and get back to you.

<!-- gh-comment-id:854932240 --> @benbusby commented on GitHub (Jun 4, 2021): Actually, after looking into it a bit more, it might be something that Whoogle itself can fix after all. I'm going to look into it a bit more and get back to you.
Author
Owner

@benbusby commented on GitHub (Jun 4, 2021):

Can you try again with the latest tag? I pushed a fix that I confirmed works with a basic Privoxy setup, but want to make sure it's working on your end as well.

<!-- gh-comment-id:854964163 --> @benbusby commented on GitHub (Jun 4, 2021): Can you try again with the `latest` tag? I pushed a fix that I confirmed works with a basic Privoxy setup, but want to make sure it's working on your end as well.
Author
Owner

@timespacedecay commented on GitHub (Jun 4, 2021):

It works! Thanks for your efforts and I appreciate the quick help!

<!-- gh-comment-id:855077003 --> @timespacedecay commented on GitHub (Jun 4, 2021): It works! Thanks for your efforts and I appreciate the quick help!
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#230
No description provided.