Open johanneshiry opened 3 years ago
@johanekhager Can you please point out in which recent version this was functional?
I will try to resolve it. :smiley:
Thanks for the fast reply - I think it must have been 3.11.2
I'm experiencing several bugs related to subdir. (Rocket.Chat version 3.12.3) I have following nginx configuration to workaround.
location /avatar/ {
rewrite ^(.*)$ /chat$1 permanent;
}
location /file-upload/ {
rewrite ^(.*)$ /chat$1 permanent;
}
location /chat/chat/file-upload/ {
rewrite ^/chat(.*)$ $1 permanent;
}
I have the same problem but under Apache proxy. I am using docker-compose install v 3.14
This has never been an issue for me last couple years. I upgraded recently, so this is a totally new issue.
thanks
Just tested on 3.15.0 and it still has the same problem with uploads, as well as a host of other issues with navigating the admin area. I can't use this until this issue is fixed.
/api/ecdh_proxy/initEncryptedSession is giving a 404 with sub directories as well.
Description:
A valid upload file cannot be downloaded, because the download link provided differs from the actual upload link when Rocket.Chat runs in a subdir. Seems like RC is adding the already proxied subdir a second time for downloads.
Worked in pre 3.12 versions - started occuring with v3.12.0.
May be related to #20640, but can't figure out if the issue is the same or if there is just an invalid apache/nginx configuration in #20640.
Steps to reproduce:
Expected behavior:
The file is downloaded successfully
Actual behavior:
A dummy file is created with a few kB instead.
Server Setup Information:
Client Setup Information
Additional context
Comparing upload and download links reveals the issue. A manual change of the download link (removing the invalid second /chat/ fixed it.
Upload Link:
https://<ROOT-URL>/chat/file-upload/8KAZmCZcswoEWQcZt/<FILENAME>.png
Download Link:
https://<ROOT-URL>/chat/chat/file-upload/8KAZmCZcswoEWQcZt/<FILENAME>.png?download
Relevant nginx conf:
Relevant logs:
None
Quick fix / Workaround:
I managed to get this fixed by an additional nginx.conf entry after
location /file-upload/ {...}
. However, this does not seem to be the preferred way to handle this?!