redimp
502 Bad Gateway, invalid request block size, Docker deployment
Hello,
New user there, I wanted to notify you about the error talked about in #97
After installing the lastest version (2.8.0) of OtterWiki in Docker form, on a remote machine and accessing it through http://192.168.1.15:8080 everything work fine with Firefox, but the moment I try to create a new page, the 502 error trigger and I cannot access OtterWiki anymore with the browser unless I start using private browsing mode.
The fix of setting buffer-size=8196 in /app/uwsgi.ini seem to work and fix the issue.
otterwiki-1 | 2025-01-18 23:43:21,122 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
otterwiki-1 | 2025-01-18 23:43:21,122 INFO success: uwsgi entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
otterwiki-1 | invalid request block size: 5233 (max 4096)...skip
otterwiki-1 | 192.168.1.111 - - [18/Jan/2025:23:43:24 +0000] "GET / HTTP/1.1" 502 157 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0"
otterwiki-1 | 2025/01/18 23:43:24 [error] 19#19: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.111, server: , request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "192.168.1.15:8006"
I tried to recover a .har file from Firefox by redoing the same steps, but OtterWiki don't seem to want to work again without setting the fix, even on a fresh restart, the request block size seem pretty random in the end, or maybe it is something in the cache...
Reproducing the sames steps in private browsing mode does not seem to trigger the 502 and new pages are created normally.
I am a bit confused.
Hey @Yarg-mirror, that confuses me too. At first I have no idea what is causing it.
Let's dig into this. I'm wondering about what may cause the problems with request block size. The very same was reported in #179.
A few questions:
- What reverse proxy are you using?
- Do you edit as anonymous user or are you logged in?
Hello,
-
At this point the installation was really fresh, so no other reverse proxy than the nginx inside 1.2 I will add HAProxy in front of it today and see if that change something with the default buffer
-
The edit (page creation even) was done as an anonymous user, it was the first action done once connected, not even the first user/admin was created
Setting the reverse proxy seem to fix the issue, the navigation came back, and page creation/edition work as intended. Even if the 502 still trigger when trying a direct access.
As a bonus test, no issues with chrome in direct access, it really seem to be browser dependant
Maybe it's something with the internal nginx then?
Just spined fresh installation and after few edits to check how everything works
ARM build if that matter - Docker
as anonymous user and on chrome
I'm getting the same error but only when using http://localhost:8080 is solved when I use http://127.0.0.1:8080 ???
Hey @horaciod, please share some more information.
- (1) Is this a fresh install?
- (2) How did you deploy An Otter Wiki?
- (3) Are you using a reverse proxy to access the wiki?
- (4) Which Version are you running?
Hey @horaciod, please share some more information.
* (1) Is this a fresh install? * (2) How did you deploy An Otter Wiki? * (3) Are you using a reverse proxy to access the wiki? * (4) Which Version are you running?
(1). Fresh install via docker-compose
version: "3.8" services: otterwiki: image: redimp/otterwiki:2 restart: unless-stopped ports: - 8080:80 volumes: - /datos/webs/wiki/app-data:/app-data networks: {}
(2). in local (ubuntu linux 22.04)
(3) Are you using a reverse proxy to access the wiki? Not yet.
(4) Which Version are you running? redimp/otterwiki:2
Hey @horaciod, thanks for sharing the details.
Can share the logs of the pod starting up? e.g. via docker compose logs --no-log-prefix
I have same error. Fresh install via docker compose:
otterwiki:
image: redimp/otterwiki:2
container_name: otterwiki
restart: unless-stopped
ports:
- 8484:80
volumes:
- /mnt/usb_1/Docker/Otterwiki:/app-data
502 Bad Gateway
nginx/1.22.1
Logs:
*** Starting uWSGI 2.0.21-debian (64bit) on [Mon Apr 7 14:14:43 2025] ***
compiled with version: 12.2.0 on 19 May 2023 13:59:29
os: Linux-6.8.12-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-8 (2025-01-24T12:32Z)
nodename: bb88bd1a76d1
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 16
current working directory: /
writing pidfile to /tmp/uwsgi.pid
detected binary path: /usr/bin/uwsgi-core
chdir() to /app
your processes number limit is 125781
your memory page size is 4096 bytes
detected max file descriptor number: 524288
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
setgid() to 33
setuid() to 33
Python version: 3.11.2 (main, Nov 30 2024, 21:22:50) [GCC 12.2.0]
PEP 405 virtualenv detected: /opt/venv
Set PythonHome to /opt/venv
Python main interpreter initialized at 0x7c16132f1018
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 5 seconds
mapped 145840 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
2025-04-07 14:14:44,927 INFO success: quit_on_failure entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2025-04-07 14:14:44,927 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2025-04-07 14:14:44,927 INFO success: uwsgi entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
*** Starting An Otter Wiki 2.10.4 v2.10.4-0-g8e26332
[2025-04-07 14:14:45,266] INFO in server: server: Created initial /Home.
WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x7c16132f1018 pid: 21 (default app)
spawned uWSGI master process (pid: 21)
spawned uWSGI worker 1 (pid: 34, cores: 1)
running "unix_signal:15 gracefully_kill_them_all" (master-start)...
invalid request block size: 6829 (max 4096)...skip
2025/04/07 14:14:57 [error] 22#22: *2 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.28.1, server: , request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "192.168.28.53:8484"
192.168.28.1 - andrej [07/Apr/2025:14:14:57 +0000] "GET / HTTP/1.1" 502 559 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36"
Hey @thehijacker, thanks for reporting and adding the log output.
invalid request block size: 6829 (max 4096)...skip
Please update the docker-compose.yaml and add:
environment:
UWSGI_BUFFER_SIZE: "8192"
I have come to the conclusion after spending almost two weeks and reading countless posts about this
STUPID 502 error crap from the docker version of otter wiki that... SHOCK SHOCK otterwiki SUCKS!!!
When you look the install guide it is nothing but a bunch of Half way done explanations chained in a single page...
and 3 of them are different ways to use docker to install it.
The revers proxy doesn't work with caddy, Nginx, Apache... I can't even get the docker image to ignore needed a reverse proxy because the docker image will not take the command the uwsgi install can take even though the docker image should be using uwsgi.
Not only that the documentation cant decide if it is localhost, 127.0.0.1, or 0.0.0.0
While all of those should just work none of them do and people have had varying luck trying to get this to work
At first I thought oh yeah I have two separate dockers for otterwiki and the reverse proxy. then went I bet that is why it isn't working. It wasn't
The only thing I get is 502 regardless of all the special sauce settings people have figured out for their setup.
Also they way this package wants you to use a reverse proxy PROVIDES ZERO EXTRA SECURITY!!! so what even do it. imagine making your software so it will only talk to its localhost or host system the vm is on... unless you do some special settings... because you think that will make it more secure. Except how does it do that, when you have to run the reverse proxy on the same system... Great move in not actually providing security and adding an extra step in frustration and complication in getting your software working!
To be fair it provides about maybe 1-5% extra security, but when you have to start throwing random stuff at the docker container setup and host... your system ends up being a screen door by the time you got it working. if you can get it working
TLDR: I thought I was being dumb, pulling my hair out. When finally I had a realization after trying a literal 100s to about a 1000 different ways to get this software working. It is the software not me. IT IS BAD! the docker implantation shouldn't even exist in it's current state. Docker images are suppose to be one click/ command line and done. This isn't it wasted two weeks of my life. Normally I wouldn't complain about free opensource software, but two weeks down the drain, is not nothings.
For context I have a CS degree and CIS degree and a several certs for backend server stuff including database design and administration. Which is why I spent so much time trying to get this to work... I have never in my life had such a pain getting something to work. Also I hate docker because every tom dick and harry make a docker image and they work worst than setting it up on a vm in proxmox... It shouldn't be like that... since it was designed directly to fix this kind of issue. This docker image is TRASH! the maker documentation is bad.
I do want to end with this. The part that makes me so mad is I finally did the manual setup NOT FOLLOWING THE DOCUMENTATION BECAUSE IT IS BAD FOR THAT... it took all of 5 minutes to get it up and running and then I bypassed the need for a reverse proxy. Then setup a reverse proxy on another system that can touch the outside world and had DMZ just because that is how you actually secure your traffic with a reverse proxy!
If I wanted to go the extra mile I could put the server behind another firewall set up a port forward for http traffic only for just the port need to the DMZ server that can talk to the outside world with only certain ports open the the outside world, then use cloudflare proxy stuff. and then set it up so the webserver for otter wiki only takes requests from the exact address of the DMZ proxy server. that then passes traffic through cloudflares network.
Well... Since the fix in v2.10.5 everything seem to work flawlessly with direct access and behind a reverse proxy without any additional configuration on my side. Since the others did not raise another issues either I guess it's the same for them?
My current compose is 7 lines:
services:
otterwiki:
image: docker.io/redimp/otterwiki:2.10.6
ports:
- 8006:80
volumes:
- /data/otterwiki:/app-data
Are you using the latest version ? What is your log output from docker ? If it is the same issue you will have the same line as us
Hey @GeekyBit, thank you for sharing your experience. I salute you for not giving up on this for two weeks. Happy to hear that you finally solved the issue and got An Otter Wiki running!
Based on your description, I would say that the problem was the configuration of the reverse proxy running as docker container. This is indeed not documented in the installation guide. Will add a section on that.
Also important: This issue here was an issue with the uwsgi configuration that has been fixed (it has not been reported since v2.10.5).
I am on latest/2.14.1 and am unable to configure the buffer size higher than 8192, which I'm hitting:
otterwiki | invalid request block size: 8255 (max 8192)...skip
otterwiki | 192.168.208.6 - - [07/Oct/2025:16:30:23 +0000] "POST /Home/save HTTP/1.1" 502 157 "https://wiki/Home/edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0"
otterwiki | 2025/10/07 16:30:23 [error] 15#15: *3 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.208.6, server: , request: "POST /Home/save HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "wik", referrer: "https://wiki/Home/edit"
Here's my env configuration:
environment:
APP_NAME: otterwiki
AUTH_METHOD: SIMPLE
WRITE_ACCESS: REGISTERED
UWSGI_BUFFER_SIZE: "16384"
Hey @andygeorge, thanks for reaching out. I will look into this. Looks like I've missed somthing.
Can you check if the -slim variant works for you?
image: redimp/otterwiki:2-slim
The -slim variant has no nginx running but uwsgi directly.
Note for myself: check adding uwsgi_buffer_size to the nginx.conf if UWSGI_BUFFER_SIZE is set.
Great, thanks for letting me know it helped!
It looks like it's not just uwsgi causing this error 🤔