On Thu, May 13, 2021 at 08:24:46AM +0200, Florian Obser wrote: > I don't think so, I'm running current and I last updated my nextcloud > server on Apr 30th.
It's not Nextcloud server. When app tries to upload, it pings the server on /index.php/204 endpoint expecting code 204 No Content and Content-Length: 0. Since this header is not available when doin Transfer-Encoding: chunked, the application HTTP client returns -1. The test fails and app thinks server is down, aborting the upload. I fixed that problem in the app, but it will take time until it gets accepted and rolls into stable version in Play store. > While my timeline suggests that this is triggered by a change in the > mobile app, I'm happy to entertain the idea that httpd is doing > something wrong. Were you able to try with e.g. nginx and is it working > there? Yes, nginx works correctly. It broke after I upgraded my httpd. I did not update the client. > I'd be interested in seeing HTTP request/response headers for httpd(8) > and nginx to see how they are different if this works with nginx. I did this when investigating the problem. Nginx returns 204 and no Transfer-Encoding header. Httpd returns 204 and Transfer-Encoding: chunked and no Content-Length. Since I'm familiar with the Java/Kotlin code on the client side, and stepped through it with a debugger, I know that chunked encoding is the root cause, causing the client to return reply without content length (signalled as -1). > Or maybe the answer is just: nginx doesn't do chunked encoding? You can check by doing curl -v https://demo1.nextcloud.com/index.php/204 and the same with something that runs on httpd. Cheerio, Chris
signature.asc
Description: PGP signature
