Lighttpd

POST /cgi-bin/web_response.exe HTTP/1.1

Considering that some proxying (to thttpd) works for you, while other proxying (to web_response.exe) does not work for you, have you taken a closer look at web_response.exe? How does it handle connections? Does it send a response and then immediately closesocket() on the connection? Are you using closesocket() instead of close() in web_response.exe? What would happen if web_response.exe writes the response, forces a flush of any buffering, and then sleeps for a second before calling closesocket()? Or how about if web_response.exe writes the response, calls shutdown(fd, SHUT_WR), and waits for client (the lighttpd reverse proxy) to close the connection?

I have not looked inside web_response.exe yet. Do not be fooled by ".exe" it is running on a embedded linux machine. It is a web/control site build upon cgiC. This is legacy code maintained by other developers, and there is little change i will be allowed to modify, but i can look at the code though.
I works perfectly if i use HAproxy instead.

If you are interested i can create a wireshark trace.

gstrauss wrote:

[...]
The above request line suggests you are on a Windows machine.

Considering that some proxying (to thttpd) works for you, while other proxying (to web_response.exe) does not work for you, have you taken a closer look at web_response.exe? How does it handle connections? Does it send a response and then immediately closesocket() on the connection? Are you using closesocket() instead of close() in web_response.exe? What would happen if web_response.exe writes the response, forces a flush of any buffering, and then sleeps for a second before calling closesocket()? Or how about if web_response.exe writes the response, calls shutdown(fd, SHUT_WR), and waits for client (the lighttpd reverse proxy) to close the connection?

Sounds as good explanation (looking at the original responses)
This actually means we suck and do not comply with the HTTP protocol.
http://stackoverflow.com/a/11254057/2986991
Will you still make a praqmatic solution and accept \n\n ?
(i am not certain if this is implies by you target version)

stbuehler wrote:

I think the difference is whether the backend terminates the response header with "\r\n\r\n" (works) or with "\n\n" (doesn't work)

omegasteffy wrote:

Will you still make a praqmatic solution and accept \n\n ?
(i am not certain if this is implies by you target version)

We probably should, yes.

Untested patch:

diff --git a/src/mod_proxy.c b/src/mod_proxy.c
index b7d4b43..2e47436 100644
--- a/src/mod_proxy.c
+++ b/src/mod_proxy.c
@@ -534,14 +534,15 @@ static int proxy_response_parse(server *srv, connection *con, plugin_data *p, bu

        buffer_copy_buffer(p->parse_response, in);

-       for (s = p->parse_response->ptr; NULL != (ns = strstr(s, "\r\n")); s = ns + 2) {
+       for (s = p->parse_response->ptr; NULL != (ns = strchr(s, '\n')); s = ns + 1) {
                char *key, *value;
                int key_len;
                data_string *ds;
                int copy_header;

                ns[0] = '\0';
-               ns[1] = '\0';
+               if (s != ns && ns[-1] == '\r')
+                       ns[-1] = '\0';

                if (-1 == http_response_status) {
                        /* The first line of a Response message is the Status-Line */

Submitted pull request https://github.com/lighttpd/lighttpd1.4/pull/29 with the above patch