There is a serious issue with openlitespeed using as a extprocess with proxy protocol over unix domain socket.
The extprocessor proxy mode send the the packets as http protocol instead of uwsgi , which may result in 500 error on a shared application environment with nginx , apache or another webserver running on the same server . All other servers like nginx or apache works fine with uwsgi sockets.
To recreate this issue :
1) Setup a Django application and run it as uwsgi socket the uwsgi setting must be
The django application can access via /path-to-unix-socket.socket on apache httpd and nginx servers . But you can't access it over OLS
2) Setup OLS extprocessor
3) Setup virtual host Context
c
This will result in the following error logs in uwsgi log files
This means that the OLS proxy is sending the protocol as HTTP to a uswgi socket instead of uwsgi protocol . So there is no native support for uwsgi websocket proxy in OLS . You always need to force the "socket" to "http-socket" in the uwsgi server configurations . That is unacceptable in a shared app environment .
The same socket works fine in the following NGINX and HTTPD configurations .
Nginx Configuration :
Apache HTTPD Configuration :
Of course , OLS have a separate lswsgi binary and it can run any django application. But this is only a test as python Django . The app may nor be django . Even if you run a Django in OLS you can't share the same app with all users due to the suexec restriction ., because you can't switch suexec used in a context of OLS.
As an example you can't share a mailman 3 web app with all your domains inside your OLS server via /mailman3 context .
There are workarounds an it is not a fix
Work Around 1 : user http-socket instead of socket , so that it will break your generic servers like nginx and httpd who follow true usgi protocol . It is not professional
Work Around 2 : Only use OLS , don't use any other webserver in your server , that is like tell only install windows and no other OS. it is the end user freedom to use what software inside his server as he wish . My application have the ability to chose webserver as ols, olsvarnis, nginx,olsvarnish, http, nginxhttp, nginxhttpdvarnis, nginxvarnish , so it is the end user freedom to chose
Work around 3 : Don't use native uwsgi socket application in ols
I chose option 3 and currently stopped further integration into OLS on the project I am working on.
So finally I am leaving this topic to open, if the developers like it, they can accept it , if not simply reject it.
PS: I haven't tested it in LiteSpeed Enterprise , I will do it when I can afford a commercial license for LS . I am not sure they provide developer licenses. if I had some free time I could patch the source code of OLS to add this feature , but no time right now.
Thanks
The extprocessor proxy mode send the the packets as http protocol instead of uwsgi , which may result in 500 error on a shared application environment with nginx , apache or another webserver running on the same server . All other servers like nginx or apache works fine with uwsgi sockets.
To recreate this issue :
1) Setup a Django application and run it as uwsgi socket the uwsgi setting must be
socket = /path-to-unix-socket.socketThe django application can access via /path-to-unix-socket.socket on apache httpd and nginx servers . But you can't access it over OLS
2) Setup OLS extprocessor
extprocessor Djangoapp {
type proxy
address unix:/path-to-unix-socket.socket
maxConns 100
initTimeout 5
retryTimeout 5
respBuffer 1
extUser appuser
extGroup www-data
}
3) Setup virtual host Context
c
ontext /myapp/ {
type proxy
handler Djangoapp
addDefaultCharset off
}This will result in the following error logs in uwsgi log files
invalid request block size: 21573 (max 4096)...skip
invalid request block size: 21573 (max 4096)...skip
invalid request block size: 21573 (max 4096)...skip
invalid request block size: 21573 (max 4096)...skip
invalid request block size: 21573 (max 4096)...skip
invalid request block size: 21573 (max 4096)...skip
This means that the OLS proxy is sending the protocol as HTTP to a uswgi socket instead of uwsgi protocol . So there is no native support for uwsgi websocket proxy in OLS . You always need to force the "socket" to "http-socket" in the uwsgi server configurations . That is unacceptable in a shared app environment .
The same socket works fine in the following NGINX and HTTPD configurations .
Nginx Configuration :
location ~/myapp(?:/(.*))?$ {
include /etc/nginx/uwsgi_params;
uwsgi_pass unix:/path-to-unix-sock;
uwsgi_param Host $host;
uwsgi_param X-Real-IP $remote_addr;
uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
}Apache HTTPD Configuration :
<Location /myapp/>
ProxyPass "unix:/path-to-unix.sock|uwsgi://localhost/myapp/"
</Location>
Of course , OLS have a separate lswsgi binary and it can run any django application. But this is only a test as python Django . The app may nor be django . Even if you run a Django in OLS you can't share the same app with all users due to the suexec restriction ., because you can't switch suexec used in a context of OLS.
As an example you can't share a mailman 3 web app with all your domains inside your OLS server via /mailman3 context .
There are workarounds an it is not a fix
Work Around 1 : user http-socket instead of socket , so that it will break your generic servers like nginx and httpd who follow true usgi protocol . It is not professional
Work Around 2 : Only use OLS , don't use any other webserver in your server , that is like tell only install windows and no other OS. it is the end user freedom to use what software inside his server as he wish . My application have the ability to chose webserver as ols, olsvarnis, nginx,olsvarnish, http, nginxhttp, nginxhttpdvarnis, nginxvarnish , so it is the end user freedom to chose
Work around 3 : Don't use native uwsgi socket application in ols
I chose option 3 and currently stopped further integration into OLS on the project I am working on.
So finally I am leaving this topic to open, if the developers like it, they can accept it , if not simply reject it.
PS: I haven't tested it in LiteSpeed Enterprise , I will do it when I can afford a commercial license for LS . I am not sure they provide developer licenses. if I had some free time I could patch the source code of OLS to add this feature , but no time right now.
Thanks
