Lighttpd

Please be detailed in what protocol you are using

HTTP/1.1.

for compatibility with less-strictly compliant clients, I might not end up making any changes.

Any client that generates empty CL values would be incompatible with nearly every web server, and is therefore very unlikely to exist. Among the HTTP servers that reject empty CL values are aiohttp, Apache httpd, Boost::Beast, Gunicorn, h2o, Microsoft IIS, Jetty, Nginx, Node.js, Apache Tomcat, Tornado, all of the major CDNs, and nearly all major proxies. By accepting empty CL headers, Lighttpd makes the job of HTTP client programmers more difficult because their requests will be accepted by Lighttpd and basically nothing else.

Please provide more details how and why you think this behavior might constitute request smuggling.

I am aware of an HTTP parser in a widely-used server (which I cannot disclose at this time) that makes the opposite assumption to Lighttpd. (i.e. it interprets the message body of a request with an empty Content-Length header to be all bytes received after the request headers.) I suspect that the programmers of this unnamed server are not the only people to have settled on that interpretation of the empty CL header. I am also aware of two widely-used HTTP proxies that are happy to forward requests with empty CL header values intact, in violation of the RFC.

While I could invent a sitaution in which Lighttpd's interpretation of the empty header plays a part in a request smuggling exploit chain involving these proxies and servers, it would only be an invention. If you're looking for a PoC, I have none. That said, Lighttpd's HTTP/1.1 parser does not accept any other malformed CL values. Lighttpd also does not accept CL values consisting of comma-separated lists of duplicate integers, which the RFC states it MAY. It seems strange and inconsistent to forbid all malformed CL values except one, especially while rejecting what some would argue are valid CL headers.

There are places in which Postel's law applies. I believe that the Content-Length header is not one, due to its use in request smuggling and response splitting. If you disagree with me about this, then our disagreement will not be sorted out in this issue thread, and you should therefore feel free to close it.

Thank you for taking the time to read this thread.

Thanks. I appreciate the details. While I do not agree with your tenuous logical leaps, I will treat your (intentionally) vague assertions of other servers behaviors as true for the sake of continuing the discussion.

I am also aware of two widely-used HTTP proxies that are happy to forward requests with empty CL header values intact, in violation of the RFC.

That is a bug in those HTTP proxies and could contribute to request smuggling through those HTTP proxies. It is not a bug in lighttpd.

(i.e. it interprets the message body of a request with an empty Content-Length header to be all bytes received after the request headers.)

This does not make sense to me for HTTP/1.1. No such behavior is documented in HTTP/1.1 RFCs. No such behavior is implied in the HTTP/1.1 RFCs. HTTP/1.0 might half-close a TCP connection to indicate end of request body, but if I recall correctly, that is not permitted in HTTP/1.1, and also not widely supported by servers since reading EOF is often an indication of TCP connection closed. In HTTP/1.1, a request body must be indicated with a Content-Length of non-negative integer value, or via Transfer-Encoding: chunked.

Whoever made that choice is overloading Content-Length in what I consider a non-intuitive way. lighttpd does not send an empty Content-Length to backends (e.g. mod_proxy or any CGI-based backend, such as FastCGI), so I do not see how that other server treating Content-Length that way is any concern of lighttpd. If that server were to send an empty Content-Length, then as you pointed out, that would be a violation of the RFC and a bug in that server, not lighttpd.

Any client that generates empty CL values would be incompatible with nearly every web server, and is therefore very unlikely to exist. [...] By accepting empty CL headers, Lighttpd makes the job of HTTP client programmers more difficult because their requests will be accepted by Lighttpd and basically nothing else.

Sorry, since the situation is unlikely to exist, I do not believe your conclusion logically follows. As I said previously, lighttpd ignores empty request headers, and so lighttpd's behavior when receiving an empty Content-Length is the same as if Content-Length was not sent at all.

How does this affect HTTP client programmers? HTTP client programmers should not send malformed requests. (If you are writing HTTP/1.1 conformance tests, then, yes, I believe that there is more than one allowed behavior for empty Content-Length.)

I read this issue as a request for lighttpd to reject empty Content-Length. I will consider the feature request.

I do not believe lighttpd's behavior is incorrect, although lighttpd's behavior in this case is not the behavior that you desire. I have not carefully reviewed RFC 9110 et al, but will try to make some time to do so.

Modifying this behavior in lighttpd is not difficult, but might be a measurable cost on the critical path for every header in every request.

While I could invent a sitaution (sic) in which Lighttpd's interpretation of the empty header plays a part in a request smuggling exploit chain involving these proxies and servers, it would only be an invention.

That would be a bug in those other servers, not lighttpd. You seem to be stuck on the idea that lighttpd accepting and ignoring empty Content-Length is wrong, but only because others do it differently. If it is wrong, please help me find evidence of that in the RFCs. Otherwise, it would be unfortunate if the bug in broken proxies were able to send a request to lighttpd with empty Content-Length, which lighttpd ignored, but is not a bug in lighttpd since the behavior in lighttpd is the same as when Content-Length is not provided in the request.

That said, Lighttpd's HTTP/1.1 parser does not accept any other malformed CL values. Lighttpd also does not accept CL values consisting of comma-separated lists of duplicate integers, which the RFC states it MAY. It seems strange and inconsistent to forbid all malformed CL values except one, especially while rejecting what some would argue are valid CL headers.

It seems strange that you have ignored my explanation that lighttpd historically ignores empty request headers. Simple.

Lighttpd also does not accept CL values consisting of comma-separated lists of duplicate integers, which the RFC states it MAY.

That would indicate duplicated Content-Length sent through broken proxies, and that the request was not rejected or fixed by those proxies, and then combined into a single field before the request was sent to lighttpd. I have chosen not to attempt to fix all broken behavior from broken proxies. While it could be coded in lighttpd, it is extra bytes for a malformed request, and lighttpd is permitted by the RFCs to reject that malformed request. lighttpd does just that.

Checkpoint, in case this is revisited. This would reject empty Content-Length for HTTP/1.x requests, but this code does not check empty Content-Length for HTTP/2 (or later).

--- a/src/request.c
+++ b/src/request.c
@@ -1197,7 +1197,11 @@ static int http_request_parse_headers(request_st * const restrict r, char * cons

         const int vlen = (int)(end - v);
         /* empty header-fields are not allowed by HTTP-RFC, we just ignore them */
-        if (vlen <= 0) continue; /* ignore header */
+        if (__builtin_expect( (vlen <= 0), 0)) {
+            if (id == HTTP_HEADER_CONTENT_LENGTH)
+                return http_request_header_line_invalid(r, 400, "invalid Content-Length header -> 400");
+            continue; /* ignore header */
+        }

         if (http_header_strict) {
             const char * const x = http_request_check_line_strict(v, vlen);

Aside: RFC 9112 HTTP/1.1 requires that servers reject or close the connection after servicing an HTTP/1.1 request containing both Content-Length and Transfer-Encoding. Again, lighttpd currently ignores request headers with empty field values, so ignores empty Content-Length, but I have added code to my dev branch so that the next release of lighttpd will disable keep-alive on an HTTP/1.1 connection where a request is sent with both valid Content-Length (non-empty) and Transfer-Encoding: chunked.

Thank you for the thoughtful responses. Your concern for the correctness and performance of lighttpd is refreshing.