[BUG] Text (.txt) file won't download / open in Android App

[geobzmm]

Actual behaviour

Creating a .txt file on another device containing a few words or some notes in a accessible folder then syncs as expected to all devices - server, laptop, desktop and Mobile / Cell. the .txt file can be opened / viewed on server, laptop (win 10), desktop (win 11) but Android App displays message "Download Failed". All other "document" formats appear to work fine (eg. .pdf, .docx, .xlsx, .doc etc...).

Expected behaviour

The .txt file should open and show the text in the file or be downloadable to the Android device (neither of which is possible).

Steps to reproduce

1. Create .txt file containing text such as "Hello World!".
2. Allow to sync to OwnCloud Server - this works when file is originally generated on PC.
3. Refresh folder on Android device and attempt to open / download file.
4. Message appears onscreen "Download Failed".

Can this problem be reproduced with the official owncloud server? (url: https://demo.owncloud.org, user: test, password: test) Not tested on Official Server

Environment data

Android version: v13

Device model: Samsung Galaxy S20+5G

Stock or customized system: Stock One UI v5.1

ownCloud app version: v4.2.1

ownCloud server version: Infinite Scale Community v4.0.3 running webclient v7.1.2

Logs

ownCloud App Log (data/owncloud.log)

D: 2024-03-27 20:28:32:819(SingleSessionManager.java:98)getClientFor starting 
V: 2024-03-27 20:28:32:819(SingleSessionManager.java:125)reusing client for account [OwnCloudServer]
D: 2024-03-27 20:28:32:820(SingleSessionManager.java:180)getClientFor finishing 
D: 2024-03-27 20:28:32:869(OwnCloudClient.java:129)Executing in request with id ff931731-xxx-etc
I: 2024-03-27 20:28:32:869(ReadRemoteFileOperation.kt:72)Read remote file /Basic Files/Another Text File.txt with status 207
I: 2024-03-27 20:28:32:871(SynchronizeFileUseCase.kt:66)File Another Text File.txt is not downloaded. Let's download it
I: 2024-03-27 20:28:32:875(DownloadFileUseCase.kt:103)Download of Another Text File.txt has been enqueued.
D: 2024-03-27 20:28:32:876(ViewModelExt.kt:68)Use case executed: SynchronizeFileUseCase with result: Success(data=DownloadEnqueued(workerId=d04d033c-xxxx-4833-b2c2-xxx))
D: 2024-03-27 20:28:32:912(GetRemoteAppRegistryOperation.kt:54)Successful response {"mime-types":[]}
D: 2024-03-27 20:28:32:917(GetRemoteAppRegistryOperation.kt:64)Get AppRegistry completed and parsed to AppRegistryResponse(value=[])
D: 2024-03-27 20:28:32:962(SingleSessionManager.java:98)getClientFor starting 
V: 2024-03-27 20:28:32:963(SingleSessionManager.java:125)reusing client for account [OwnCloudServer]
D: 2024-03-27 20:28:32:964(SingleSessionManager.java:180)getClientFor finishing 
D: 2024-03-27 20:28:32:965(OwnCloudClient.java:129)Executing in request with id dc4b9aca-xxxx-4dbb-a919-xxx
D: 2024-03-27 20:28:33:073(OwnCloudClient.java:129)Executing in request with id eb935ee4-xxxx-4178-8530-xxx
E: 2024-03-27 20:28:33:228(DownloadRemoteFileOperation.kt:154)Content-Length not equal to transferred bytes.
D: 2024-03-27 20:28:33:229(DownloadRemoteFileOperation.kt:155)totalToTransfer = 0, transferred = 2451
I: 2024-03-27 20:28:33:231(DownloadRemoteFileOperation.kt:80)Download of /Basic Files/Another Text File.txt to /data/user/0/com.owncloud.android/files/owncloud/tmp/[OwnCloudServer]/80630633-xxxx-4b45-a280-bd1e9c8d8eec$b22ee417-b5ce-xxxx-920e-xxxx/Basic Files/Another Text File.txt - HTTP status code: 207
E: 2024-03-27 20:28:33:236(DownloadFileWorker.kt:127)com.owncloud.android.domain.exceptions.LocalStorageNotMovedException
    at com.owncloud.android.workers.DownloadFileWorker.moveTemporalFileToFinalLocation(DownloadFileWorker.kt:200)
    at com.owncloud.android.workers.DownloadFileWorker.doWork(DownloadFileWorker.kt:123)
    at androidx.work.CoroutineWorker$startWork$1.invokeSuspend(CoroutineWorker.kt:68)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

[JuancaG05]

Hi @geobzmm! Thanks a lot for the info! We'll take a look ASAP and will let you know news about this in this thread 🍻

[chaotix-]

I have the exact same problem with four different devices and v4.2.1 (I downgraded one to v4.2.0, but this did not make a difference), but with all tested data types (.ogg, .txt, *.jpg)

D: 2024-04-20 01:13:34:511(OwnCloudClient.java:129)Executing in request with id 76fe8527-57eb-4255-bdbe-cfcb14c67f72
E: 2024-04-20 01:13:35:911(DownloadRemoteFileOperation.kt:154)Content-Length not equal to transferred bytes.
D: 2024-04-20 01:13:35:913(DownloadRemoteFileOperation.kt:155)totalToTransfer = 0, transferred = 3198389
I: 2024-04-20 01:13:35:919(DownloadRemoteFileOperation.kt:80)Download of /testfile.ogg to /data/user/0/com.owncloud.android/files/owncloud/tmp/xxx@xxx/testfile.ogg - HTTP status code: 207
E: 2024-04-20 01:13:35:921(DownloadFileWorker.kt:127)com.owncloud.android.domain.exceptions.LocalStorageNotMovedException
        at com.owncloud.android.workers.DownloadFileWorker.moveTemporalFileToFinalLocation(DownloadFileWorker.kt:200)
        at com.owncloud.android.workers.DownloadFileWorker.doWork(DownloadFileWorker.kt:123)
        at androidx.work.CoroutineWorker$startWork$1.invokeSuspend(CoroutineWorker.kt:68)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

Webfrontend and Desktop-Sync are working fine.

This makes the Owncloud-App completely unusable for me.

[jesmrec]

will do a look here. Meanwhile, you can use the "open with" option to open with 3rd party apps (changes will sync to the server as well)

[chaotix-]

Thank you for taking your time to look at this.

Unfortunately using "open with" does not work either. I get the same small popup "Herunterladen fehlgeschlagen" (Download failed) at the bottom of the screen before it asks what app I want to open the file with.

Let me know if I can assist you in any way with debugging this.

[Noni006]

Hello, Same probleme for me: I: 2024-04-29 08:38:47:680(DownloadRemoteFileOperation.kt:80)Download of /test.pdf to /data/user/0/com.owncloud.android/files/owncloud/tmp/xxx@xxxx/test.pdf - HTTP status code: 207 E: 2024-04-29 08:38:47:682(DownloadFileWorker.kt:127)com.owncloud.android.domain.exceptions.LocalStorageNotMovedException

No way to access to my files

Everything is working on the PC or web client. Uninstall / install does not change anything

Thks for you help

[Noni006]

After lot of tests, I found the solution (in my case) The problem came from php-fpm With this processor, my owncloud server response as Transfer-Encoding : chunked so without Content-Length

But with apache php: serveur responce is with a Content-Length header and Android client works! A don't kown when it has changed..

[jesmrec]

@chaotix- @geobzmm could you take a look to @Noni006's solution? ⬆️ ⬆️ . It might fit your case as well.

[chaotix-]

@jesmrec Unfortunately this is not a solution for me as I am running several different virtual servers that need to run under different users. I don't think this is configurable with mod_php so I need to use php-fpm.

[JuancaG05]

This could be related: https://central.owncloud.org/t/download-failed-unknown-error/47935 Will research a bit about this and see if the problem is a common one for all cases 🚀

[linkp]

That is my post over at ownCloud Central. I can confirm that the files I tested were text files (markdown, specifically).

I also have been using PHP-FPM with my ownCloud instance for many years and cannot substitute mod PHP.

[dapkdapk]

@linkp @chaotix- @geobzmm I also use only php-fpm instances and had the same problem. by adding the line SetEnv ap_trust_cgilike_cl to the .htaccess file, my problem was solved.

[iasdeoupxe]

Might worth to mention that OP is using / running:

ownCloud server version: Infinite Scale Community v4.0.3

but other users mention php-fpm bot oCIS doesn't use PHP so this could be something different or even independent from the underlying server variant (oCIS vs. ownCloud 10).

Also not even sure if using php-fpm is officially supported for the PHP variant of ownCloud.

[JohnHardline]

@linkp @chaotix- @geobzmm I also use only php-fpm instances and had the same problem. by adding the line SetEnv ap_trust_cgilike_cl to the .htaccess file, my problem was solved.

This worked for me as well

[chaotix-]

It works for me as well. But I had to put it in the .htaccess file in my owncloud-data folder as it is not a subfolder of the owncloud folder.

[JuancaG05]

Hey @chaotix- , @JohnHardline, @iasdeoupxe, @dapkdapk, @Noni006 glad you found a solution, that seems to be server-related. Could you tell us which server version are you using? So that we can locate the error more easily and maybe solve whatever we need to solve from our side if needed

[JuancaG05]

@DeepDiver1975 all these problems seem to be related with an incorrect received Content-Length, are you aware of something changing in this regard recently?

[jvillafanez]

Side note: php-fpm is NOT supported with OC10. You're on your own. You can use a docker environment to setup ownCloud using the official docker image in an isolated way so it doesn't disturb the rest of your installation.

As for oCIS, please try to upgrade to 5.0.3 because it might be fixed there. It could be a server-side issue.

[dapkdapk]

Hey @chaotix- , @JohnHardline, @iasdeoupxe, @dapkdapk, @Noni006 glad you found a solution, that seems to be server-related. Could you tell us which server version are you using? So that we can locate the error more easily and maybe solve whatever we need to solve from our side if needed

Hi @JuancaG05 , this is my owncloud server version and php info lines below. Hope that helps.

version: 10.14.0.3
edition: Community

PHP Version 7.4.33
System  Linux dd29232 5.4.0-174-generic #193-Ubuntu SMP Thu Mar 7 14:29:28 UTC 2024 x86_64
Build Date  Apr 15 2024 11:22:17
Server API  FPM/FastCGI

[iasdeoupxe]

IF the users running the PHP version of ownCloud are really having the same problem as the OP using the non-PHP OCIS then it is really surprising how this should be a server side issue if two completely different technologies suddenly causing the very same issue and one requires an update (OCIS) while the other requires server side modifications in the PHP configuration (OC 10).

Sounds more that something changed on the client side (be it in the app itself, in a library or in Android).

[NoSilentRunning]

Just wanted to add that since about a week's time I was facing the same problem (all filetypes affected, on multiple android phones) and adding the SetEnv to the (main) .htaccess file solved the issue.

[jesmrec]

Just wanted to add that since about a week's time I was facing the same problem (all filetypes affected, on multiple android phones) and adding the SetEnv to the (main) .htaccess file solved the issue.

i get your point and this is also surprising for us. Last app version is two months ago, and server version the same. No changes in last week or last three weeks. Keep checking...

[jvillafanez]

@iasdeoupxe the common problem is that the server isn't sending the content-length header, or it sends it with a 0 length.

For OC10, as far as I know, the issue happens only with php-fpm, which, as said, it isn't supported. PHP as apache module (I think it's apache prefork) works fine (https://github.com/owncloud/android/issues/4352#issuecomment-2088392337)

For oCIS, the client logs show the same issue: content-length header seems to be 0 for a 207 HTTP response. I don't know the conditions for the server to send that kind of response, but there have been changes in this regard, so it's possible that the issue is solved in recent oCIS versions.

As for the android app, it has problems if the content-length of the downloaded file doesn't match the actual content. If the code didn't change, either the problem was there the whole time but nobody hit it, or android changed something about how downloads are handled if there is a mismatch with the content-length.

[jvillafanez]

In addition, I'd recommend to anyone having this issue (and posting here) to provide the environment data (check the opening post). The issue was posted for an android v13 phone, which is a relatively recent version. If everyone is having the issue with that version, we could narrow down the problem.

[appiekap653]

I have the same problem. I can upload files and see the files. But when trying to open them or download them I get unknown error while downloading. Filetype does not matter.

Specs:

Android 14 Samsung OneUI 6.0 Owncloud Android app 4.2.1

Server: Ocis 5.0.3

Logs:

2024-05-08T11:32:53Z WRN http |
service=storage-system pkg=rhttp 
traceid=############### host=127.0.0.1 
method=GET uri=/data/spaces/
jsoncs3-share-manager-metadata%21jsoncs3-share
-manager-metadata/groups/
########-###--####-####-############/
received.json url=/groups/
########-####-####-####-############/
received.json proto=HTTP/1.1 status=404 size=0 
start=08/May/2024:11:32:53 +0000 end=08/May/
2024:11:32:53 +0000 time_ns=154780 
line=github.com/cs3org/reva/v2@v2.19.6/internal
/http/interceptors/log/log.go:112 

[jesmrec]

@appiekap653 did you notice the error recently? did you update the app?

[appiekap653]

@appiekap653 did you notice the error recently? did you update the app?

I just installed owncloud for the first time yesterday. So this is the first time I tried everything and came on this error.

[appiekap653]

I just checked if downloading the same file was working with the web-client and that worked without problems.

Maybe I must also mention that the file was uploaded with the automatic photo upload function of the android app to a folder in a space.

[jesmrec]

did you try to download a file in test server (ocis.owncloud.works)?

[appiekap653]

did you try to download a file in test server (ocis.owncloud.works)?

No, what are the credentials?

[jesmrec]

einstein/relativity

[appiekap653]

That works with the test server

[appiekap653]

What does the 404 not found error mean from my logs?

[jesmrec]

What does the 404 not found error mean from my logs?

Could yo post here? operation related with the downloaded file?

EDIT:

you mean this:

received.json proto=HTTP/1.1 status=404 size=0

these are oCIS logs, for us (Android team) would be more useful Android logs... will do some check as well

[chaotix-]

My config: ownCloud server version: Debian package 10.14.0-1+10.1

Device 1: Android version: v13 Device model: Poco X3 Pro Stock or customized system: LineageOS 20 ownCloud app version: v4.2.1 (also tested with v4.2.0) (from F-Droid)

Device 2: Android version: v13 Device model: Xiaomi Pad 5 Stock or customized system: Arrow OS 13.1 ownCloud app version: v4.2.1 (from F-Droid)

Device 3: Android version: v14 Device model: Poco F5 Stock or customized system: Stock 1.0.3.0 ownCloud app version: v4.2.1

Device 4: Android version: v13 Device model: Xiaomi Pad 5 Stock or customized system: Stock 13.0.6 ownCloud app version: v4.2.1

[appiekap653]

My Android Log File:

E: 2024-05-08 
16:06:02:777(DownloadRemoteFileOperation.kt:154
)Content-Length not equal to transferred bytes. 

D: 2024-05-08 
16:06:02:777(DownloadRemoteFileOperation.kt:155
)totalToTransfer = 0, transferred = 2667846 

D: 2024-05-08 
16:06:02:534(LogInterceptor.kt:133)RESPONSE 
ca7907f6-b71a-4481-82ec-af9ac62bf590 
{"response":{"body":{"data":"<-- Body end for 
response -- Binary -- Omitted: 1785739 bytes 
-->","length":1785739},"headers":{"Date":"Wed, 08 
May 2024 14:06:01 GMT","Content-Type":"image/
jpeg; 
charset=UTF-8","Transfer-Encoding":"chunked","Con
nection":"keep-alive","access-control-allow-credentia
ls":"true","alt-svc":"h3=\":443\"; ma=86400","cf-cache-status":"DYNAMIC","content-di
sposition":"attachment; 
filename*=UTF-8''\"20240508_115422.jpg\"; 
filename=\"20240508_115422.jpg\"","content-securit
y-policy":"default-src 'self'; script-src 'unsafe-eval' 
wasm-eval; script-src-elem 'self' 'unsafe-inline' 
www.gstatic.com cdn.matomo.cloud 
traefik.github.io js.pusher.com; script-src-attr 
'unsafe-inline'; style-src 'self'; style-src-elem 'self' 
'unsafe-inline' fonts.googleapis.com 
cdnjs.cloudflare.com cdn.jsdelivr.net; style-src-attr 
'unsafe-inline'; img-src 'self' data: blob: 
a.tile.openstreetmap.org b.tile.openstreetmap.org 
c.tile.openstreetmap.org 
user-images.githubusercontent.com 
www.gravatar.com gravatar.com 
cdns-images.dzcdn.net e-cdns-images.dzcdn.net 
avatars.githubusercontent.com 
avatars0.githubusercontent.com 
avatars2.githubusercontent.com 
avatars3.githubusercontent.com frenck.dev 
github.com img.shields.io ui-avatars.com; font-src 
'self' data: fonts.gstatic.com cdn.jsdelivr.net 
cdnjs.cloudflare.com; connect-src 'self' 
o17675.ingest.sentry.io raw.githubusercontent.com 
wss://ws-eu.pusher.com api.github.com 
ka-p.fontawesome.com kit.fontawesome.com data: 
dpdb.webvr.rocks sockjs-eu.pusher.com blob: 
owncloud.mydomain.com 8eurk2.us ipinfo.io; 
media-src data: 'self'; worker-src 'self' blob:; 
frame-ancestors 'self'; form-action 'self'; 
manifest-src 'self'; frame-src 'self'; 
upgrade-insecure-requests; report-uri 
https://myacc.report-uri.com/r/d/csp/wizard; 
report-to 
default","content-security-policy-report-only":"default
-src 'none'; form-action 'none'; frame-ancestors 
'none'; report-uri 
https://myacc.report-uri.com/r/d/csp/wizard; 
report-to wizard","etag":"W/
\"###\"","last-modified":"Wed, 08 May 2024 09:54:24 
+0000","oc-checksum":"SHA1:###","oc-etag":"\"###\
"","oc-fileid":"###-###-###-###-###$
$afe###-####-###-###-###!
###-###-###-###-###","permissions-policy":"intere
st-cohort=() camera=(), microphone=(), 
geolocation=(), payment=(), usb=(), 
vr=()","report-to":"{\"group\": \"default\",\"max_age\": 
31536000,\"endpoints\": [{\"url\": 
\"https://myacc.report-uri.com/a/d/g\"}],\"include
_subdomains\": true}, {\"group\": \"wizard\",
\"max_age\": 31536000,\"endpoints\": [{\"url\": 
\"https://myacc.report-uri.com/r/d/csp/wizard\"}]
,\"include_subdomains\": 
true}","reporting-endpoints":"default=\"https://myacc
.report-uri.com/a/d/g\", 
wizard=\"https://myacc.report-uri.com/r/d/csp
/
wizard\"","strict-transport-security":"max-age=63072
000; includeSubDomains; 
preload","vary":"Accept-Encoding,Origin","x-content-ty
pe-options":"nosniff","x-download-options":"noopen",
"x-forwarded-proto":"https","x-frame-options":"SAME
ORIGIN","x-permitted-cross-domain-policies":"none","
x-request-id":"###/
###-###","x-robots-tag":"none,noarchive,nosnippet,n
otranslate,noimageindex,","x-xss-protection":"1; 
mode=block","Server":"cloudflare","CF-RAY":"###-AM
S"},"info":
{"id":"###-###-###-###-###","method":"GET","reply":
{"cached":false,"duration":197,"durationString":"durati
on(0h, 0min, 0s, 
197ms)","status":200,"version":"http/1.1"},"url":"https:
//owncloud.mydomain.com/dav/spaces/
###-###-###-###-###$afe###-###-###-###-####
#/myacc/20240508_115422.jpg"}}}

[jesmrec]

here is the problem as @jvillafanez stated above:

E: 2024-05-08 16:06:02:777(DownloadRemoteFileOperation.kt:154)Content-Length not equal to transferred bytes.

size of the file does not match with the Content-Length header, that was sent by the server. But, the problem does not happen with the test server... is there anything in the middle of your infra (proxys, middlewares, security firewalls...) that could cheat headers? this is pretty weird...

[appiekap653]

Cloudflare Proxied maybe? I will try to disable the p roxie of cloudflare and check back with my results

[appiekap653]

Same error with cloudflare Proxie disabled

[appiekap653]

I found the problem.

It was the Compress Middleware of Traefik. When turned off in the middleware-chain download started working, when turned back on it failed again.

This is what Traefik said about it:

Responses are compressed when the following criteria are all met:

The Accept-Encoding request header contains gzip, *, and/or br with or without quality values. If the Accept-Encoding request header is absent, the response won't be encoded. If it is present, but its value is the empty string, then compression is disabled.

The response is not already compressed, i.e. the Content-Encoding response header is not already set.

The responseContent-Type header is not one among the excludedContentTypes options, or is one among the includedContentTypes options.

The response body is larger than the configured minimum amount of bytes (default is 1024).

Can it be that the android app is not setting the Accept-Encoding header correctly? Since the web client did not had any issues downloading with Compress enabled?

[jesmrec]

Can it be that the android app is not setting the Accept-Encoding header correctly? Since the web client did not had any issues downloading with Compress enabled?

it's a clue... will check it

Thanks for taking a look into.

[jesmrec]

Accept-Encoding is set to identity from scratch (no changes there in many years). But, i notice that iOS client is using gzip, deflate, br ... not sure how far is this affecting. Keep checking...

[appiekap653]

Accept-Encoding is set to identity from scratch (no changes there in many years). But, i notice that iOS client is using gzip, deflate, br ... not sure how far is this affecting. Keep checking...

Many years without this problem could be related to Ocis now being used with Traefik instead of old Owncloud with Apache, Nginx or Caddy.

[appiekap653]

I found this issue still open at Traefik.

https://github.com/traefik/traefik/issues/6449

Seems like Traefik is in the wrong here.

[jesmrec]

That will be something for the backend team, @jvillafanez @micbar is that issue affecting backend performance somehow? are you aware of?

OTOH, as oC10 is also involved, the global behaviour is broken somehow.

[appiekap653]

These are my logs showing the difference between Compress Middleware enabled with error while downloading and Compress Middleware disabled with downloads working.

Compress Middleware disabled:

D: 2024-05-09 14:16:00:534(LogInterceptor.kt:133)RESPONSE ##-##-##-##-## {"response":{"body":{"data":"<-- Body end for response -- Binary -- Omitted: 1784737 bytes -->","length":1784737},"headers":{"Date":"Thu, 09 May 2024 12:15:59 GMT","Content-Type":"image/jpeg; charset=UTF-8","Content-Length":"2667846","Connection":"keep-alive","accept-ranges":"bytes","access-control-allow-credentials":"true","alt-svc":"h3=\":443\"; ma=86400","cf-cache-status":"DYNAMIC","content-disposition":"attachment; filename*=UTF-8''\"20240508_115422.jpg\"; filename=\"20240508_115422.jpg\"":{"id":"##-##-##-##-##","method":"GET","reply":{"cached":false,"duration":199,"durationString":"duration(0h, 0min, 0s, 199ms)","status":200,"version":"http/1.1"},"url":"https://owncloud.mydomain.com/dav/spaces/##-##-##-##-##$##-##-##-##-##/##/20240508_115422.jpg"}}}

Compress Middleware enabled:

D: 2024-05-09 14:16:00:919(LogInterceptor.kt:133)RESPONSE ##-##-##-##-## {"response":{"body":{"data":"<-- Body end for response -- Binary -- Omitted: 547998 bytes -->","length":547998},"headers":{"Date":"Thu, 09 May 2024 12:16:00 GMT","Content-Type":"image/jpeg","Transfer-Encoding":"chunked","Connection":"keep-alive","access-control-allow-credentials":"true","alt-svc":"h3=\":443\"; ma=86400":{"id":"##-##-##-##-##","method":"GET","reply":{"cached":false,"duration":68,"durationString":"duration(0h, 0min, 0s, 68ms)","status":200,"version":"http/1.1"},"url":"https://owncloud.mydomain.com/dav/spaces/##-##-##-##-##$##-##-##-##-##/##/20240508_115422.jpg?x=336&y=336&c=##&preview=1"}}}

It seems that when it is working, Traefik sends a Content-Length header. When it is not working, Traefik omits the Content-Length header but sends a Transfer-Encoding header instead.

[jesmrec]

will forward this to backend... we have many guesses but not easy to know which one is the breaking issue. Will keep you updated.

[jesmrec]

Also, if any of you wants to help as well, you could provide us a test account in a server in which you reproduce the problem with the 4.2.1 version. Just upload a txt file including the URL and test credentials to this place. No one but us will see what you push there. Pwd: 4352_testServer.

Our main problem here is that we are not able to reproduce in our servers and infra. Being able to reproduce will be the first big step to get the solution.

[jvillafanez]

I can't reproduce the issue with traefik 2.10.4 : it always sends a content-length header. Maybe I'm not setting the right options... these are the ones I'm using for the ocis container.

      - "traefik.enable=true"
      - "traefik.http.routers.ocis.entrypoints=https"
      - "traefik.http.routers.ocis.rule=Host(`ocis.${DOMAIN:-owncloud.test}`)"
      - "traefik.http.routers.ocis.tls.certresolver=http"
      - "traefik.http.routers.ocis.service=ocis"
      - "traefik.http.services.ocis.loadbalancer.server.port=9200"
      - "traefik.http.middlewares.ocis.compress=true"

[appiekap653]

Also, if any of you wants to help as well, you could provide us a test account in a server in which you reproduce the problem with the 4.2.1 version. Just upload a txt file including the URL and test credentials to this place. No one but us will see what you push there. Pwd: 4352_testServer.

Our main problem here is that we are not able to reproduce in our servers and infra. Being able to reproduce will be the first big step to get the solution.

I have uploaded the text file with my server to test

[appiekap653]

To reproduce, this is my config for Traefik:

Middlewares.yaml

    compress:
      compress: {}

Middleware-chains.yaml

    chain-owncloud:
      chain:
        middlewares:
          - rate-limit
          - https-redirectscheme
          - default-secure-headers
          - compress

Container label:

      - "traefik.http.routers.owncloud-rtr.middlewares=chain-owncloud@file"