Lighttpd

It appears to be very similar (identical?) to the bug here: http://trac.lighttpd.net/trac/ticket/35
Apparently it is still happening.

-- eliott

Seems to be stemming from a check in http-header-glue.c, in the function http_response_redirect_to_directory. The check is of con->conf.is_ssl. It is set to 0 even when ssl is being used and port 443.

It is effecting the following block of code:

if (con->conf.is_ssl) {
   buffer_copy_string(o, "https://");
} else {
   buffer_copy_string(o, "http://");
}

A backtrace to the call yeilds:

#0  http_response_redirect_to_directory (srv=0x8154008, con=0x81689b0) at http-header-glue.c:105
#1  0x0804fdc9 in http_response_prepare (srv=0x8154008, con=0x81689b0) at response.c:1205
#2  0x0805240b in connection_state_machine (srv=0x8154008, con=0x81689b0) at connections.c:1222
#3  0x0804d5cd in main (argc=9, argv=0x81689b0) at server.c:982

This only happens when in http_response_prepare a check for the uri request ending in a / is performed.

if (con->physical.path->ptr[con->physical.path->used - 2] != '/') 

I am not sure why con->conf.is_ssl is being set to 0. If that is resolved, then the subsequent code should work as designed. ie. a rewrite to https instead of http.

-- eliott

I think I tracked down the problem with some heavy duty debugging...
I attached a screenshot to highlight what seems to be the issue.

At line 1143 in connections.c, when SSL_set_accept_state(con->ssl); is done, con->is_ssl is not set. con->is_ssl is later tested in http-header-glue.c to determine if the rewrite is to http or https.

Shouldn't con->is_ssl be getting set in connections.c after a successful SSL accept?

-- eliott

I think I found the fix for the issue. I have attached a diff of the change. It is one line in connections.c.

-- eliott

The diff is against the 1.3.13 version.

-- eliott