Why isn't my version of LibreOffice displaying URLs in my database Image Control?

English
,
#1

Here’s the test I performed:

wget --server-response https://asianwiki.com/images/f/fa/100_Days_My_Prince-P1.jpg
–2025-12-12 14:18:32-- https://asianwiki.com/images/f/fa/100_Days_My_Prince-P1.jpg
Résolution de asianwiki.com (asianwiki.com)… 104.26.9.64, 104.26.8.64, 172.67.74.142
Connexion à asianwiki.com (asianwiki.com)|104.26.9.64|:443… connecté.
requête HTTP transmise, en attente de la réponse…
HTTP/1.1 403 Forbidden
Date: Fri, 12 Dec 2025 19:18:33 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Referrer-Policy: same-origin
X-Frame-Options: SAMEORIGIN
Vary: accept-encoding
Report-To: {“group”:“cf-nel”,“max_age”:604800,“endpoints”:[{“url”:“https://a.nel.cloudflare.com/report/v4?s=OF60BwwpXcrGdrUgW%2FoFggDhW1tcfR%2FxHLX5riyWWrId1k5URf5Kflz5msk7Mm%2BrOCI2ORhK7Oz9llx0msbe1HdpV3SvUv%2BBiGQ%3D”}]}
Nel: {“report_to”:“cf-nel”,“success_fraction”:0.0,“max_age”:604800}
Server: cloudflare
CF-RAY: 9acf91785db3b2eb-YYZ
2025-12-12 14:18:33 erreur 403 : Forbidden.

The Cloudflare server that protects AsianWiki returns an HTTP/1.1 403 Forbidden error when the request is made directly from my LibreOffice version on Linux Ubuntu Studio.

Why does this work on Windows but not on Linux? Is the problem with Linux or LibreOffice?

Version: 25.2.7.2 (X86_64) / LibreOffice Community
Build ID: 5cbfd1ab6520636bb5f7b99185aa69bd7456825d
CPU threads: 8; OS: Linux 6.14; UI render: default; VCL: kf5 (cairo+wayland)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded

#2

You didn’t provide information about what exactly succeeds on Windows. And hence:

The problem is, likely, the server that protects AsianWiki, that uses an unknows rule that stops requests shown in your question, but passes a request from an unknown request made from Windows.

Note that wget uses a different UserAgent compared to LibreOffice (and we had bugs that some servers used to reject LibreOffice’s UserAgent, when we changed our web access library to curl - see e.g. tdf#148429). Of course, the UserAgent may the what gets filtered by the server. Or it may be something else.

By the way:

How exactly is this request made from LibreOffice? Do you mean that you run a shell command from a macro? Then it would have nothing to do with LibreOffice machinery at all.

#3

Here’s the context. I have an image control whose data field is linked to a table field that stores the image URL. The image is therefore displayed dynamically in the form. This URL is retrieved via a macro that inserts it into the table field, so there’s no need to copy and paste.
.
As I mentioned, this works perfectly on Windows. But with the Linux version, the 403 restriction related to the AsianWiki site prevents this dynamic display. Some other sites, like Rakuten VIKI, don’t impose this restriction, and the dynamic display works fine with both the Windows and Linux versions.
.
That’s why I was wondering why there’s this difference in behavior between the LibreOffice versions on Windows and Linux. Are the LibreOffice versions on Linux more restrictive than on Windows, or is it the operating system itself that’s restrictive?
.
I can understand that Cloudflare enforces this protection and returns a 403 error, but why is it so easily bypassed on Windows but not on Linux?
.
I also suspect that on Linux, there are probably as many versions of LibreOffice as there are distributions.
.
So, this situation isn’t dramatic in itself, but it leaves me very perplexed about how LibreOffice works on different systems. I imagine that on macOS, things must be similar to Linux, given that they are both based on Unix.

#4

Neither LibreOffice nor Linux will deny your request. The server at AsiaWiki is “restrictive”.
.
The question left is: What difference is there in the request, and can we perhaps avoid being denied by Cloudflare.

Don’t bet money on this.

#5

Do you mean, that a command line

wget --server-response https://asianwiki.com/images/f/fa/100_Days_My_Prince-P1.jpg

works on Windows? There is no wget built-in there. You definitely skip steps of the context.

What is the exact code used in your macro, both on Linux and Windows?

#6

No, I tested image accessibility using wget in the console of the Linux system I’m using. I’m dual-booting with Windows.

Under Windows, LibreOffice loads the dynamic image without any problem. The URL is stored in the table field linked to the image control, and the image loads each time a record is changed in the form, sometimes with a slight delay, but it’s very short.

Under Linux, the image for the AsianWili website isn’t loaded at all because of the restriction.

It’s as if LibreOffice isn’t adding a User-Agent, which creates a difference in the HTTP headers sent compared to what happens under Windows.

#7

No code loading the URL = no sane answer possible. Given that I asked twice already, I’m off.

#8

Mike,
.
The macro I mentioned is only used to insert a URL retrieved from the AsianWiki website into the table field that will be used by the ‘Data Field’ property of the Picto control. It has nothing to do with the display in the form.
.
If you look at the screenshot, you can see the assignment of the ‘Poster’ table field from the T_FilmsSeries table. The ‘Poster’ column of the table contains all the URLs associated with each record in the form.
.
The macro was used to automate the insertion of URLs into this table field, and it works very well. This avoids manual copy/pasting.
.
As I’ve mentioned several times, on Windows, the image control dynamically displays the image corresponding to the URL in the Poster field, but this doesn’t happen in LibreOffice on Linux.
.

image
image1890×1074 556 KB

#9

Aha, at last: the URL fails in ‘Data Field’ property of the “Picto” (? need to check its English name) control. Already something to try to reproduce. Thanks.

#10

Sorry, sometimes we’re not sure how to present a problem, only to realize that a picture is worth a thousand words…

I hope there’s a possible solution. Thank you for taking the time to reproduce this issue.

#11

Aha, I reproduce using Version: 25.8.3.2 (X86_64) / LibreOffice Community
Build ID: 580(Build:2)
CPU threads: 24; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Ubuntu package version: 4:25.8.3~rc2-0ubuntu0.24.04.1~lo1
Calc: threaded

But on the same Ubuntu system, it works just fine using a self-built instance.

How do you install LibreOffice there? It may be a problem in the way distro(s) configure their LibreOffice builds. Or maybe something else.

#12

I downloaded this version from the LibreOffice website.

Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 8; OS: Linux 6.14; UI render: default; VCL: kf5 (cairo+wayland)
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: CL threaded

I used the command line via Konsole with the following command: sudo dpkg -i *.deb
I installed the language and help packages in the same way.

I just opened my file to realize that the image control wasn’t displaying the URL.

#13

Interesting, if this is related to 11f439b861922b9286b2e47ed326f3508a48d44e - core - Gitiles . (But the error seems different.)

Anyhow: since this affects the TDF-supplied package, please file a bug report. An easy way to repro is simply

soffice https://asianwiki.com/images/f/fa/100_Days_My_Prince-P1.jpg

which succeeds on Windows, opening the JPEG in Draw, but produces this on Linux:

image

FTR: the user agent string is definitely sent. But its content is different on different systems.

#14

I tested this with wget and Cloudflare doesn’t seem to impose any restrictions. If the NSS Backend has been removed from cURL, that’s probably why it’s not working.
.
wget --server-response --user-agent=“Mozilla/5.0 (Windows NT 10.0; Win64; x64)” https://asianwiki.com/images/3/32/Something_About_1_Percent_(2016)-p1.jpg
–2025-12-13 14:24:26-- https://asianwiki.com/images/3/32/Something_About_1_Percent_(2016)-p1.jpg
Résolution de asianwiki.com (asianwiki.com)… 104.26.8.64, 172.67.74.142, 104.26.9.64
Connexion à asianwiki.com (asianwiki.com)|104.26.8.64|:443… connecté.
requête HTTP transmise, en attente de la réponse…
HTTP/1.1 200 OK
Date: Sat, 13 Dec 2025 19:24:26 GMT
Content-Type: image/jpeg
Content-Length: 322309
Connection: keep-alive
Server: cloudflare
Last-Modified: Mon, 05 Sep 2016 01:35:40 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Nel: {“report_to”:“cf-nel”,“success_fraction”:0.0,“max_age”:604800}
cf-polished: ok
priority: u=1;i=?0,cf-chb=(172;u=3;i=?0 15433;u=5;i 153865;u=6;i)
cf-bgj: imgq:100,h2pri
Age: 88067
cf-cache-status: HIT
Vary: accept-encoding
Report-To: {“group”:“cf-nel”,“max_age”:604800,“endpoints”:[{“url”:“https://a.nel.cloudflare.com/report/v4?s=4YcZ7EwBzFHI7%2B5dkIrWsUGKMnUVjOwLpQt90JW9zRvxy7OFoBJNJZCESOTqFHQLZJvQbe1hnl4th5hxZ1Xu3kJ2lWSFgggpE9Y%3D”}]}
CF-RAY: 9ad7d77c7b4da223-YYZ
Taille : 322309 (315K) [image/jpeg]
Enregistre : ‘Something_About_1_Percent_(2016)-p1.jpg.2’

Something_About_1_Percent_(2016)-p1.j 100%[=======================================================================>] 314,75K --.-KB/s ds 0,03s

2025-12-13 14:24:27 (8,86 MB/s) - ‘Something_About_1_Percent_(2016)-p1.jpg.2’ enregistré [322309/322309]

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.