On Thu, Oct 30, 2025 at 10:51:42PM +0100, Claudio Jeker wrote: > On Wed, Oct 29, 2025 at 06:06:36PM +0100, Claudio Jeker wrote: > > On Thu, Sep 25, 2025 at 01:31:07PM +0200, Claudio Jeker wrote: > > > On Thu, Sep 25, 2025 at 01:14:16PM +0200, Florian Obser wrote: > > > > Nobody stepped up to fix chunked encoding in fastcgi. I think we should > > > > disable it. > > > > OK? > > > > > > No. > > > > Just to be clear, this turns off chunked encoding for output but the > > problem is when data is sent with chunked encoding in a POST. I doubt that > > forcing clt->clt_fcgi.chunked = 0 will fix chunked encoding handling > > during input processing. My fear is that httpd has no code to handle > > chunked encoding in POST request (as in sent by the client) and all of > > that needs to be written first. > > The problem is in server_read_httpchunks() which is the rev 1.1 copy of > code from relayd and is not doing the right thing. When florian@ added > POST support he only did it for server_read_httpcontent() but did not > adjust server_read_httpchunks(). All of this was done 11 years ago so this > bug has been in httpd since the beginning. > > I think the following diff below is what is needed. It seems to work with > the provided test case. It is too late to do further tests, so I hope > someone else will do that.
Testing this diff, (as well as the second version you posted), the problem of user-submitted body content being returned by the server seems to be fixed. However, if a POST request is sent with transfer-encoding:chunked and a non-zero length for the body, then the server returns nothing and the tcp connection remains open. Is that the expected or desired behaviour? (Tested with both slowcgi and the custom fcgi handler that runs on *.exoticsilicon.com, with the same results.)
