Lighttpd.cz

Lighttpd – Bug #1889 (Fixed): Add support for IPv6 in mod_extforward

Applied in changeset r2837.

Lighttpd – Revision 2837: [mod_extforward] Support ipv6 addresses (fixes #1889)

Lighttpd – Bug #1807: Long fcgi sessions is closed due to server.max-keep-alive-idle

You may be right; the problem is that the connection state machine is very complex, and i really don't want to change it in 1.4.x, as i fear i'll break too much.

If you have a simple patch that is easy to review... well, very unlikely.

Lighttpd – Bug #2416 (Fixed): Version 1.4.30 – Minor config problem: config_read: Assertion `cont…

Applied in changeset r2836.

Lighttpd – Revision 2836: Detect multiple -f options: show error message instead of assert (fixes…

Lighttpd – Revision 2835: fix typo in debug output

Lighttpd – Bug #2417 (Invalid): url.redirect Lost POST data

• not a bug
• it actually is better if it does NOT work that way, so people don't post to the insecure url

Lighttpd – Bug #2417 (Invalid): url.redirect Lost POST data

I am trying to redirect my page from http:// to https:// />I have few POST data, after redirect I lost my data. I have rules as follow.

$SERVER["socket"] == "<ip>:443" {
                ssl.engine = "enable" 
                ssl.pemfile = var.confdir + "/<domain>.pem" 
                ssl.ca-file = var.confdir + "/<domain>.crt" 
                server.name = "<domain>"

}

$SERVER["socket"] == ":80" {
                $HTTP["host"] =~ "(.*)" {
                        url.redirect= ( "/payment/$" => "https://%1/payment/")
                }
        }

server.document-root = "/var/<path>/htdocs"

Lighttpd – Bug #1807: Long fcgi sessions is closed due to server.max-keep-alive-idle

I'm having issues that sound quite similar to what is described in this ticket (on 1.5.0 r2533, used as reverse proxy with mod_proxy_core/mod_proxy_backend_http).

I experienced issues with long-running requests (GET and POST) e.g. from a simple form submission, that sometimes appear to actually be sent (and processed) multiple times on the backend server. Doing some traces on the client network showed that the TCP connection gets closed from the server side, while the request is still being processed (always after 5 seconds). Subsequently, the request is sent once again by the browser, leading to multiple invocations on the backend server.

Increasing server.max-keep-alive-idle to a higher value than the default of 5 seconds finally solved the problem (as long as the chosen time is high enough, that is), so it's really lighttpd causing the problem as it seems.

I guess this config option is not really supposed to close connections on which an HTTP request is still being processed, right (i.e. the connection not in fact being idle)? Of course I'd like to have a better solution than just setting the max-keep-alive-idle very high (which may lead to the same problem again anyway...)

Thanks

Lighttpd – Bug #2416 (New): Version 1.4.30 – Minor config problem: config_read: Assertion `contex…

Hi,

I found out that giving -f more than once can cause problems.

lighttpd -f lighttpd.conf -f lighttpd.conf

It was the same .conf file btw (which was my accident, I just found out that lighttpd hates this)

Lighttpd then will say:

lighttpd: configfile.c:1101: config_read: Assertion `context.all_configs->used == 0' failed.
Aborted

And it will abort.

When I first had this problem, it was not obvious to me why it happened (I used an alias actually and then just appended -f again to this alias, which used -f already).

The error message: "Assertion failed" was not useful to me.

Proposal:

Make this specific error message more useful in case a user uses the -f option twice (or more than once).

Suggestion for error message, in case of abort-like problems:

"You seem to be using the -f option more than once."
"Please review your configuration files as they may contradict each other."

And then a listing which specific configuration option is in conflict perhaps - that would be most helpful.