brendonm

I fixed this issue by adding the following line: httpd/server_fcgi.c: 554 > ``` > if (clt->clt_fcgi_type == FCGI_END_REQUEST) { > server_reset_http(clt); > } > ``` This effectively resets the connection...

I can reproduce this issue on plain HTTP hosts only. Httpd seems to send "Connection: close" for all HTTPS connections, which is why I couldn't replicate it on anything but...

In the code, the only place where I could find a reference to server_reset_http was in the server_file.c functions where static files are referenced. Unfortunately, there is a branch out...

This issue also has another side effect: When connecting with tls (on a FastCGI URL), the server responds with a "Connection: close" but does not actually close the connection afterwards...

This issue still exists (a year after first reported). I was wondering if there are any plans to look into this issue? Just to recap: - The FastCGI implementation is...

Why would it not work with padding exactly? As far as I am aware, my patch does not break the read loop from FastCGI, it simply completes the HTTP response...

I have tested the 8033504 commit you posted (using OpenBSD 6.0), thanks for this. Output without modification shows a lot of these: `server_response: request 2 in server_fcgi not finished` I...

After a lot more testing, I can confirm that the server_file_error method is not being called when the fd is a TCP socket. I put in a debug message at...

To clarify, the Content-Type and Content-Length headers _are_ being sent through FastCGI as CONTENT_TYPE and CONTENT_LENGTH respectively. This differs from the nginx implementation which also includes them as HTTP_CONTENT_TYPE and...

Possible fix could be to comment out the following lines: httpd/server_fcgi.c: 649 > // if (strcasecmp(key, "Content-Length") == 0 || > // strcasecmp(key, "Content-Type") == 0) { > // if...