Project

General

Profile

[1.5] Can a URL rewrite cause mod_proxy_core to choose a different backend?

Added by davidb54 over 15 years ago

Hi,

I am developing a lighttpd 1.5.0 plugin that may rewrite the request URI (either the http_host part, the uri part, or both) according to some rules. The exact nature of the rules is such that I cannot use an existing lighttpd module such as mod_rewrite.

Once the URI is rewritten, the request is passed to mod_proxy_core (mod_proxy_core_backend_http). However, I find that the lighttpd.conf conditionals are matched against the original URI, and not the rewritten URI. This causes the request to get sent to the wrong backend.

Example (host names and IP addresses are fake):

server.modules = ( "mod_access",
"mod_status",
"mod_foobar",
"mod_proxy_core",
"mod_proxy_backend_http",
"mod_accesslog" )

$SERVER["socket"] == ":80" {
proxy-core.protocol = "http"
}

$HTTP["host"] == "foobar.com" {
proxy-core.backends = ( "127.0.0.1:8080" )
}

$HTTP["host"] == "test.foobar.com" {
proxy-core.backends = ( "127.0.0.1:8081" )
}

In this example, mod_foobar receives a request for http://foobar.com/test/foo. The URI is rewritten by my plugin such that con->request.http_host becomes "test.foobar.com", con->request.uri becomes "/foo", con->uri.authority becomes "test.foobar.com", and con->uri.path becomes "/foo". Then the plugin returns HANDLER_GO_ON. My objective is to have a request to http://foobar.com/test/foo served on the backend with the following HTTP request to 127.0.0.1 port 8081:

GET /foo HTTP/1.1
Host: test.foobar.com

I am not sure exactly what is going on, but it seems as if mod_proxy_core is not recognizing that the URI has been rewritten. It uses the 127.0.0.1 port 8080 backend, even though the host was changed to "test.foobar.com". Is this expected behavior?

Thanks for your time-

-dave


Replies (1)

RE: Can a URL rewrite cause mod_proxy_core to choose a different backend? - Added by davidb54 over 15 years ago

To answer my own question, it appears that this must be expected behavior. When the request comes in and is handed to its first module, config_check_cond() caches the result of evaluating the data_config conditionals for the initial http_host. Rewriting the http_host in the first module does not magically expire the related cache entries. However, I looked around some more, and it appears that I can call config_cond_cache_reset_item() with COMP_HTTP_HOST to take care of this. I just tried it, and it worked perfectly.

Thanks for lighttpd.

-dave

    (1-1/1)