Lighttpd

I am also experiencing this issue. I have verified that the issue exists on lighttpd 1.4.11 through 1.4.13.

-- bmitchell

I have the same problem, any updates?

It works now with 1.4.13-r1 on Gentoo (I was running 1.4.11).

The same problem here - debian etch, lighttpd v 1.4.13-4, which is 1.4.13 with a few modifications to the init.d-file and default configs.
Any news on this? If gentoo has a working patch, where can I find it?

-- lukas

See lines 296 and 302 in the trace. lighttpd reads "HTTP/1.1 404 ...", but sends "HTTP/1.1 200 OK...", and encapsulates the 404 html-document into that ...

Hope this helps.

-- Lukas <lukas

Any news on this front? Anything I can do about it? If it works now in Gentoo, I'd really like to see that patch, but I don't have gentoo here and can't seem to find 1.4.13-r1 ...

-- lukas

there is no mod_proxy related patch in gentoo. so i would really wonder what is not working for you. and a friend of mine successfully proxies svn through lighttpd.

I do proxy svn, and it works. What's not working is adding new files to the repository. Please read the bugreport as it contains all information necessary to reproduce that bug ...

-- lukas

Just a note that this bug is still valid for lighttpd 1.4.17. If there's anything I can do about it, I'd be happy to help. Increased severity to major as this renders an 'svn add; svn ci' unfunctional.

-- lukas at einfachkaffee de

Still valid in 1.4.18

-- me

Just ran into this - what a pain! I guess I'll just have to open a port to apache instead. :(

-- dobesv

2007-04-11 00:43:12: (connections.c.816) missing cleanup in scgi

This cleanup failure is triggered if the scgi module tried handling the request but another module handled it afterwards too. (So i bet you loaded mod_scgi before mod_proxy in your module list)

So i just think both mod_scgi and mod_proxy tried handling the request (which of course they should not, so it is a bug in lighty).

But you should be able to workaround it with disabling mod_scgi if you want mod_proxy.

I hesitated using Lighty for proxying svn requests to Apache because of this ticket; now I tried it anyways, and strangely, it works just fine (even adding files). For your information, I am using stock binaries from Debian Etch:

Lighttpd 1.4.13
Apache 2.2.3
Svn 1.4.2

Lighttpd is hosting Trac via mod_fastcgi.

Hope this helps.

-- Alex

1.4.18 has the same problem.
I am using ssl with lighttpd.

I have the same problem here with
Debian Etch binary package revision: 1.4.13-4etch6

Updated to the following version (Etch Backports):
lighttpd-1.4.19 (ssl) - a light and fast webserver
Build-Date: Mar 19 2008 23:49:19

But the problem still exists.

Problem seems to be:

* HTTP-Requests with Method "PROPFIND" are rejected/not correctly forwarded by lighttpd to apache.
* apache itself never receives the HTTP-Request (not even tcpdump could detect network traffic)

The Bug is either in mod_proxy or lighttpd's HTTP-Parser. Maybe the parser is hardcoded to accept only "GET" and "POST" and rejects all the others.
But as I could find the requests log file of lighttpd, it seems to be a bug behind the HTTP-Parser inside the workflow...

Maybe it helps to know the active lighttpd modules:

 "mod_access" 
 "mod_alias" 
 "mod_accesslog" 
 "mod_rewrite" 
 "mod_auth" 
 "mod_fastcgi" 
 "mod_proxy" 

-- sdwarfs

Let's sort this one out!

@mafo: your issue is unrelated to the rest. Please set in your config:

server.reject-expect-100-with-417 = "disable" 

For everyone else, some have posted that it works for them, and some have posted that it does not. Please attach your lighttpd.conf with a name like broken-lighttpd.conf or works-lighttpd.conf and the version of lighttpd you are using. Thanks.

I walked through 1.4.39 code and nothing immediately jumped out at me which might change http_status from the 404 received from the backend since con->mode remains not DIRECT, and so any error handlers should not touch the response either.

Time allowing, I'll try to set up my own environment to test this, using https://redmine.lighttpd.net/projects/lighttpd/wiki/ApacheSubversionRecipe

Please mark this ticket fixed. I believe it was fixed in r2271. @mafo's issue is a config issue and is unrelated.

Updated by stbuehler over 7 years ago

    Status changed from Assigned to Fixed
    Resolution set to fixed

Comment

I tried fixing it in r2271 :)

So now it would be nice if you could test it, thx.

Submitted pull request https://github.com/lighttpd/lighttpd1.4/pull/38

While r2271 fixed the issue of multiple handlers incorrectly touching a request, I detected a new issue when testing. svn will send an OPTIONS request with request body using Transfer-Encoding: chunked. lighttpd did not detect the presence of request input body, and would proxy the request as-is to the backend Apache, and the backend Apache would time-out after 20 seconds waiting for the request body.

https://github.com/lighttpd/lighttpd1.4/pull/38 detects presence of Transfer-Encoding: chunked on request input and returns 411 Length Required, which causes svn to resend the request with Content-Length, and then the request is successfully relayed to the backend Apache.