Description: If you try to update an extension in the LibreOffice extension manager, the update is detected and then downloaded but is not installed with the following message: Error while installing extension jdbcDriverOOo. The error message is: Cannot detect media-type: file:///tmp/aEZpfj_/J67d0J_/0188aee2-fbbd-4f36-9701-93e242fda00a at /home/prrvchr/github/libreoffice/desktop/source/deployment/registry/dp_registry.cxx:479 The extension will not be installed. Steps to Reproduce: 1. Install the SQLiteOOo v 1.1.2 extension which is provided as an attachment (it is not necessary to install Java and jdbcDriverOOo for this test) 2. Go to: Tools -> Extensions manager... -> Check for Updates -> Install 3. After downloading the extension you see error message: Cannot detect media-type - The extension will not be installed. Actual Results: The extension will not be installed. Expected Results: The extension will be installed. Reproducible: Always User Profile Reset: No Additional Info: You can try by installing the extension provided in the attachment and try to update it. This should reproduce the error message.
Created attachment 192633 [details] SQLiteOOo extension
Same error on Win11 Version: 24.2.1.1 (X86_64) / LibreOffice Community Build ID: 359ef544e625d2ffbfced462ab37bd593ca85fa7 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Error while installing extension SQLiteOOo. The error message is: Cannot detect media-type: file:///C:/Users/xxxxx/AppData/Local/Temp/FD32.tmp_/FD42.tmp_/6ed0cacb-0869-4d69-85ad-e5770aa867f1 at C:/cygwin64/home/buildslave/source/libo-core/desktop/source/deployment/registry/dp_registry.cxx:477 The extension will not be installed. But I'm not sure if it is a LO bug or an extension bug.
the problem seems to come from the line: https://github.com/LibreOffice/core/blob/ca935d5a016f5527422058f23c1bf3cb2917fb0f/desktop/source/deployment/registry/dp_registry.cxx#L479 I don't really understand how the media type of the file is retrieved but apparently it is copied into a temporary directory under a name without extension (ie: 0188aee2-fbbd-4f36-9701-93e242fda00a as can be seen in my error message)
Maybe the error is in the extension. Report to the authors.
@m_a_riosv yes, I am the author... that's why I opened an issue...
Well if I look at the code that I referenced above, it appears that the media type is retrieved by the extension of the file downloaded in the temp directory. But if we look at the path of the temporary file in the error message then we see that there is no extension on the file name... Can someone please confirm, in C I'm not very good...
Would it be possible that when downloading the extension update by LibreOffice the name of the extension file is preserved? I suspect that the fact that LibreOffice renames the extension file with a random name and without .oxt extension is the problem. In addition, this poses the problem that the extension is installed in a directory which has the same name as the downloaded file which currently is a random name.
I think the easy way that works for me is to download the latest version from the extensions site, and install it. I first uninstall the previous. Thank you, @prrvhr, for taking care of it.
Here are the error messages I get when I use the daily build: > warn:ucb.ucp.webdav:13526:13552:ucb/source/ucp/webdav-curl/webdavcontent.cxx:4192: OPTIONS - Got an SC_NOT_FOUND, but the URL <https://github.com/prrvchr/eMailerOOo/releases/latest/download/eMailerOOo.update.xml> resource exists > warn:ucb.ucp.webdav:13526:13552:ucb/source/ucp/webdav-curl/webdavcontent.cxx:4177: OPTIONS - SC_NOT_IMPLEMENTED or SC_METHOD_NOT_ALLOWED for URL <https://updateexte.libreoffice.org/ExtensionUpdateService/check.Update>, HTTP error: 405, 'OPTIONS => HTTP/1.1 405 Not Allowed' I don't know what webdav-curl is trying to do, but the file does exist, and if you put the URL in a browser, the file is automatically downloaded. I'll have to keep investigating...
Okay, I've made some progress on this issue. The short version: It comes from Github. The long version: - If the extension's oxt file is placed on a [raw Github URL][1] then the download will work. - If the extension's oxt file comes from a [Github revision URL][2] then the download won't work because Github requires a download with an HTTP session with cookies. In order to find out what is really going on with Github I wrote a [macro in BASIC][3] with the help of the OAuth2OOo extension and realized that it was necessary to proceed with the download in two HTTP requests in order to have cookies and to be able to proceed with the download. The first request, to the home on site, is only there to open the HTTP session and initialize cookies. While searching through the LibreOffice codebase, two places caught my eye: - The file [dp_gui_updateinstalldialog.cxx#L534][4] - The file [dp_registry.cxx#L425][5] I'm wondering if it would be possible to use an HTTP session to perform this download and be able to do it when the files come from a Github revision URL? [1]: <https://github.com/prrvchr/jdbcDriverOOo/raw/refs/heads/master/source/jdbcDriverOOo/dist/jdbcDriverOOo.oxt> [2]: <https://github.com/prrvchr/jdbcDriverOOo/releases/latest/download/jdbcDriverOOo.oxt> [3]: <https://github.com/prrvchr/OAuth2OOo/blob/master/source/OAuth2OOo/OAuth2OOo/GithubDownloadRequest.xba> [4]: <https://github.com/LibreOffice/core/blob/32aa68a652007a718f9e3f41b49e191f0527d518/desktop/source/deployment/gui/dp_gui_updateinstalldialog.cxx#L534> [5]: <https://github.com/LibreOffice/core/blob/32aa68a652007a718f9e3f41b49e191f0527d518/desktop/source/deployment/registry/dp_registry.cxx#L425>
I forgot to mention that my oxt files are large (over 50MB) and that Github gives me warnings when I push files of that size. According to Github, update files should normally be in revisions.
If nothing is done, then it would be good to write in big letters somewhere that the automatic update of LibreOffice does not work with the Github site because it seems to me that it is the first site in terms of quantity of free software online and this will prevent others from wasting their time.
prrvchr: this suggestion was made in the dev chat, but you did not report any result, can you say what happens if you do it: 'try adding a ".oxt" to the name there, and test. Of course, that doesn't solve the issue, but allows to test'
@Buovjaga There are two reasons why I refuse to do this: - How is it that by changing the URL on Github, I can get it to work? - How is it that if I try to download the file in a single HTTP request in the previous BASIC macro, I get a 405 error with the following error message: Please enable cookies. However, since I know that if I do nothing, nothing will happen, I'll add .oxt to the file name and keep you informed.
https://gerrit.libreoffice.org/c/core/+/188114
(In reply to prrvchr from comment #14) > @Buovjaga There are two reasons why I refuse to do this: > - How is it that by changing the URL on Github, I can get it to work? Heh, let me quote it in full. > mikekaganski: prrvchr: the difference likely was, that the package that you > download from one URL arrives as a .OXT, and another as `eff2c80e- > 138d-4b06-8139-e433f4672379` without an extension > ... > prrvchr: mikekaganski: Oh yes, this is very important, if I put the file in > the repository and access it via a raw URL, then the update is done > perfectly. So I persist, for me it is a problem of cookies that > WebDAV curl does not manage. > mikekaganski: prrvchr: for me it's not. I suppose, the whole question is why > an URL like > https://github.com/hanya/MRI/releases/download/v1.3.5/MRI-1.3.5.oxt > (from my debug session) arrives as a file named `eff2c80e-138d-4b06- > 8139-e433f4672379`. What defines the rename. > prrvchr: mikekaganski: From what I found it is a temporary file that is > created in the file: > prrvchr: https://github.com/LibreOffice/core/blob/master/desktop/source/ > deployment/gui/dp_gui_updateinstalldialog.cxx#L545 > mikekaganski: prrvchr: then just try adding a ".oxt" to the name there, and test > mikekaganski: of course, that doesn't solve the issue, but allows to test So how is it that you ignore what is told to you by people who intend to help you? Indeed, we were talking about *local filename*; and my proposal was to construct a *local filename* with an extension. And yes, *that* is the problem. And your "I persist", "I refuse" just tell something to me, if I should persist to try to help you in the future, or just skip. But I will fix at least this one for you.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b729b0bb677bd2b82492b45806ed3ddd91d2234f tdf#159775: restore filename from URL on redirection It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Mike Kaganski from comment #16) > > So how is it that you ignore what is told to you by people who intend to > help you? Indeed, we were talking about *local filename*; and my proposal > was to construct a *local filename* with an extension. And yes, *that* is > the problem. And your "I persist", "I refuse" just tell something to me, if > I should persist to try to help you in the future, or just skip. > > But I will fix at least this one for you. Well done and thank you for this quick solution. I admit I was mistaken; it has nothing to do with cookies, but a redirect. But it would be normal if you found the solution and you see that the other person made a mistake, then you correct it and not ask the other person to keep looking. Actually, I'm not getting paid ;-) Anyway, thanks again.
(In reply to prrvchr from comment #18) > But it would be normal if you found the solution and you see that the other > person made a mistake, then you correct it and not ask the other person to > keep looking. Actually, I'm not getting paid ;-) I didn't find the solution to that moment. I gave you the ideas I got from my weekend's debug session; I didn't yet got to dp_gui_updateinstalldialog.cxx and the tempfile there, which was what you pointed to - and I immediately suggested you to check that guess.
@Mike Kaganski I confirm that it works and again a big thank you to you. It took you much less time than it would have taken me to get to this point.
@Mike Kaganski Maybe this can be backported to the upcoming 25.8?
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/59340251fa4c403c0659e0016ff1e606b829c669 tdf#159775: restore filename from URL on redirection It will be available in 25.8.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Mike Kaganski, Thanks for backporting. This is my first time a fix has been available a week later... Until now, it took at least six months.
(In reply to prrvchr from comment #23) It was a trivial bug fix. These are backported ~automatically (Xisco takes care of that, and he did it this time, too). Your other changes were much more intrusive.
(In reply to Mike Kaganski from comment #19) > > I didn't find the solution to that moment. I gave you the ideas I got from > my weekend's debug session; I didn't yet got to > dp_gui_updateinstalldialog.cxx and the tempfile there, which was what you > pointed to - and I immediately suggested you to check that guess. I'd also like to clarify that I was convinced there was a cookie problem, and if I'm convinced of something, then you'll have a hard time making me do the opposite... It was precisely this flaw that gave me the strength to rewrite the SDBC layer in Java. But I was still willing to do it just to move this problem forward, as I mentioned earlier. I had to spend a lot of time, which isn't paid for, trying to resolve this problem; in fact, I mentioned the redirection issue in my Comment#3. My problem is that I don't have an IDE for LibreOffice, and all my debugging is done with SAL_DEBUG, a compilation (the first one takes me more than 12 hours and my machine becomes unusable), and then I read what's displayed on the screen, whereas a break point on the Curl command, which performs the download, normally allows you to see the redirection the first time... So, thank you for taking charge of this problem and managing to fix it so quickly. And thank you also for back-porting it so that this will be available very soon. And I hope you won't hold it against me and that we can continue together to fix what isn't working.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/50ee3ec188a6d51ba242f348257123a7260e1532 tdf#159775: restore filename from URL on redirection It will be available in 25.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.