History

Not a bug. That's intentional. Why are you sending a request-body with GET or HEAD?

https://www.ietf.org/rfc/rfc7231.txtSection 4.3.1 GET... A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

GuzzlePHP seems to set the encoding to chunked if it can't determine the length of the request body, which is the case when you try to forward the request PHP got to a different server, because then it will use stdin for the request body.

While I am aware that using a chunked encoding with GET is not really correct, I would argue though that rejecting such a request is too strict if the request body is empty.Especially because other implementations, such as Apache HTTPD, allow such requests.

If you decide to maintain the strict implementation, you should at least adjust the error message to better reflect the true reason of rejecting the request, which is the Transfer-Encoding header, not a non-empty body.

GuzzlePHP seems to set the encoding to chunked if it can't determine the length of the request body, which is the case when you try to forward the request PHP got to a different server, because then it will use stdin for the request body.

That's gross. [edit: gross for a GET request]

While I am aware that using a chunked encoding with GET is not really correct, I would argue though that rejecting such a request is too strict if the request body is empty.

The code in lighttpd does accept and discard Content-Length: 0. Sending an empty request body via 0-length chunk can still occur with a long time delay, and, as I quoted in the RFC above, lighttpd can legitimately reject the request.

If you decide to maintain the strict implementation, you should at least adjust the error message to better reflect the true reason of rejecting the request, which is the Transfer-Encoding header, not a non-empty body.

No, the request is rejected before any body is read. Ending chunk may have been sent already, but it also may not have been sent (and could be sent minutes later) or might be in a separate packet. lighttpd is not spending any additional resource on this Bad Request, and does not know if the body that will be sent by Transfer-Encoding chunked is empty or not.

Did you file a bug with GuzzlePHP? Since you did not provide the reference here, I am going to assume that you did not. Please kindly tell them to fix their code. This is most definitely not a bug in lighttpd. (If you disagree, don't bother trying to convince me. I refer you once again to the RFC specification I quoted above.)