#1765 mod_http files.lua:72: attempt to concatenate upvalue 'base_path' (a nil value)
Reporter
PICCORO Lenz McKAY
Owner
Zash
Created
Updated
Stars
★ (1)
Tags
Priority-Medium
Status-Fixed
Type-Defect
Milestone-0.12
PICCORO Lenz McKAY
on
What steps will reproduce the problem?
1. configure the http and BOSH to serve files
2. setup ws bosh and http
3. point the conversejs (no usage of the module) to the xmpp server
What is the expected output?
No traceback
What do you see instead?
```
/usr/lib/prosody/util/async.lua:144: in function </usr/lib/prosody/util/async.lua:142>
Jul 15 08:36:09 http.server error Traceback[httpserver]: /usr/lib/prosody/net/http/files.lua:72: attempt to concatenate upvalue 'base_path' (a nil value)
stack traceback:
/usr/lib/prosody/net/http/files.lua:72: in function </usr/lib/prosody/net/http/files.lua:64>
(...tail calls...)
/usr/lib/prosody/util/events.lua:81: in function </usr/lib/prosody/util/events.lua:77>
(...tail calls...)
/usr/lib/prosody/net/http/server.lua:310: in function 'handle_request'
/usr/lib/prosody/net/http/server.lua:127: in function 'func'
/usr/lib/prosody/util/async.lua:144: in function </usr/lib/prosody/util/async.lua:142>
```
What version of the product are you using? On what operating system?
0.12.1 on Debian
PICCORO Lenz McKAY
on
Hi, i guess this is hight priority cos i cannot configure MUC of uploads files.. neither property trace back the problem.. cos there's so much modules involved and i not a XMPP developer
Zash
on
This happens because you enabled mod_http_files without configuring `http_files_dir`. We should improve error handling in this case.
However, if your intent was to enable file uploads, then you are using the wrong module.
See https://prosody.im/doc/modules/mod_http_file_share or https://modules.prosody.im/xeps.html#xep0363
mod_http_files is not used directly for uploads, it simply lets you serve static files, like a website.
PICCORO Lenz McKAY
on
umm i do not have expertise.. but let me guess, i must define http_files_dir path in the host configuration right? seems documentation is so vage.. http_files_dir its global module but does not said if there a global variable or per host config,,
i defined the http_files_dir variable in global config to "/var/lib/prosody/http_files" but that will conflict with already configured other modules like http_uploads ? of course i setupo the directory to the user that runs the prosody process ("prosodyuser") with chown.. but documentation is soso vage also..
i cant restart the process but i reload manually by prosodyctl and i cannot check if happened or no.. there's another way to check this are correct or will conflict with other configurations?
Zash
on
mod_http_files is not a global module. all settings should work as with most other modules, with per-host settings taking priority over global settings, see https://prosody.im/doc/configure#overview
of course the files in the directory pointed to by http_files_dir would need to be readable by prosody for them to be served, otherwise a 403 or such error is returned.
keep in mind that these would show up at a path determined by http_paths, with a final URL like https://xmpp.example.com:5281/files/
Some improvements to https://prosody.im/doc/modules/mod_http_files have been applied.
Patches or suggestions for further improvements are welcome.
Will add a check to ensure that mod_http_files is correctly configured, but this needs updates in several community modules that still use mod_http_files instead of net.http.files to serve their own files.
Please try to keep to one issue per issue, and refrain from using this as a support forum. https://prosody.im/discuss lists better places for generic support
Changes
tags Milestone-0.12 Status-Started
owner Zash
PICCORO Lenz McKAY
on
ok, thanks fort clarifications, too much to check and change in my deploy then.. but as i can see it, it seems that docuemntation ned lot of work.. cos module behaviour are not specify..
i think i will let open this issue until most of the modules get in sync with 0.12 branch and this clarification over documentation, i already know that not all modules are mantained by core team but some are so important like the conversjs.. (i liked the issue cos it seems its a problem of the http module, conversejs uses that module to server files and it seems does not work)
Zash
on
mod_conversejs should not be having this problem, it should handle both 0.11 and 0.12 per https://hg.prosody.im/prosody-modules/rev/3a06dea21ea1#l2.13
It is not clear to me what the problem is, beyond the ability to enable mod_http_files directly without configuring it. If this is not the issue, please explain how to reproduce, including Prosody configuration.
Changes
tags Status-NeedInfo
PICCORO Lenz McKAY
on
hi i check and deactivate the module.. ad still happened the problem.. i will try to find where's the problem.. of course some kind of dependency
Zash
on
A warning has been added in https://hg.prosody.im/trunk/rev/ba05f7e5f2a2 to highlight any modules still using the old way to serve files. The method will stop working at some point in the future.
I will consider this to what this issue is about. Since it sounds like you have other issues, please either describe them in sufficient detail in a new issue or ask for help debugging in one of our support channels.
What steps will reproduce the problem? 1. configure the http and BOSH to serve files 2. setup ws bosh and http 3. point the conversejs (no usage of the module) to the xmpp server What is the expected output? No traceback What do you see instead? ``` /usr/lib/prosody/util/async.lua:144: in function </usr/lib/prosody/util/async.lua:142> Jul 15 08:36:09 http.server error Traceback[httpserver]: /usr/lib/prosody/net/http/files.lua:72: attempt to concatenate upvalue 'base_path' (a nil value) stack traceback: /usr/lib/prosody/net/http/files.lua:72: in function </usr/lib/prosody/net/http/files.lua:64> (...tail calls...) /usr/lib/prosody/util/events.lua:81: in function </usr/lib/prosody/util/events.lua:77> (...tail calls...) /usr/lib/prosody/net/http/server.lua:310: in function 'handle_request' /usr/lib/prosody/net/http/server.lua:127: in function 'func' /usr/lib/prosody/util/async.lua:144: in function </usr/lib/prosody/util/async.lua:142> ``` What version of the product are you using? On what operating system? 0.12.1 on Debian
Hi, i guess this is hight priority cos i cannot configure MUC of uploads files.. neither property trace back the problem.. cos there's so much modules involved and i not a XMPP developer
This happens because you enabled mod_http_files without configuring `http_files_dir`. We should improve error handling in this case. However, if your intent was to enable file uploads, then you are using the wrong module. See https://prosody.im/doc/modules/mod_http_file_share or https://modules.prosody.im/xeps.html#xep0363 mod_http_files is not used directly for uploads, it simply lets you serve static files, like a website.
umm i do not have expertise.. but let me guess, i must define http_files_dir path in the host configuration right? seems documentation is so vage.. http_files_dir its global module but does not said if there a global variable or per host config,, i defined the http_files_dir variable in global config to "/var/lib/prosody/http_files" but that will conflict with already configured other modules like http_uploads ? of course i setupo the directory to the user that runs the prosody process ("prosodyuser") with chown.. but documentation is soso vage also.. i cant restart the process but i reload manually by prosodyctl and i cannot check if happened or no.. there's another way to check this are correct or will conflict with other configurations?
mod_http_files is not a global module. all settings should work as with most other modules, with per-host settings taking priority over global settings, see https://prosody.im/doc/configure#overview of course the files in the directory pointed to by http_files_dir would need to be readable by prosody for them to be served, otherwise a 403 or such error is returned. keep in mind that these would show up at a path determined by http_paths, with a final URL like https://xmpp.example.com:5281/files/ Some improvements to https://prosody.im/doc/modules/mod_http_files have been applied. Patches or suggestions for further improvements are welcome. Will add a check to ensure that mod_http_files is correctly configured, but this needs updates in several community modules that still use mod_http_files instead of net.http.files to serve their own files. Please try to keep to one issue per issue, and refrain from using this as a support forum. https://prosody.im/discuss lists better places for generic support
Changesok, thanks fort clarifications, too much to check and change in my deploy then.. but as i can see it, it seems that docuemntation ned lot of work.. cos module behaviour are not specify.. i think i will let open this issue until most of the modules get in sync with 0.12 branch and this clarification over documentation, i already know that not all modules are mantained by core team but some are so important like the conversjs.. (i liked the issue cos it seems its a problem of the http module, conversejs uses that module to server files and it seems does not work)
mod_conversejs should not be having this problem, it should handle both 0.11 and 0.12 per https://hg.prosody.im/prosody-modules/rev/3a06dea21ea1#l2.13 It is not clear to me what the problem is, beyond the ability to enable mod_http_files directly without configuring it. If this is not the issue, please explain how to reproduce, including Prosody configuration.
Changeshi i check and deactivate the module.. ad still happened the problem.. i will try to find where's the problem.. of course some kind of dependency
A warning has been added in https://hg.prosody.im/trunk/rev/ba05f7e5f2a2 to highlight any modules still using the old way to serve files. The method will stop working at some point in the future. I will consider this to what this issue is about. Since it sounds like you have other issues, please either describe them in sufficient detail in a new issue or ask for help debugging in one of our support channels.
Changeshttps://hg.prosody.im/trunk/rev/360e05f33835 should detect the misconfiguration causing the traceback in the start of this issue earlier.
Changes