On 2021-05-13 22:00 +01, Chris Narkiewicz <[email protected]> wrote:
> 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.
>
oh, it's 204 no content. I missed that.
The demo url (apparently running appache) doesn't return a
Content-Lenght, either.
Anyway, trying to chunk encode an empty body is not going to work well.
This is making the spice flow again:
diff --git server_fcgi.c server_fcgi.c
index 8d3b581568f..0ac80c27d11 100644
--- server_fcgi.c
+++ server_fcgi.c
@@ -615,6 +615,10 @@ server_fcgi_header(struct client *clt, unsigned int code)
if (kv_add(&resp->http_headers, "Server", HTTPD_SERVERNAME) == NULL)
return (-1);
+ /* we cannot chunk-encode no-content */
+ if (code == 204)
+ clt->clt_fcgi.chunked = 0;
+
/* Set chunked encoding */
if (clt->clt_fcgi.chunked) {
/* XXX Should we keep and handle Content-Length instead? */
> Cheerio,
> Chris
>
--
I'm not entirely sure you are real.
