Lighttpd

I am using 1.4.45 but also the same troubles with 1.4.53

You have described behavior that you have observed in Chrome. Why do you think this is a problem in lighttpd?

I quickly tested lighttpd with 'openssl s_client' and an oversized HTTP POST request is properly rejected with a "413 Request Entity Too Large"

Have you tested with something other than Chrome?

Please try the following patch. I am going to guess that Chrome is seeing a TLS error before it sees the HTTP response.

--- a/src/connections.c
+++ b/src/connections.c
@@ -150,7 +150,7 @@ static int connection_close(server *srv, connection *con) {
        return 0;
 }

-static void connection_read_for_eos(server *srv, connection *con) {
+static void connection_read_for_eos_plain(server *srv, connection *con) {
        /* we have to do the linger_on_close stuff regardless
         * of con->keep_alive; even non-keepalive sockets may
         * still have unread data, and closing before reading
@@ -173,6 +173,18 @@ static void connection_read_for_eos(server *srv, connection *con) {
                con->close_timeout_ts = srv->cur_ts - (HTTP_LINGER_TIMEOUT+1);
 }

+static void connection_read_for_eos_ssl(server *srv, connection *con) {
+       if (con->network_read(srv, con, con->read_queue, MAX_READ_LIMIT) < 0)
+               con->close_timeout_ts = srv->cur_ts - (HTTP_LINGER_TIMEOUT+1);
+       chunkqueue_reset(con->read_queue);
+}
+
+static void connection_read_for_eos(server *srv, connection *con) {
+       !con->srv_socket->is_ssl
+         ? connection_read_for_eos_plain(srv, con)
+         : connection_read_for_eos_ssl(srv, con);
+}
+
 static void connection_handle_close_state(server *srv, connection *con) {
        connection_read_for_eos(srv, con);

Hi!

I've tried your patch - but still the same troubles/behaviour.

The behaviour is as follows:
1.) The HTTPS POST Form-Upload (multipart) is uploaded to target.
2.) In messages file on target I see the following message

lighttpd[23527]: (response.c.441) request-size too long: 110100927 -> 413 

It seems, that after the 5 seconds 'read' the connection is not closed instead it is reset and beginn from 0%!
When i force a call to connection_close everything is ok (instead of reading the 5seconds) - it seems, that for HTTPS the timeout of 5 seconds doesn't trigger the close of connection? HTTP is working as expected.

The same behaviour occurs with firefox (60.5) and chrome (72.0.3626.81).

Thanks,
Martin

My previous patch above is not sufficient since shutdown(con->fd, SHUT_WR) is called on the socket before that code is executed.

I wasn't able to (quickly) reproduce Firefox spinning while submitting, but I was testing on localhost, with both Firefox and browser running on the same machine.

However, I did see the browser reporting that the SSL connection was reset instead of showing the 413 error page.

There is code in lighttpd mod_openssl.c which reads encrypted data after attempting SSL_shutdown(), and then tries SSL_shutdown() again, but there is currently a 16KB limit to what is read. The limit was put in place because on slow, embedded systems where the CPU is slower decoding encrypted traffic than arriving traffic, the read loop might never end.

I pushed a slightly larger patch to git.lighttpd.net on the unstable branch personal/gstrauss/master. Please check if it works for you. See DevelGit

The updated patch takes into account that I see the state of SSL_is_init_finished() changing. I wonder if that is new behavior or a regression (I am using openssl 1.1.1a)

martin.schwarzbauer have you had a chance to test against lighttpd git master since my last post?