You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases, if the HTTP Upgrade and Connection headers are present, they are forwarded to the proxy only when the request is for /socket.io. In other cases, there's no distinction and they are always forwarded if present.
What is the best practice here?
Forward them only for requests against /socket.io ?
Is there a security risk if those headers are present and we forward them even for requests that are not for /socket.io?
In the wiki you can find both ways.
For Apache, the wiki page states we should have two locations '/' and '/socket.io/' and only enable the HTTP proxy header forwarding in the latter:
<Location />
AuthType Basic
AuthName "Welcome to the domain.org Etherpad"
AuthUserFile /path/to/svn.passwd
AuthGroupFile /path/to/svn.group
Require group etherpad
ProxyPass http://localhost:9001/ retry=0 timeout=30
ProxyPassReverse http://localhost:9001/
</Location>
**<Location /socket.io>**
# This is needed to handle the websocket transport through the proxy, since
# etherpad does not use a specific sub-folder, such as /ws/ to handle this kind of traffic.
# Taken from https://github.com/ether/etherpad-lite/issues/2318#issuecomment-63548542
# Thanks to beaugunderson for the semantics
#-----Apache <2.4.47-----
#RewriteEngine On
#RewriteCond %{QUERY_STRING} transport=websocket [NC]
#RewriteRule /(.*) ws://localhost:9001/socket.io/$1 [P,L]
#ProxyPass http://localhost:9001/socket.io retry=0 timeout=30
#ProxyPassReverse http://localhost:9001/socket.io
#-----Apache >=2.4.47-----
ProxyPass ws://localhost:9001/socket.io **upgrade=websocket** timeout=30
ProxyPassReverse ws://localhost:9001/socket.io
</Location>
For nginx, when the pad is parked at '/', there is only one location, '/' and the proxy headers are set there if the client sent the HTTP upgrade headers:
location / {
proxy_pass http://127.0.0.1:9001;
proxy_buffering off; # be careful, this line doesn't override any proxy_buffering on set in a conf.d/file.conf
proxy_set_header Host $host;
proxy_pass_header Server;
# Note you might want to pass these headers etc too.
proxy_set_header X-Real-IP $remote_addr; # https://nginx.org/en/docs/http/ngx_http_proxy_module.html
proxy_set_header X-Forwarded-For $remote_addr; # EP logs to show the actual remote IP
proxy_set_header X-Forwarded-Proto $scheme; # for EP to set secure cookie flag when https is used
proxy_http_version 1.1; # recommended with keepalive connections
**# WebSocket proxying - from https://nginx.org/en/docs/http/websocket.html
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;**
}
For nginx, when the pad is parked at a subdirectory', there are many distinct sections and only the one for sockets.io is forwarding the HTTP upgrade headers if present.
location /pad {
rewrite /pad/(.*) /$1 break;
rewrite ^/pad$ /pad/ permanent;
proxy_redirect / /pad/;
proxy_pass http://127.0.0.1:9001;
proxy_buffering off; # be careful, this line doesn't override any proxy_buffering on set in a conf.d/file.conf
proxy_set_header Host $host;
proxy_pass_header Server;
# Note you might want to pass more headers etc too. See above configs.
}
location /pad/socket.io {
rewrite /pad/socket.io/(.*) /socket.io/$1 break;
proxy_redirect / /pad/;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:9001;
proxy_buffering off; # be careful, this line doesn't override any proxy_buffering on set in a conf.d/file.conf
proxy_set_header Host $host;
proxy_pass_header Server;
proxy_http_version 1.1;
**proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";**
}
Whatever is the resolution, the nginx info should be reviewed to make it consistent. I also feel that many of those location sections when the pad is hosted in a subdir could be factorized into two location sections, retaining only one section for '/foo(/*)?' and another one for /foo/socket.io . I've been testing this with positive results (here below partial config for pad hosted on subdir /test):
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The How to put Etherpad Lite behind a reverse Proxy wiki page is not consistent with itself with respect to the webscockets connection upgrade headers.
In some cases, if the HTTP Upgrade and Connection headers are present, they are forwarded to the proxy only when the request is for /socket.io. In other cases, there's no distinction and they are always forwarded if present.
What is the best practice here?
In the wiki you can find both ways.
For Apache, the wiki page states we should have two locations '/' and '/socket.io/' and only enable the HTTP proxy header forwarding in the latter:
For nginx, when the pad is parked at '/', there is only one location, '/' and the proxy headers are set there if the client sent the HTTP upgrade headers:
For nginx, when the pad is parked at a subdirectory', there are many distinct sections and only the one for sockets.io is forwarding the HTTP upgrade headers if present.
For caddy, hosted in a subdirectory url,, those headers are only forwarded for location.io
Whatever is the resolution, the nginx info should be reviewed to make it consistent. I also feel that many of those location sections when the pad is hosted in a subdir could be factorized into two location sections, retaining only one section for '/foo(/*)?' and another one for /foo/socket.io . I've been testing this with positive results (here below partial config for pad hosted on subdir /test):
WDYT?
Thanks in advance for your feedback.
Beta Was this translation helpful? Give feedback.
All reactions