Lighttpd

Your solution strikes me as unclean to have more than one "handler" for a request that is moderated by mod_proxy. Sometimes it is the mod_proxy handler and sometimes it is not mod_proxy, but something else on the local server.

however I noticed that there where no way for mod_proxy to include "it self" in the pool.

Would an alternative be to configure another virtual host on a different port? e.g. 127.0.0.1:88 and you could include that in your proxy pool? The caveat with this solution is that you would have to be careful to remove the :88 port on the URI when sending back HTTP redirects or other URI construction, but you are, in all likelihood already handling that if you are behind a load balancer.

I don't know if I read you right, but AFAIK have a request handled by more than one module is standard practice in lighttpd. I might have missed something but as far as I can see this patch should make the handling by mod_proxy for a "pass-through" host to be completely transparent, i.e any other module including the lighttpd core should see it as any other request not handled by mod_proxy just like if mod_proxy had been configured inside a conditional like:

$HTTP["remoteip"] == "xxx.16.164.14" {
        proxy.balance = "fair" 
        proxy.server = (
                "" => (
                        ( "host" => "10.91.128.68" ),
                        ( "host" => "10.81.64.161" ),
                        ( "host" => "10.102.19.53" ),
                        ( "host" => "pass-through" ),
                )
        )
}

and where the source would not match that of "xxx.16.164.14".

Using a new virtual host would of course work, but it would either require to run one more lighttpd server on the same host (wasting resources) or create a rather complex configuration. Reconstructing the URI is not really done in this case since the Amazon EC2 LBS in practice is DNS round robin plus something similar to mod_proxy.

You stated earlier:

however I noticed that there where no way for mod_proxy to include "it self" in the pool.

Therefore, I suggested a way, without requiring a patch, for mod_proxy to include "itself" in the pool. Your response:

Using a new virtual host would of course work, but it would ... create a rather complex configuration.

I'm sorry you feel that way. Would you provide more details as to why you think doing this would create a "rather complex configuration"? Creating a virtual host is fairly common practice, and not something considered too complex by most, so there must be something else that I am missing that is adding to the complexity. Please help me to understand.

While this patch sounds like it works for @HenrikHolst, I do not think this patch is generic and I do not think it should be applied. There is at least one valid configuration which allows for the desired functionality, and in most cases that I can think of, does not, IMO, add much complexity to the configuration.

Here is one example to clarify why I do not think the proposed patch should be applied. More advanced web server load balancers include options such as health-checking a host. The health-check can be done independently, something not straightforward if some requests are "passed through" as this patch does. This is why I described the patch as "unclean". I feel that it violates the abstraction of proxying.